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
Copy file name to clipboardExpand all lines: modules/k8s-best-practices-linux-capabilities.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ The capabilities associated with a new container are determined as follows:
18
18
19
19
* If the container has the UID 0 (root) its Effective capability set is determined according to the capability attributes requested by the pod or container security context and allowed by the SCC assigned to the pod. In this case, the SCC provides a way to limit the capabilities of a root container.
20
20
21
-
* If the container has a UID non 0 (non root), the new container has an empty Effective capability set (see link:https://github.com/kubernetes/kubernetes/issues/56374#[]). In this case the SCC assigned to the pod controls only the capabilities the container may acquire through the file capabilities of binaries it will execute.
21
+
* If the container has a UID non 0 (non root), the new container has an empty Effective capability set (see link:https://github.com/kubernetes/kubernetes/issues/56374#[Kubernetes should configure the ambient capability set]). In this case the SCC assigned to the pod controls only the capabilities the container may acquire through the file capabilities of binaries it will execute.
22
22
23
23
Considering the general recommendation to avoid running root containers, capabilities required by non-root containers are controlled by the pod or container security context and the SCC capability attributes but can only be acquired by properly setting the file capabilities of the container binaries.
0 commit comments