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.

 
To summarize:
 

• 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:
 

--enable-admission-plugins=...,PodSecurityPolicy

 
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:

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

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:

deploy-not-privileged.yaml
 

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:

deploy-privileged.yaml
 

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[0].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'.
 

summary

 
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.