NGINX Service Mesh Permissions
This topic documents a beta feature. Beta features are provided for you to try out before they are released. You shouldn't use beta features for production purposes.
The init container is a privileged container that runs as root. In addition to the container running with root privileges on the host system, it also has weaker sandboxing. The init container needs this level of access in order to manipulate
eBPF on the host.
Kubernetes allows pods to be given capabilities that extend their permissions and allow them to perform restricted tasks. These capabilities are modelled after the standard Linux capabilities (
man capabilities). The sidecar init container uses the following capabilities:
CAP_NET_ADMIN) This capability provides the ability to administer the IP firewall and modify the routing tables.
CAP_NET_RAW) This capability provides the ability to open and use RAW sockets.
CAP_SYS_RESOURCE) Used by the init container to lock memory for BPF resources.
CAP_SYS_ADMIN) This capability provides access to BPF operations, among other things.
Some services like NGINX Ingress Controller and Certificate Manager will fail to deploy when auto-injected with the NGINX Service Mesh init container. This may be because they specify
runAsNonRoot in their security policies, which prevents the init container from launching. This issue can be avoided by containing these services in their own namespaces where auto-injection is disabled.
The sidecar container cannot escalate privilege and is not a privileged container. The sidecar container runs as user 2102 once the init container has completed.
All other containers in NGINX Service Mesh use