A privileged container gives its processes full or nearly unrestricted access to the operating system kernel. Because those processes can execute system calls that affect the node, most containers should run without elevated privileges; use privileged mode only when necessary and trusted. section 2.3.4 section 17.2.1
Choose the narrowest permission model that satisfies the workload:
- Run without elevated privileges for ordinary application workloads. section 2.3.4
- Use a privileged container when the process needs full kernel access, such as modifying node network packet-filtering rules. section 17.2.1
- Grant selected Linux capabilities when the workload needs only particular privileged operations; examples include NET_ADMIN, NET_RAW, NET_BIND_SERVICE, and SYS_TIME. section 2.3.4 section 17.2.1
Kubernetes node agents
The kube-proxy DaemonSet sets securityContext.privileged to true because it needs root access to the host kernel for Kubernetes Service networking. The kindnet DaemonSet instead adds NET_RAW and NET_ADMIN while setting privileged to false. section 17.2.1
$ kubectl -n kube-system get ds kube-proxy -o yaml
apiVersion: apps/v1
kind: DaemonSet
spec:
template:
spec:
containers:
- name: kube-proxy
securityContext: #1
privileged: true #1
...
Inspect the kube-proxy DaemonSet manifest to see privileged: true in the container securityContext. section 17.2.1
$ kubectl -n kube-system get ds kindnet -o yaml
apiVersion: apps/v1
kind: DaemonSet
spec:
template:
spec:
containers:
- name: kindnet-cni
securityContext: #1
capabilities: #1
add: #1
- NET_RAW #1
- NET_ADMIN #1
privileged: false #2
Inspect the kindnet DaemonSet manifest to compare selected capabilities with privileged: false. section 17.2.1
