Skip to content

Root containers admitted

Description

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.

Fix - Buildtime

Kubernetes

  • Resource: PodSecurityPolicy
  • Arguments:
    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.

Kind: ClusterRole

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):

Kind: ClusterRoleBinding

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>