This article comes from Rancher Labs
What is Pod security policy?
Kubernetes Pod security policy (PSP) is an important component of kubernetes security section. Pod security policy is a cluster level resource, used to control pod security related options, and also a mechanism to enhance kubernetes workload security. Kubernetes platform team or cluster operation and maintenance personnel can use it to control the creation of pod and limit the functions available to specific users, groups or applications.
For a simple example, with PSP you can:
Prevent privileged Pod from starting and control privilege escalation.
Restrict the host namespace, network, and file system that Pod can access
Limit the users / groups that can run the pod.
Limit the volumes that Pod can access
- Restrict other parameters, such as runtime profiles or read-only root file systems
In this article, we will show you how to enhance your Kubernetes security in Rancher by enabling a simple Pod security policy.
Can Pod security policy really enhance K8S security?
Yes, the Pod security policy does enhance the security of Kubernetes. It provides Kubernetes native control mechanism, which can prevent threats without affecting performance, which is different from the agent must intercept every action on the host.
If you have not enabled PSP in the cluster (or perform an equivalent method such as access control), Kubernetes users may generate a privileged cluster. This can be exploited maliciously, such as promoting privileges to break through container isolation and access other Pod / services.
If there is no mechanism to restrict the privilege of Pod spec, * * * person can perform any operation through the docker command, such as running privilege container, using node resources, etc.
To quickly verify the above statement, you can execute the following script (never operate on the production cluster):
❯ ./kubectl-root-in-host.sh bash-4.4# whoami root bash-4.4# hostname sudo--alvaro-rancher-rancheragent-0-all
You can get immediate root access to the Kubernetes node. Is it a little afraid?
By following the concept of minimum privileges, you can safely implement PSP in a cluster and make sure that you don't have unnecessary permissions in the Kubernetes Pod or workload. In addition to the core concept of Kubernetes security, the principle of minimum privilege is a common security best practice, and also the core requirement of compliance standards such as PCI, SOC2 or HIPAA.
PSP will provide default security constraints for the security functions granted by pod, which can be created by any user on the cluster
- PSP can also help you verify compliance by meeting specific compliance benchmarks
Minimum privilege is a concept as well as a practice, which can restrict the access rights of users, accounts and calculation processes to only the resources needed for daily legal activities.
Enable Pod security policy in your cluster
In Kubernetes, the Pod security policy can be implemented as the permission controller. To enable PSP in your cluster, make sure that PodSecurityPolicy is in the enable admission plugins list and passed as a parameter to your Kubernetes API configuration parameter:
Cloud providers that host Kubernetes clusters (you can't directly access the API configuration) usually provide advanced settings that allow users to enable PSP across the entire cluster. In other cases, you may need to edit the / etc / kubernets / manifests / kube-apiserver.yaml file and add it to the corresponding command parameters.
In Rancher, you can edit the cluster on the UI to enable PSP easily:
You can choose which Pod security policy to apply by default. In this case, we chose restricted.
The advantage of using an access controller to enable PSP is that it provides an immediate prevention mechanism, and even stops deploying overly privileged pods before scheduling. The disadvantage is that after you enable a PSP, each pod needs to be approved by the PSP, making its deployment and transition more difficult.
Enable basic Pod security policy demo in Rancher
In this section, we will step-by-step demonstrate how to enable the Pod security policy in the cluster through the Rancher dashboard, use the restricted policy by default, and learn how to prevent the creation of privileged pods.
The PSP object itself is a list of requirements and constraints to be applied to the pod specs. PSP YAML is as follows:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: allowedCapabilities: - NET_ADMIN - IPC_LOCK allowedHostPaths: - pathPrefix: /dev - pathPrefix: /run - pathPrefix: / fsGroup: rule: RunAsAny hostNetwork: true seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny privileged: true runAsUser: rule: RunAsAny volumes: - hostPath - secret
The above PSP S have many permissions, such as:
It allows pod to run with other Linux features such as net admin and IPC lock
It allows sensitive paths to be installed from the host
- Pod can run as privilege
Browse the official Kubernetes documentation for a complete list of available PSP controls and their default values:
Let's look at an example of how to prevent privileged Pod from running in a cluster.
After enabling PSP in the cluster, try to deploy a similar pod:
apiVersion: apps/v1 kind: Deployment metadata: labels: app: not-privileged-deploy name: not-privileged-deploy spec: replicas: 1 selector: matchLabels: app: not-privileged-deploy template: metadata: labels: app: not-privileged-deploy spec: containers: - image: alpine name: alpine stdin: true tty: true securityContext: runAsUser: 1000 runAsGroup: 1000
It can be used immediately because we told Rancher to enable PSP with restricted security policy, which allows unprivileged pod to operate normally, as above.
Check the contents of the default PSP as follows:
$ kubectl get psp restricted-psp -o yaml
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: annotations: serviceaccount.cluster.cattle.io/pod-security: restricted serviceaccount.cluster.cattle.io/pod-security-version: "1960" creationTimestamp: "2020-03-04T19:56:10Z" labels: cattle.io/creator: norman name: restricted-psp resourceVersion: "2686" selfLink: /apis/policy/v1beta1/podsecuritypolicies/restricted-psp uid: 40957380-1d44-4e43-9333-91610e3fc079 spec: allowPrivilegeEscalation: false fsGroup: ranges: - max: 65535 min: 1 rule: MustRunAs requiredDropCapabilities: - ALL runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: ranges: - max: 65535 min: 1 rule: MustRunAs volumes: - configMap - emptyDir - projected - secret - downwardAPI - persistentVolumeClaim
Or in Rancher's global perspective. Select [Security > pod security policy] and click the restricted option.
The PSP should allow any pod as long as it is running as a standard user (not root) and does not require any privileges or special features.
Other content about PSP and RBAC will be discussed later. For the sake of simplicity, add that Rancher has set up the necessary bindings for you, so let's skip this section now. Let's try to deploy a privileged pod, such as the one from the kubectl root in host.sh script:
apiVersion: apps/v1 kind: Deployment metadata: labels: app: privileged-deploy name: privileged-deploy spec: replicas: 1 selector: matchLabels: app: privileged-deploy template: metadata: labels: app: privileged-deploy spec: containers: - image: alpine name: alpine stdin: true tty: true securityContext: privileged: true hostPID: true hostNetwork: true
The pod will not enter the cluster
Warning FailedCreate 2s (x12 over 13s) replicaset-controller Error creating: pods "privileged-deploy-7569b9969d-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.containers.securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
The PodSecurityPolicy admission controller will not allow this pod to be created because the existing PSP does not allow the use of 'hostPID', 'hostNetwork', or 'privileged'.
In this article, we enhance your Kubernetes security by enabling a simple pod security policy in the Rancher environment. By using the default restricted PSP, we ensure that the pod can only run without the need to extend security permissions. Finally, we tried to deploy a pod with many permissions and failed because the existing PSP prevented it from being scheduled to the cluster.
The Rancher Kubernetes platform has more than 100 million downloads, and we know the importance of security issues for users. Later, we will also launch more security related content to help Rancher users land in Kubernetes safely and safely.