Pod security policy is a commonly used method to verify the security of pod configurations before pods are deployed. This ensures that applications are running in secure pods. This topic describes how to create, manage, and associate pod security policies, and use pod security policies in Container Service for Kubernetes (ACK) clusters.
Usage notes
This topic describes how to manage pod security policies on the PSPs (earlier version) page in the ACK console. The PSPs (earlier version) page will soon be deprecated. For more information about how to manage pod security policies on the PSPs (new version) page, see Configure and enforce ACK pod security policies.
Background information
- Forced security verification: A pod security policy is a cluster-level resource of Kubernetes. Pod security policy control is implemented as an admission controller of the API server to verify the security of pod configurations before pods are deployed. If the pod configuration fails to meet the conditions that are defined in a specified pod security policy, the Kubernetes API server rejects the request to create the pod.
- Role-based access control (RBAC) bindings: To create pod security policies, you must enable the admission controller for pod security policies. Then, you must create RBAC bindings to authorize service accounts to use the pod security policies that you created.
- Pod security policy setting: By default, the pod security policy feature is automatically enabled for managed and dedicated Kubernetes clusters.
- Principle of least privilege: To ensure the compatibility of ACK clusters, a default
pod security policy named
ack.privileged
is automatically created and associated with each legitimate account. The policy enforces the principle of least privilege. For example, the default pod security policy may forbid specific users to deploy privileged pods, allow them to use only read-only root file systems, and allow them to mount host paths only within the specified range.
Prerequisites
- A managed Kubernetes cluster or a dedicated Kubernetes cluster is created, and the cluster version is 1.14.8-aliyun.1 or later. For more information, see Create an ACK managed cluster or Create an ACK dedicated cluster.
- Log on to the Container Service for Kubernetes (ACK) console console with your Alibaba Cloud account. You can also log on to the console as a RAM user after you grant administrator permissions to the RAM user. For more information, see Assign RBAC roles to RAM users.
- If you want to manage pod security policies as a RAM user, make sure that the RAM
user has the following permissions:
cs:DescribeClusterPSPState
: queries the status of the pod security policy feature for the cluster.cs:DescribeServiceAccountBindingPSP
: queries the pod security policy that is associated with a specifiedservice account
.cs:UpdateClusterPodSecurityPolicy
: updates a pod security policy.cs:CreatePSPBinding
: associates a pod security policy with a specifiedservice account
.cs:UnbindingServiceAccountPSP
: disassociates a pod security policy from a specifiedservice account
.
For more information about custom RAM policies, see Create a custom RAM policy.
Create a pod security policy
Associate a pod security policy with service accounts
Error from server (Forbidden): error when creating xxx: pods "xxx" is forbidden: unable to validate against any pod security policy: []
You can associate a pod security policy with a specified service account or all service
accounts in a specified namespace. - Log on to the ACK console.
- In the left-side navigation pane of the ACK console, click Clusters.
- On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
- In the left-side navigation pane of the cluster page, choose .
- Click the Association Rules tab and click Add Association Rule.
- In the Add Association Rule panel, specify Namespace, Account, and PSP.
- Click OK.
Disassociate the default pod security policy
- When the system disassociates the default pod security policy, the system authorizes
all service accounts in the kube-system namespace and the
system:nodes
user group to use the default pod security policy. This ensures that the system components and containers run as normal. - All service accounts in a namespace are authorized to use the default pod security policy if no custom pod security policy is associated with the namespace. This ensures that the containers in the namespace run as normal.
- For a namespace in which service accounts are associated with a custom pod security
policy:
To make the custom pod security policy take effect, after you disassociate the default pod security policy, the services accounts are not authorized to use the default pod security policy. Therefore, before you disassociate the default pod security policy, make sure that the service accounts in the namespace are associated with the desired custom pod security policy.
- For a namespace that is newly created:
The system does not automatically associate the default pod security policy with service accounts in the newly created namespace. Therefore, after you create a namespace, you must create a custom pod security policy and associate it with service accounts in the namespace at the earliest opportunity.
- Log on to the ACK console.
- In the left-side navigation pane of the ACK console, click Clusters.
- On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
- In the left-side navigation pane of the cluster page, choose .
- In the PSP Management Guide section, click Disassociate Default PSP.
- In the Disassociate message, click OK.
Enable the admission controller for pod security policies
By default, ACK automatically enables the admission controller for newly created clusters. To make custom pod security policies take effect within a cluster, enable the admission controller for the API server of the cluster.
Default pod security policy
By default, pod security policy control is enabled for standard managed Kubernetes clusters of version 1.16.6 and standard dedicated Kubernetes clusters of version 1.16.6. A default pod security policy named ack.privileged is automatically created for these clusters. The default pod security policy accepts all types of pods. This provides the same effect as when pod security policy control is disabled for the cluster.
kubectl get psp ack.privileged NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES ack.privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *
kubectl describe psp ack.privileged Name: ack.privileged Settings: Allow Privileged: true Allow Privilege Escalation: true Default Add Capabilities: <none> Required Drop Capabilities: <none> Allowed Capabilities: * Allowed Volume Types: * Allow Host Network: true Allow Host Ports: 0-65535 Allow Host PID: true Allow Host IPC: true Read Only Root Filesystem: false SELinux Context Strategy: RunAsAny User: <none> Role: <none> Type: <none> Level: <none> Run As User Strategy: RunAsAny Ranges: <none> FSGroup Strategy: RunAsAny Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>
--- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: ack.privileged annotations: kubernetes.io/description: 'privileged allows full unrestricted access to pod features, as if the PodSecurityPolicy controller was not enabled.' seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy spec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny' readOnlyRootFilesystem: false --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ack:podsecuritypolicy:privileged labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy rules: - apiGroups: - policy resourceNames: - ack.privileged resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ack:podsecuritypolicy:authenticated annotations: kubernetes.io/description: 'Allow all authenticated users to create privileged pods.' labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ack:podsecuritypolicy:privileged subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated
Delete the ClusterRoleBinding resource that is related to the default pod security policy
cat <<EOF | kubectl delete -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ack:podsecuritypolicy:authenticated annotations: kubernetes.io/description: 'Allow all authenticated users to create privileged pods.' labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ack:podsecuritypolicy:privileged subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated EOF
Configure or restore the default pod security policy
After you enable the custom pod security policy, you can run the following code to configure or restore the default pod security policy.
cat <<EOF | kubectl apply -f - --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: ack.privileged annotations: kubernetes.io/description: 'privileged allows full unrestricted access to pod features, as if the PodSecurityPolicy controller was not enabled.' seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy spec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny' readOnlyRootFilesystem: false --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ack:podsecuritypolicy:privileged labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy rules: - apiGroups: - policy resourceNames: - ack.privileged resources: - podsecuritypolicies verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ack:podsecuritypolicy:authenticated annotations: kubernetes.io/description: 'Allow all authenticated users to create privileged pods.' labels: kubernetes.io/cluster-service: "true" ack.alicloud.com/component: pod-security-policy roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ack:podsecuritypolicy:privileged subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated EOF
Verify the pod security policy
The following example shows how a pod security policy is created, associated with service accounts, and then enforced.