Kubernetes should configure the ambient capability set

> /kind bug **What happened**: The following takes place on a k8s 1.8.2 cluster. I have a Docker container image that wants to listen on :80, and specifies a non-root USER. To get this running, in my pod spec the container has the following security context: ```yaml securityContext: capabilities: drop: - all add: - NET_BIND_SERVICE allowPrivilegeEscalation: false ``` When I schedule this pod on the cluster, the container fails to bind to :80 (permission denied), and goes into a crashloop. Note that Kubernetes did not complain that this configuration is in any way infeasible. The reason for this is that Linux capabilities interact in surprising ways with other security mechanisms. In this case, the problem is that I'm also running the container as a non-root user, and Kubernetes/Docker are only setting the inherited, permitted, effective and bounding capability sets. The catch is: the effective and permitted sets get _cleared_ when you transition from UID 0 to UID !0, so my container ends up with: ``` CapInh: 0000000000000400 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000000000000400 CapAmb: 0000000000000000 NoNewPrivs: 1 ``` 0x400 is CAP_NET_BIND_SERVICE, and as you can see my effective capabilities do not have this bit set. The linux kernel corrected this very confusing behavior by introducing the ambient capability set, which does not have surprising behaviors when you transition from UID 0 to !0. If you've se

Posted by danderson on Nov 26, 2017, 4:02 AM

Tags

• github (Sysadmin)

Related issues

• Custom games stuck on "finding server" for all european servers
• Feature request: add ACP (Agent Client Protocol) stdio JSON-RPC mode
• Forza Horizon 6 (2483190)
• Turn off integrated browser for default
• Weekly updates are too frequent
• [BUG] Max 20x plan: 100% usage after 2 hours of light work (5 commits, no agents)