Kubernetes Pod Security Policy Concepts: Difference between revisions
| Line 68: | Line 68: | ||
<code>allowedProcMountTypes</code>, <code>forbiddenSysctls</code>, <code>allowedUnsafeSysctls</code> | <code>allowedProcMountTypes</code>, <code>forbiddenSysctls</code>, <code>allowedUnsafeSysctls</code> | ||
==Multiple PodSecurityPolicies== | ==Multiple PodSecurityPolicies== | ||
When multiple policies are available, the access controller selects policies 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. | |||
==PodSecurityPolicy Operations== | ==PodSecurityPolicy Operations== | ||
Revision as of 03:23, 3 September 2020
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 an example of a Kubernetes policy.
Pod security policy is 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 policy controls security sensitive aspects of the pod specification. 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 enabled, otherwise the admission controller will prevent any pods from being created in the cluster. The PodSecurityPolicies can be deployed before enabling the admission controller, and this is the recommended sequence. When multiple PodSecurityPolicies are available, the access controller selects the effective policy as described here: Multiple PodSecurityPolicies.
To be used, a specific PodSecurityPolicy must be associated with either users or the target pods' service accounts, via a role and a binding. 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.
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:
- '*'
PodSecurityPolicy Controlled Aspects and Fields
Capability of Enabling Privileged Mode
privileged
Access to Host Namespaces
hostPID, hostIPC, hostNetwork, hostPorts.
Specification of Accepted Volume Types and File System Access Control
volumes, allowedHostPaths, allowedFlexVolumes, fsGroup, readOnlyRootFilesystem
User and Group Control
runAsUser, runAsGroup, supplementalGroups
Privilege Escalation Control
allowPrivilegeEscalation, defaultAllowPrivilegeEscalation
Linux Capabilities
defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities
SELinux Configuration
seLinux
Others
allowedProcMountTypes, forbiddenSysctls, allowedUnsafeSysctls
Multiple PodSecurityPolicies
When multiple policies are available, the access controller selects policies 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.
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: