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 more 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 policies are implemented by a set of specialized Kubernetes resources (PodSecurityPolicy), generic resources (ServiceAccount, higher level pod controllers 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, and 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.
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, 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:
privileged: false # Don't allow privileged pods!
# The rest fills in some required fields.
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
Examples
Multiple PodSecurityPolicies
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: