In Kubernetes, a container's user ID table maps to the host's user table. Running a process as the root user inside a container runs it as root on the host. Many container images use the root user to run PID 1. If PID 1 is compromised, an attacker has root permissions in the container, and any misconfigurations can be exploited.
Containers that run as root frequently have more permissions than their workload requires which, in case of compromise, could help an attacker further their exploits.
- Resource: PodSecurityPolicy
runAsUser:rule:MustRunAsNonRoot - Unable containers to run with root privileges.
runAsUser:rule:MustRunAs - When the minimum range is set to 1 or higher, containers cannot run as root.
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: <policy name> spec: runAsUser: + rule: 'MustRunAsNonRoot' or rule: 'MustRunAs' ranges: + - min: <min user, 1 or higher> max: <max user>
To use a PodSecurityPolicy resource, the requesting user or target pod’s service account must be authorized to use the policy. The preferred method is to grant access to the service account. In the following example we use RBAC, a standard Kubernetes authorization mode.
A Role or ClusterRole needs to grant access to use the desired policies.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <role name> rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: - <policy name>
The ClusterRole is bound to the authorized service(s):
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <binding name> roleRef: kind: ClusterRole name: <role name> apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: <authorized service account name> namespace: <authorized pod namespace>
Updated 12 months ago