Baseline profile — preventing known privilege escalations

The baseline profile is the middle ground: it forbids the most common privilege escalations while allowing common operational patterns. It is the right choice for multi-tenant clusters and untrusted workloads; production clusters should migrate to restricted where possible.

What baseline forbids

The baseline profile is the floor for hardening; it prevents the well-known escalation paths.

What baseline allows

These fields are allowed because they are common in operational workloads. The restricted profile tightens each one.

A baseline manifest

A Pod that passes baseline but fails restricted:

apiVersion: v1
kind: Pod
metadata:
  name: ci-runner
  namespace: ci
spec:
  securityContext:
    runAsUser: 0              # baseline: allowed
    fsGroup: 1000
  containers:
  - name: runner
    image: ci-runner:v1.0
    securityContext:
      allowPrivilegeEscalation: true  # baseline: allowed
      capabilities:
        add: ["NET_ADMIN"]    # baseline: allowed (NET_ADMIN is not on the forbidden list)
    volumeMounts:
    - name: workspace
      mountPath: /workspace
    - name: cache
      mountPath: /cache
  volumes:
  - name: workspace
    emptyDir: {}
  - name: cache
    hostPath:
      path: /var/cache/ci       # baseline: allowed (specific path)
      type: Directory

The Pod is admitted in ci (enforce: baseline). In prod (enforce: restricted), it would be rejected for: running as root with no runAsNonRoot, allowPrivilegeEscalation: true, the NET_ADMIN capability without drop: ["ALL"], the hostPath volume, and the missing seccompProfile.

A baseline with restricted migration plan

The baseline profile is a step on the way to restricted. The migration:

1. warn: restricted. Surface the violations without rejecting workloads.
2. Fix the small violations. Add runAsNonRoot: true, seccompProfile: RuntimeDefault.
3. Fix the medium violations. Replace hostPath with CSI volumes; remove root.
4. Switch to audit: restricted. Capture remaining violations in the audit log.
5. Switch to enforce: restricted. Reject the remaining violations.

The migration is per-namespace; the team tracks each namespace’s progress in a spreadsheet.

Production patterns

1. baseline for multi-tenant. Untrusted workloads run with baseline. The discipline is no privileged, no host namespaces.
2. baseline as a transition. Workloads that cannot pass restricted run with baseline temporarily. The team has a deadline to migrate.
3. baseline for build runners. CI runners need hostPath for cache mounts and broad capabilities for tooling. baseline allows them; restricted does not.

Production failure modes

1. A workload uses privileged: true in a baseline namespace. The Pod is rejected; the team changes the namespace to privileged to “fix” it. The fix is to remove the field, not to relax the namespace’s PSS.
2. A hostPath to a non-allowed path. The Pod is rejected in baseline. The fix is to use emptyDir or a CSI volume.
3. hostNetwork: true on a workload that does not need it. The Pod is rejected in baseline. The fix is to remove the field.
4. No migration to restricted. A namespace stays on baseline indefinitely. The fix is to set a migration deadline per namespace.

Cross-course references

• The Observability course covers the audit log entries for baseline violations.
• The Linux course covers the kernel features that baseline enforces.

Quiz

Production discipline

The baseline profile is the right choice for multi-tenant clusters and as a transition to restricted. The discipline is to default to restricted for trusted workloads, use baseline for untrusted or transitional workloads, and document every namespace that is on baseline. A cluster whose namespaces are mostly restricted and has documented baseline exceptions has a PSS programme that is auditable.