Pod Security Policies

Pod Security Policies (PSP) enable fine-grained authorization of pod creation and updates.

REMOVED FEATURE

PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using Pod Security Admission (PSA).

What is a Pod Security Policy?

A Pod Security Policy (PSP) is a cluster-level resource that controls security sensitive aspects of the pod specification (like root privileges). The PodSecurityPolicy objects define a set of conditions that a pod must run in order to be accepted into the system, as well as defaults for the related fields. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start.

BEST PRACTICE: Set pod security at the cluster level.

Read more about Pod Security Policies in this article of the Kubernetes documentation.

Default Pod Security Policies

Kublr ships with two default Pod Security Policies (PSPs): restricted and privileged policies.

• restricted This policy is based on the Kubernetes example restricted policy. It significantly restricts what types of pods can be deployed to a cluster. This policy:
  • Prevents pods from running as a privileged user and prevents escalation of privileges
  • Validates that server-required security mechanisms are in place (such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added)
• privileged This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.

The default Kublr installation goes with privileged Pod Security Policy enabled.

It also has 2 Cluster Roles:

• psp:privileged that uses privileged Pod Security Policy
• psp:restricted that uses restricted Pod Securily Polycy

psp:privileged - Cluster Role binds to all service accounts in the namespace kube-system and we do not recommend changing this behaviour. By default it also binds to all service accounts in the cluster, so all service accounts use privileged Pod Security Policy if other not specified.

psp:restricted - Cluster Role to bind service accounts to restricted mode. (Not used by default)

In order to have more secure cluster you should deploy it with default role psp:restricted. To do that use cluster specification:

  kublrAgentConfig:
    kublr:
      psp:
        default_clusterrole: 'psp:restricted'

Another value in default_clusterrole is psp:privileged (used by default) will deploy cluster without any restriction.

Operations with Pod Security Policies in Secure Kublr Cluster

While running secure cluster with ‘restricted’ Pod Security Policy, you may want to run the application in privileged mode. For example, you need use a Jenkins Kubernetes plugin for running JNLP slave agents in a Kublr cluster. In this case, your Jenkins will need to use privileged PSP. By default Jenkins create Role in the namespace where agents are running. This role is used to allow Jenkins scheduling of agents via a Kubernetes plugin. You can extend this role to allow the use of a privileged PSP and bind this role to Jenkins ServiceAccount:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: jenkins-schedule-agents
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods", "pods/exec", "pods/log"]
  verbs: ["*"]
- apiGroups: ['policy']
  resources: ["podsecuritypolicies"]
  resourceNames: ["privileged"]
  verbs: ["use"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-schedule-agents
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: jenkins-schedule-agents
subjects:
- kind: ServiceAccount
  name: ${jenkins.serviceAccountName}
  namespace: ${jenkins.Namespace}

See Also

• Kubernetes documentation: Pod Security Policies overview.
• This documentation: Kublr Pod Security Policy option description.