Skip to main content

More Info:

SecurityContexts constrain the privileges and capabilities of pods and containers. Apply them to harden workloads.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify pods lacking a securityContext
    • Run on: any machine with kubectl access
    • Command:
    • This lists pods where neither the pod nor any containers define a securityContext.
  2. Review current security settings for selected pods
    • Pick a workload (preferably from a non-system namespace) from the list above.
    • Command:
    • Inspect .spec.securityContext and each .spec.containers[].securityContext for settings such as runAsNonRoot, runAsUser, runAsGroup, readOnlyRootFilesystem, allowPrivilegeEscalation, and capabilities.
  3. Decide required hardening based on workload needs
    • For each application/team owning the pods, determine:
      • Whether the container can run as non-root (runAsNonRoot: true, non-0 runAsUser).
      • Whether it needs write access to root filesystem (if not, readOnlyRootFilesystem: true).
      • Whether it needs extra Linux capabilities (drop all, then selectively add if required).
      • Whether privilege escalation is needed (allowPrivilegeEscalation: false if not).
    • Collect inputs from the app owners before changing manifests.
  4. Update manifests to include appropriate securityContext
    • Retrieve the controller manifest (Deployment/StatefulSet/Job/etc.):
    • Edit deployment-secctx.yaml to add security contexts, for example:
    • Apply the updated manifest:
    • Repeat with other controllers (StatefulSets, DaemonSets, Jobs, CronJobs) rather than editing pods directly.
  5. Handle pods not managed by higher-level controllers
    • List standalone pods (no ownerReferences):
    • For any long-lived standalone pod you intend to keep, recreate it from a manifest that includes a securityContext; avoid using kubectl run without saving and hardening the YAML first.
  6. Verify that security contexts are now applied
    • Re-run the initial check:
    • Confirm that all non-exempt workloads (per your policy) no longer appear in the output and spot-check a few pods with kubectl get pod -n NAMESPACE PODNAME -o yaml to ensure the intended securityContext settings are present.

Using kubectl

1. List pods that have no pod-level securityContext

Run on: any machine with kubectl access.
Indication of a problem:
Any lines in the output are pods that do not define a pod-level securityContext at all and should be manually reviewed. Lack of a pod-level securityContext is a red flag, especially for non-system namespaces.

2. List containers without a container-level securityContext

Indication of a problem:
Any line in the output shows a pod where one or more regular or init containers do not define a securityContext. These containers must be reviewed to determine if explicit restrictions are needed (usually yes).

3. Inspect a specific pod in detail

Replace <namespace> and <pod-name>.
Focus your manual review on:
  • .spec.securityContext
  • .spec.containers[].securityContext
  • .spec.initContainers[].securityContext
Indication of a problem:
You see missing or overly-permissive fields such as:
  • No securityContext at all at pod or container level.
  • runAsUser: 0 or runAsNonRoot: false (or not set where non-root is expected).
  • privileged: true.
  • allowPrivilegeEscalation: true or not set.
  • capabilities.add including dangerous capabilities (e.g., SYS_ADMIN, NET_ADMIN).
  • hostNetwork: true, hostPID: true, hostIPC: true without a clear, documented reason.
  • readOnlyRootFilesystem: false (or missing) where a read-only root FS is possible.
These require human judgement to determine if the privilege level is justified.

4. Quickly surface some high‑risk patterns

a. Pods using privileged containers
Problem indication: Any output shows containers running in privileged mode, which is usually a serious concern unless explicitly required.
b. Pods allowing privilege escalation
Problem indication: Any output shows containers explicitly allowing privilege escalation. This is typically not desired.
c. Pods running containers as root (explicitly)
Problem indication: Any output shows containers explicitly configured to run as UID 0. This should be justified and usually avoided.(Note: many images run as root implicitly; this command only catches explicit runAsUser: 0. Determining implicit root requires image review, not just kubectl.)

5. Verification after you update manifests

After you manually adjust pod or deployment manifests to add appropriate securityContext settings, re-run:
  • The “no pod-level securityContext” command (step 1).
  • The “containers without securityContext” command (step 2).
  • Any specific high-risk pattern commands you are targeting (step 4).
Verification success criteria:
  • The previously flagged pods/containers no longer appear in the outputs, and
  • A kubectl get pod <pod> -n <ns> -o yaml shows the intended securityContext fields applied.