istio: proxy: init container cannot manipulate iptables with selinux enforcing

When selinux is enforcing withing RHEL, the iptables rules do not appear properly setup when the init container runs.

First error first time the init container is run: iptables: No chain/target/match by that name. Second error (and forever after) the init container is run: iptables: Chain already exists

with selinux set to enforcing, the following error appears

`type=AVC msg=audit(1521747498.758:3677): avc:  denied  { module_request } for  pid=486 comm="iptables" kmod="ipt_REDIRECT" scontext=system_u:system_r:svirt_lxc_net_t:s0:c388,c684 tcontext=system_u:system_r:kernel_t:s0 tclass=system`

istio version: 0.6.0 OS: RHEL 7.4 Environment: OpenShift Origin 3.9 rc / kube 1.9

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 24 (11 by maintainers)

Most upvoted comments

I have a few results after more testing and found a few issues:

Sidecar defaults

In our docs we mention several ways of injecting the sidecar but the logic and instructions do not inherently require someone to use the istio-inject configmap. During setup we recommend bootstrapping Istio with kubectl apply -f ./install/kubernetes/istio.yaml . I think this yields the very minimum settings required for the sidecar here. A file injected manually with istioctl will default to these settings and the template will not fill in the correct NET_ADMIN privileges.

Possible options for sidecar docs:

Highlight the need for adding the istio-sidecar-injector-release.yaml file from the setup instructions and using the configMap option for manual injection
Add the release.yaml to the istio.yaml in place of the current default settings

Privilege settings

The release configmap only adds minimal NET_ADMIN securityContext settings for the init container but this is either not enough for SeLinux/AppArmor or there is a subtle bug in our prepare_proxy.sh script.

** Possible problems **

The release configmap sets the run user for the proxy as 1337 but we do not create that user except in the case of the proxy debug container
- We either need to remove the -u setting for init and fall back to whatever the default is for the proxy_init or add the logic to the init container that we have in proxy
- If we truly do add these settings, we may need to consider adding additional CAP settings to allow the container to manage user settings
If I use the debug settings and then delete the sleep sample and restart it with the release settings, everything passes successfully.
- This makes me think we are doing more than manipulating iptables rules in the release init container

cmluciano on Mar 26, 2018