Kubernetes Pod Security Policy Concepts
External
- https://kubernetes.io/docs/concepts/policy/pod-security-policy/
- https://kubernetes.io/docs/concepts/security/pod-security-standards/
Internal
Overview
A pod security policy is a cluster-level API resource that specifies required values and limitations for security-sensitive aspects for pod and container configurations, as configured by the pod security context and container security context. If those values are not present in the pod configuration, the pod security policy provides default values.
The pod and container security contexts configure pods and containers at runtime. They are defined as part of the pod manifest and are consumed by the container runtime, which uses them as configuration parameters. However, pod manifests could be intercepted and modified by a malicious actor, with the aim of giving excessive privileges to containers. Pod security policies are the mechanism to protect against this possibility. Pod security policies are the control plane mechanism to enforce specific settings in the security contexts, as well as other parameters outside the security contexts. The pod security policies ensure that the pods and containers created from the pod manifest cannot go beyond security boundaries specified and enforced by the pod security policies.
A pod security policy is an example of a Kubernetes policy.
Pod Security Policy Functions
The pod security policies are used in conjunction with pod and container security contexts to define privilege and access control settings for pods and containers. Together, they can:
- Define whether a pod can use host's IPC, PID or Network namespaces.
- Define which host ports a pod can bind to.
- Define discretionary access control elements such as what user IDs a container can run as.
- Define whether a pod can have privileged containers.
- Define which kernel capabilities are allowed, which are added by default and which are always dropped.
- Define what SELinux labels a container can use.
- Specify whether a container can use a writable root filesystem or not.
- Define which volume types a pod can use.
- Filter a process' system calls.
- Control whether a process can gain more privileges that its parent process.
If a pod or container security context does not specify values for elements such as runAsUser or runAsGroup, but the corresponding PodSecurityPolicies has rules on those values, default values that comply with the rules will be provided and the pod will be deployed with them. This applies even in the case the container image contains corresponding configuration, such as USER for UID:GID. If there's a PodSecurityPolicy rule referring to runAsUser, a conforming default value will be provided, overriding the container image configuration.
Implementation
Pod security policies are implemented by a set of specialized Kubernetes resources (PodSecurityPolicy), generic resources (ServiceAccount, workload resources such as Deployments, ReplicaSets and so on), the PodSecurityPolicy admission controller and other controllers, all working in concert to ensure that the pods are created within strict security assumptions, and the pods access various resources in a controlled, secure manner. The pod security policies can also be used to provide default values for many of the fields that they control.
To enable pod security policy control, the PodSecurityPolicy admission controller must be explicitly enabled. At the same time, corresponding PodSecurityPolicy instances must be created and deployed, otherwise the admission controller will prevent any pods from being created in the cluster. The PodSecurityPolicies can be deployed before enabling the admission controller - this is the recommended deployment sequence.
When the admission controller is not able to locate any suitable policy, either because none was deployed, or the current identity does have the permission to use any, the operation will fail with a message similar to:
Error from server (Forbidden): error when creating "./[...]": unable to validate against any pod security policy: []
When multiple PodSecurityPolicies are available, the admission controller selects one policy to use.
When the pod is created, the identity that executes the pod creation request, either a users or a service accounts, must have the permission to use at least one PodSecurityPolicy. The permission to use is gained by binding the identity to a role that allows the use of the PodSecurityPolicy, as shown in the Role that Allows Use of Pod Security Policy section. For more details on the identity under which a pod is created, see Identity under which Pods are Created. Note that associating PodSecurityPolicy with users is not recommended, service accounts are preferred. More details on how a PodSecurityPolicy can be associated with users and security accounts are available in PodSecurityPolicy Operations. Apparently, an alternative method to associate pods with a specific policy is to grant its higher-level controller access to the policy, but that would meant that all pods created by the controller in question are associated with the policy. The more selective method of using a service account is preferred.
Once a pod security policy is selected, the PodSecurityPolicy admission controller plugin validates the pod definition against it. If the pod conforms to the cluster's policies, it is accepted and stored in etcd, otherwise is rejected immediately. The plugin may also modify the pod resources according to the defaults configured in the policy.
Note that the controller manager must be run against the secure API port and must not have superuser permissions, otherwise requests would bypass authentication and authorization modules, all PodSecurityObjects would be allowed and users would be able to create privileged containers. For more details, see Controlling Access to the Kubernetes API.
PodSecurityPolicy
The PodSecurityPolicy is a cluster-level resource that defines a set of conditions that a pod must run with in order to be accepted in the system, aspects of pod behavior, security-related features users can or can't use in the pods as well as defaults for the related fields.
Note that an API server has a single, cluster-wide list of PodSecurityPolicies, available with:
kubectl get podsecuritypolicies
PodSecurityPolicy Manifest
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: hostIPC: false # Containers are not allowed to use the host IPC namespace hostPID: false # Containers are not allowed to use the host PID namespace hostNetwork: false # Containers are not allowed to use the host network namespace hostPorts: - min: 10000 max: 11000 - min: 13000 max: 14000 privileged: false # Don't allow privileged pods! readOnlyRootFilesystem: true runAsUser: rule: RunAsAny runAsGroup: rule: RunAsAny fsGroup: rule: RunAsAny supplementalGroups: rule: RunAsAny seLinux: rule: RunAsAny allowedCapabilities: - ... defaultAddCapabilities: - ... requiredDropCapabilities: - ... volumes: - '*'
Examples
PodSecurityPolicy Update
Changing a policy has no effect on existing pods. PodSecurityPolicies are enforced only when creating or updating pods.
Multiple PodSecurityPolicies
TODO: Kubernetes in Action 13.3.5 "Assigning different PodSecurityPolicies to different users and groups"
Multiple policies may be available for admission controller to use. The list of deployed PodSecurityPolicies can be obtained with kubectl get podsecuritypolicies.
When more than one policy are available, the admission controller needs to decide which one to use.
First, it selects all policies the identity making the call, be it a user or a service account, has permission to use, and the rest are ignored.
If after selection there are still multiple policies, the access controller selects the policy according to the following criteria:
- PodSecurityPolicies which allow the pod as-is, without changing defaults or mutating the pod, are preferred. The order of these non-mutating PodSecurityPolicies doesn't matter.
- If the pod must be defaulted or mutated, the first PodSecurityPolicy (ordered by name) to allow the pod is selected.
During update operations (during which mutations to pod specs are disallowed) only non-mutating PodSecurityPolicies are used to validate the pod.
Role that Allows Use of Pod Security Policy
To be allowed to use a specific PodSecurityPolicy, so the PodSecurityPolicy appears among those the admission controller will select from, an identity must be bound to a cluster role or role that allows the use of the policy:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: [...]
rules:
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames: ['example']
A concrete example of how to associate a PodSecurityPolicy with a service account, including deploying the required role and role binding, is available in the Operations section: Associate a PodSecurityPolicy with a Service Account.
PodSecurityPolicy Operations
PodSecurityPolicy Admission Controller
The PodSecurityPolicy admission controller is a piece of code within the API server that intercepts pod creation and modification requests and determines if the request should be allowed based on the requested security context and the available PodSecurityPolicies.
More about admission controllers and admission controller operations: