You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm trying to set this up on a multi-tenanted EKS cluster with around 300 namespaces. We enforce tenant boundaries quite strictly and lock everything down with gatekeeper. I'm running in to an issue where the controller can't inject the init container into pods due to its security context, I don't see anything about this in the controller logs. But I encounter this issue if I manually apply a pod manifest with the init and sidecar containers populated. If I bypass the gatekeeper rule then the pod is applied correctly and I can assume managed identities in Azure.
Describe the solution you'd like
Other components (like Istio's Envoy sidecar) reconfigure a pod's networking using CNI plugins and don't require a special security context. Is this an approach that you'd consider implementing?
Error from server (Forbidden): error when creating "test.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [default-privileged-restriction] Privileged container is not allowed: init-networking, securityContext: {"capabilities": {"add": ["NET_ADMIN"], "drop": ["ALL"]}, "privileged": true, "runAsUser": 0}
[default-capability-restriction] init container <init-networking> has a disallowed capability. Allowed capabilities are ["NONE"]
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'm trying to set this up on a multi-tenanted EKS cluster with around 300 namespaces. We enforce tenant boundaries quite strictly and lock everything down with gatekeeper. I'm running in to an issue where the controller can't inject the init container into pods due to its security context, I don't see anything about this in the controller logs. But I encounter this issue if I manually apply a pod manifest with the init and sidecar containers populated. If I bypass the gatekeeper rule then the pod is applied correctly and I can assume managed identities in Azure.
Describe the solution you'd like
Other components (like Istio's Envoy sidecar) reconfigure a pod's networking using CNI plugins and don't require a special security context. Is this an approach that you'd consider implementing?
Describe alternatives you've considered
We could potentially replicate the iptables configuration using an envoy filter.
Additional context
Applying:
Results in:
The text was updated successfully, but these errors were encountered: