Kubernetes Pod Security Policy Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(169 intermediate revisions by the same user not shown)
Line 4: Line 4:


=Internal=
=Internal=
* [[Kubernetes_Pod_and_Container_Security#Pod_Security_Policy|Kubernetes Pod and Container Security]]
* [[Kubernetes_Security_Concepts#Pod_Security_Policies|Kubernetes Security Concepts]]
* [[Kubernetes_Security_Concepts#Pod_Security_Policies|Kubernetes Security Concepts]]
=Overview=
=Overview=


A pod security policy is an example of a [[Kubernetes Concepts#Kubernetes_Policies|Kubernetes policy]].
A pod security policy is a cluster-level [[Kubernetes_API_Resources_Concepts#API_Resources|API resource]] that specifies required values and limitations for security-sensitive aspects for pod and container configurations, as configured by the [[Kubernetes_Pod_and_Container_Security#Pod_Security_Context|pod security context]] and [[Kubernetes_Pod_and_Container_Security#Container_Security_Context|container security context]]. If those values are not present in the pod configuration, the pod security policy provides default values.
 
The [[Kubernetes_Pod_and_Container_Security#Pod_Security_Context|pod]] and [[Kubernetes_Pod_and_Container_Security#Container_Security_Context|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 Policies#Overview|Kubernetes policy]].
==<span id='PodSecurityPolicy_Functions'></span>Pod Security Policy Functions==
The pod security policies are used in conjunction with [[Kubernetes_Pod_and_Container_Security#Pod_Security_Policy|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 [[Kubernetes_Pod_and_Container_Security#Access_to_Host_Namespaces|host's IPC, PID or Network namespaces]].
* Define which host ports a pod can bind to.
* Define [[Kubernetes_Pod_and_Container_Security#Discretionary_Access_Control|discretionary access control elements]] such as what user IDs a container can run as.
* Define whether a pod [[Kubernetes_Pod_and_Container_Security#Privileged_Mode|can have privileged containers]].
* Define which [[Kubernetes_Pod_and_Container_Security#Linux_.28Kernel.29_Capabilities|kernel capabilities]] are allowed, which are added by default and which are always dropped.
* Define what [[Kubernetes_Pod_and_Container_Security#SELinux|SELinux labels a container can use]].
* Specify whether a container can use a [[Kubernetes_Pod_and_Container_Security#readOnlyRootFilesystem|writable root filesystem or not]].
* Define which volume types a pod can use.
* [[Kubernetes_Pod_and_Container_Security#Seccomp|Filter a process' system calls]].
* Control whether a process can [[Kubernetes_Pod_and_Container_Security#allowPrivilegeEscalation|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|PodSecurityPolicy]]), generic resources ([[Kubernetes_Security_Concepts#Service_Account|ServiceAccount]], [[Kubernetes Workload Resources|workload resources]] such as [[Kubernetes_Deployments|Deployments]], [[Kubernetes_ReplicaSet|ReplicaSets]] and so on), the [[#PodSecurityPolicy_Admission_Controller|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 [[#PodSecurityPolicy_Controlled_Aspects_and_Fields|fields]] that they control.
 
To enable pod security policy control, the [[#PodSecurityPolicy_Admission_Controller|PodSecurityPolicy admission controller]] must be [[Admission_Controller_Operations#Turn_On_an_Admission_Controller|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:
<syntaxhighlight lang='text'>
Error from server (Forbidden): error when creating "./[...]": unable to validate against any pod security policy: []
</syntaxhighlight>
 
When multiple PodSecurityPolicies are available, the admission controller [[#Multiple_PodSecurityPolicies|selects one policy to use]].
 
When the pod is created, the identity that executes the pod creation request, either a [[Kubernetes_Security_Concepts#User_Account|users]] or a [[Kubernetes_Security_Concepts#Service_Account|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|Role that Allows Use of Pod Security Policy]] section. For more details on the identity under which a pod is created, see [[Kubernetes_Pod_and_Container_Concepts#Identity_under_which_Pods_are_Created|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.


Pod security policy is implemented by a set of specialized Kubernetes resources ([[#PodSecurityPolicy|PodSecurityPolicy]]), generic resources ([[Kubernetes_Security_Concepts#Service_Account|ServiceAccount]], [[Kubernetes Higher Level Pod Controllers|higher level pod controllers]] such as [[Kubernetes_Deployments|Deployments]], [[Kubernetes_ReplicaSet|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, secured manner.
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 [[Kubernetes_Security_Concepts#Controlling_Access_to_the_Kubernetes_API|Controlling Access to the Kubernetes API]].
 
[[File:PodSecurityPolicy.png]]


=PodSecurityPolicy=
=PodSecurityPolicy=
The PodSecurityPolicy is a [[Kubernetes_API_Resources_Concepts#API_Resources|cluster-level resource]] that defines a set of conditions that a pod must run with in order to be accepted in the system, [[#PodSecurityPolicy_Controlled_Aspects_and_Fields|aspects of pod behavior]], security-related features users can or can't use in the pods as well as defaults for the related [[#PodSecurityPolicy_Fields|fields]].
Note that an API server has a single, cluster-wide list of PodSecurityPolicies, available with:
[[PodSecurityPolicy_Operations#Get_Deployed_PodSecurityPolicies|kubectl get podsecuritypolicies]]
==PodSecurityPolicy Manifest==
{{External|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritypolicy-v1beta1-policy}}
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  [[Kubernetes_Pod_and_Container_Security#Access_to_Host_Namespaces|hostIPC]]: false # Containers are not allowed to use the host IPC namespace
  [[Kubernetes_Pod_and_Container_Security#Access_to_Host_Namespaces|hostPID]]: false # Containers are not allowed to use the host PID namespace
  [[Kubernetes_Pod_and_Container_Security#Access_to_Host_Namespaces|hostNetwork]]: false # Containers are not allowed to use the host network namespace
  hostPorts:
    - min: 10000
      max: 11000
    - min: 13000
      max: 14000
  [[Kubernetes_Pod_and_Container_Security#privileged|privileged]]: false  # Don't allow privileged pods!
  [[Kubernetes_Pod_and_Container_Security#readOnlyRootFilesystem|readOnlyRootFilesystem]]: true
  [[Kubernetes_Pod_and_Container_Security#runAsUser|runAsUser]]:
    rule: RunAsAny
  [[Kubernetes_Pod_and_Container_Security#runAsGroup|runAsGroup]]:
    rule: RunAsAny
  [[Kubernetes_Pod_and_Container_Security#fsGroup|fsGroup]]:
    rule: RunAsAny
  [[Kubernetes_Pod_and_Container_Security#supplementalGroups|supplementalGroups]]:
    rule: RunAsAny
  [[Kubernetes_Pod_and_Container_Security#seLinux|seLinux]]:
    rule: RunAsAny
  [[Kubernetes_Pod_and_Container_Security#allowedCapabilities|allowedCapabilities]]:
    - ...
  [[Kubernetes_Pod_and_Container_Security#defaultAddCapabilities|defaultAddCapabilities]]:
    - ...
  [[Kubernetes_Pod_and_Container_Security#requiredDropCapabilities|requiredDropCapabilities]]:
    - ...
  [[Kubernetes_Pod_and_Container_Security#volumes|volumes]]:
  - '*'
==Examples==
{{External|https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies}}
==PodSecurityPolicy Update==
Changing a policy has no effect on existing pods. PodSecurityPolicies are enforced only when creating or updating pods.
==Multiple PodSecurityPolicies==
<font color=darkgray>TODO: Kubernetes in Action 13.3.5 "Assigning different PodSecurityPolicies to different users and groups"</font>
Multiple policies may be available for admission controller to use. The list of deployed PodSecurityPolicies can be obtained with [[PodSecurityPolicy_Operations#Get_Deployed_PodSecurityPolicies|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, [[Kubernetes_Security_Operations#Authorization_Check|has permission to use]], and the rest are ignored.
<font color=darkgray>
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.
</font>
==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 [[Kubernetes_Role_Based_Access_Control_Concepts#Cluster_Role|cluster role ]] or [[Kubernetes_Role_Based_Access_Control_Concepts#Role|role]] that allows the use of the policy:
<syntaxhighlight lang='yaml'>
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: [...]
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:    ['use']
  resourceNames: ['example']
</syntaxhighlight>
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: [[PodSecurityPolicy_Operations#Associate_a_PodSecurityPolicy_with_a_Service_Account|Associate a PodSecurityPolicy with a Service Account]].
==PodSecurityPolicy Operations==
{{Internal|PodSecurityPolicy Operations|PodSecurityPolicy Operations}}


=PodSecurityPolicy Admission Controller=
=PodSecurityPolicy Admission Controller=


More about admission controllers:{{Internal|Kubernetes Admission Controller Concepts|Kubernetes Admission Controller Concepts}}
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 [[Kubernetes_Pod_and_Container_Concepts#Security_Context|security context]] and the available [[#PodSecurityPolicy|PodSecurityPolicies]].
 
More about admission controllers and admission controller operations:{{Internal|Kubernetes Admission Controller Concepts|Kubernetes Admission Controller Concepts}}
{{Internal|Admission Controller Operations|Admission Controller Operations}}
 
=Pod Security Policy in EKS=
{{Internal|Amazon_EKS_Concepts#Pod_Security_Policy|EKS Concepts - Pod Security Policy}}

Latest revision as of 23:30, 11 July 2023

External

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:

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.png

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

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritypolicy-v1beta1-policy
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

https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies

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:

  1. 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.
  2. 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 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:

Kubernetes Admission Controller Concepts
Admission Controller Operations

Pod Security Policy in EKS

EKS Concepts - Pod Security Policy