Pod Security Admission for CloudBees CI on modern cloud platforms

Pod Security Policy (PSP) was deprecated in Kubernetes 1.21 and removed from Kubernetes 1.25. As an alternative, you can enforce Pod Security Standards by using Pod Security Admission (PSA). To migrate from PSP to PSA, refer to the Kubernetes migration instructions. There are also PSA configuration changes required for the following:

Operations center
Controller
Kubernetes build agents
Hibernation monitor
Ingress controller

These changes target the restricted Pod Security Standard.

Configure PSA for operations center

Configure the operations center pod with the required ContainerSecurityContext from the values.yaml. Refer to the following example:

ContainerSecurityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault▼

Configure PSA for controllers

Apply the following configuration to each controller in the YAML field of the controller item configuration page in the operations center.

kind: StatefulSet
apiVersion: apps/v1
spec:
  template:
    spec:
      containers:
      - securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        name: "jenkins"▼

Figure 1. Configure PSA on controller item configuration page

You can also apply this configuration at the global level in the operations center in the Default YAML area of the Configure Controller Provisioning page. However, that default configuration only applies to newly created controllers and not to existing ones.

Figure 2. Global PSA configuration on the Configure Controller Provisioning page

Configure PSA for Kubernetes build agents

All containers in build agents running in Kubernetes need to define the expected container securityContext in the values.yaml. Refer to the following example.

apiVersion: "v1"
kind: "Pod"
spec:
  containers:
  - name: <container_name>
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault▼

Kubernetes build agents (provisioned by the kubernetes Jenkins plugin) have a default container injected transparently. It is the jnlp container. This container needs to be overridden to add the securityContext configuration. Apart from the user-defined containers, there must be an override for the jnlp container too:

  containers:
  - name: jnlp (1)
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault▼

1	`jnlp` is a reserved container name used by the Kubernetes plugin.

For Windows agents, most of the securityContext values are not supported and must be omitted. PSA allows that for compatibility, as long as .spec.os.name is set to windows. Refer to Windows containers in Kubernetes for more information.

PSA for the hibernation monitor

If the Hibernation Monitor is enabled, configure SecurityContext in the values.yaml file. Refer to the following example:

Hibernation:
  Enabled: true
  SecurityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop:
      - ALL
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault▼

Configure PSA for the Ingress controller

ingress-nginx does not currently support PSA (refer to Deprecate PSP and use PSA for more information). Therefore, if ingress-nginx is installed using the deprecated built-in chart (where CloudBees CI uses ingress-nginx.Enabled: true in values.yaml), then PSA cannot be enabled. The solution is to install the ingress controller separately in another namespace (instead of using the CloudBees CI chart inline install) and not enable PSA on that namespace.

In August 2020, the Jenkins project voted to replace the term master with controller. We have taken a pragmatic approach to cleaning these up, ensuring the least amount of downstream impact as possible. CloudBees is committed to ensuring a culture and environment of inclusiveness and acceptance - this includes ensuring the changes are not just cosmetic ones, but pervasive. As this change happens, please note that the term master has been replaced through the latest versions of the CloudBees documentation with controller (as in managed controller, client controller, team controller) except when still used in the UI or in code.