Containers with added capability are allowed
Description
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
Kubernetes
- 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
metadata:
name: <policy name>
spec:
- 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
metadata:
name: <role name>
rules:
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- <policy name>
The ClusterRole is then 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>