{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/56374","repository_url":"https://api.github.com/repos/kubernetes/kubernetes","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/56374/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/56374/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/56374/events","html_url":"https://github.com/kubernetes/kubernetes/issues/56374","id":276797602,"number":56374,"title":"Kubernetes should configure the ambient capability set","user":{"login":"danderson","id":1918,"avatar_url":"https://avatars0.githubusercontent.com/u/1918?v=4","gravatar_id":"","url":"https://api.github.com/users/danderson","html_url":"https://github.com/danderson","followers_url":"https://api.github.com/users/danderson/followers","following_url":"https://api.github.com/users/danderson/following{/other_user}","gists_url":"https://api.github.com/users/danderson/gists{/gist_id}","starred_url":"https://api.github.com/users/danderson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danderson/subscriptions","organizations_url":"https://api.github.com/users/danderson/orgs","repos_url":"https://api.github.com/users/danderson/repos","events_url":"https://api.github.com/users/danderson/events{/privacy}","received_events_url":"https://api.github.com/users/danderson/received_events","type":"User","site_admin":false},"labels":[{"id":105146071,"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/kind/bug","name":"kind/bug","color":"e11d21","default":false},{"id":778118404,"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/lifecycle/stale","name":"lifecycle/stale","color":"795548","default":false},{"id":173493665,"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/sig/node","name":"sig/node","color":"d2b48c","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2017-11-26T04:02:16Z","updated_at":"2018-04-18T15:45:16Z","closed_at":null,"author_association":"NONE","body":"> /kind bug\r\n\r\n**What happened**:\r\n\r\nThe following takes place on a k8s 1.8.2 cluster.\r\n\r\nI 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:\r\n\r\n```yaml\r\nsecurityContext:\r\n    capabilities:\r\n        drop:\r\n        - all\r\n        add:\r\n        - NET_BIND_SERVICE\r\n    allowPrivilegeEscalation: false\r\n```\r\n\r\nWhen 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.\r\n\r\nThe 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:\r\n\r\n```\r\nCapInh:\t0000000000000400\r\nCapPrm:\t0000000000000000\r\nCapEff:\t0000000000000000\r\nCapBnd:\t0000000000000400\r\nCapAmb:\t0000000000000000\r\nNoNewPrivs:\t1\r\n```\r\n\r\n0x400 is CAP_NET_BIND_SERVICE, and as you can see my effective capabilities do not have this bit set.\r\n\r\nThe 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 set a capability as ambient, you keep it unless you explicitly revoke it.\r\n\r\n**What you expected to happen**:\r\n\r\nI expect the capabilities I assign in my podspec to still exist when my main binary `exec`s, regardless of other security context configuration (assuming k8s accepted my manifest as valid). To me, that translates to: k8s should be writing the caps described by `securityContext.capabilities` into the ambient capability set, as well as the other capability sets.\r\n\r\nAlternatively, if you believe the current behavior of `securityContext.capabilities` is working as intended, there should be another knob somewhere that I can use to populate the ambient capability set. However, I would strongly encourage you to instead consider the current behavior of `securityContext.capabilities` combined with non-root users as a bug, because it will likely trip up ~everyone using it unless they know a lot about the linux capability implementation.\r\n\r\n**How to reproduce it (as minimally and precisely as possible)**:\r\n\r\nDeploy this pod to a cluster using the default container runtime. You should see it crashlooping, with `kubectl logs bug-demo` showing that netcat is not allowed to bind to :80. If you comment out `runAsUser` and let the container binary run as root, it'll work fine. Similarly, if you modify the container to have a binary that has been altered with `setcap net_bind_service=+ep`, the contianer will run correctly as !root, because the setcap'd binary allows the container to regain the privileges it lost when transitioning out of UID 0.\r\n\r\n```yaml\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  name: bug-demo\r\nspec:\r\n  containers:\r\n  - name: netcat\r\n    image: danderson/bug-demo:latest\r\n    args:\r\n    - /bin/sh\r\n    - -c\r\n    - \"netcat -l -p 80\"\r\n    securityContext:\r\n      runAsUser: 65534\r\n      capabilities:\r\n        drop:\r\n        - all\r\n        add:\r\n        - NET_BIND_SERVICE\r\n      allowPrivilegeEscalation: false\r\n```\r\n\r\n**Anything else we need to know?**:\r\n\r\n**Environment**:\r\n- Kubernetes version (use `kubectl version`): 1.8.2 server, 1.8.1 kubectl\r\n- Cloud provider or hardware configuration: bare metal cluster, single node (master taint removed), set up with `kubeadm`.\r\n- OS (e.g. from /etc/os-release): Debian Testing\r\n- Kernel (e.g. `uname -a`): Linux pandora 4.12.0-2-amd64 #1 SMP Debian 4.12.13-1 (2017-09-19) x86_64 GNU/Linux\r\n- Install tools: `kubeadm`\r\n- Others:\r\n"},"comment":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/comments/382433631","html_url":"https://github.com/kubernetes/kubernetes/issues/56374#issuecomment-382433631","issue_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/56374","id":382433631,"user":{"login":"johngmyers","id":1760720,"avatar_url":"https://avatars1.githubusercontent.com/u/1760720?v=4","gravatar_id":"","url":"https://api.github.com/users/johngmyers","html_url":"https://github.com/johngmyers","followers_url":"https://api.github.com/users/johngmyers/followers","following_url":"https://api.github.com/users/johngmyers/following{/other_user}","gists_url":"https://api.github.com/users/johngmyers/gists{/gist_id}","starred_url":"https://api.github.com/users/johngmyers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/johngmyers/subscriptions","organizations_url":"https://api.github.com/users/johngmyers/orgs","repos_url":"https://api.github.com/users/johngmyers/repos","events_url":"https://api.github.com/users/johngmyers/events{/privacy}","received_events_url":"https://api.github.com/users/johngmyers/received_events","type":"User","site_admin":false},"created_at":"2018-04-18T15:45:16Z","updated_at":"2018-04-18T15:45:16Z","author_association":"NONE","body":"/remove-lifecycle stale"}}
{"actor":{"display_login":"johngmyers"}}