Configure security context¶

Type: How-To (Task-oriented)

Difficulty: Intermediate

Time: 10 minutes

This guide shows you how to harden backend and frontend pods by setting a Kubernetes container security context through cdk8s-plone. Use it when your cluster enforces Pod Security Standards, when an admission webhook rejects permissive pods, or when you want to apply least-privilege defaults.

Prerequisites¶

A working Plone deployment using cdk8s-plone.
A Plone image that runs as a non-root user (the official plone/plone-backend and plone/plone-frontend images do).
Cluster knowledge of any namespace-level Pod Security Standards in effect.

Apply a baseline hardened context¶

Set securityContext on backend or frontend (or both).

import { Plone, PloneVariant } from '@bluedynamics/cdk8s-plone';

new Plone(chart, 'plone', {
  variant: PloneVariant.VOLTO,
  backend: {
    image: 'plone/plone-backend:6.1.3',
    securityContext: {
      runAsNonRoot: true,
      allowPrivilegeEscalation: false,
      capabilities: {
        drop: ['ALL'],
      },
    },
  },
  frontend: {
    image: 'plone/plone-frontend:16.0.0',
    securityContext: {
      runAsNonRoot: true,
      allowPrivilegeEscalation: false,
      capabilities: {
        drop: ['ALL'],
      },
    },
  },
});

These four settings satisfy the Kubernetes restricted Pod Security Standard for containers that do not need extra capabilities.

Pin the UID and GID¶

If your cluster requires explicit user and group IDs (for example, when you mount shared volumes), set them:

backend: {
  image: 'plone/plone-backend:6.1.3',
  securityContext: {
    runAsUser: 500,
    runAsGroup: 500,
    runAsNonRoot: true,
  },
}

The official Plone backend image already uses UID 500. Match that UID to keep file permissions consistent with the image.

Mount the root filesystem read-only¶

backend: {
  image: 'plone/plone-backend:6.1.3',
  securityContext: {
    runAsNonRoot: true,
    readOnlyRootFilesystem: true,
    allowPrivilegeEscalation: false,
    capabilities: {
      drop: ['ALL'],
    },
  },
}

Warning

A read-only root filesystem breaks any container that writes outside mounted volumes. Plone’s Zope writes temporary files; verify the pod stays Ready after rollout. Mount writable emptyDir volumes for /tmp and the Zope var/ directory through podAnnotations or the underlying Deployment patches if you hit EROFS errors.

Add a specific capability¶

When you must add a Linux capability, drop everything else first.

backend: {
  image: 'plone/plone-backend:6.1.3',
  securityContext: {
    runAsNonRoot: true,
    allowPrivilegeEscalation: false,
    capabilities: {
      add: ['SYS_PTRACE'],
      drop: ['ALL'],
    },
  },
}

Verify the rollout¶

# Generate manifests
cdk8s synth

# Confirm the securityContext appears on the pod template
grep -A 10 securityContext dist/*.yaml

# Apply and check pod status
kubectl apply -f dist/
kubectl rollout status deployment/<plone-backend-deployment> -n <namespace>

# Inspect the running container
kubectl exec -n <namespace> deployment/<plone-backend-deployment> -- id

A pod that fails to start with CreateContainerConfigError or permission denied usually points to a UID, capability, or read-only conflict.