Ensure containers with added capability are not allowed

Error: Containers with added capability are allowed

Bridgecrew Policy ID: BC_K8S_23
Checkov Check ID: CKV_K8S_24
Severity: LOW

Containers with added capability are allowed


Using the Linux capabilities feature you can grant certain privileges to a process without granting all the privileges of the root user. Added capabilities entitle containers in a pod with additional privileges that can be used to change core processes and networking settings of a cluster. We recommend you only use privileges that are required for the proper function of the cluster.

To add or remove Linux capabilities for a container, you can include the capabilities field in the securityContext section of the container manifest.

Fix - Buildtime


  • Resource: PodSecurityPolicy
  • Argument: allowedCapabilities (Optional)
    Provides a list of capabilities that may be added to a container beyond the default set.
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
  name: <policy name>
- allowedCapabilities:

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
  name: <role name>
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  - <policy name>

The ClusterRole is then bound to the authorized service(s):

Kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: <binding name>
  kind: ClusterRole
  name: <role name>
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: <authorized service account name>
  namespace: <authorized pod namespace>