Apply Security Context To Your Pods And Containers

More Info:

Security contexts constrain the privileges and access of pods and containers at runtime. Apply appropriate security contexts to all pods and containers.

Risk Level

Medium

Address

Security

Compliance Standards

• CIS AKS

Triage and Remediation

Remediation

Remediation

Manual Steps

1. List pods missing or with weak securityContext

   • Run on: any machine with kubectl access
   • Command:
     kubectl get pods --all-namespaces -o json \
       | jq -r '
         .items[]
         | select(
             # Pod-level securityContext absent or empty
             (.spec.securityContext // {} | length == 0)
             or
             # Any container without securityContext
             ( [.spec.containers[], (.spec.initContainers // [])[]]
               | map(select((.securityContext // {} | length == 0))) | length > 0
             )
           )
         | [.metadata.namespace, .metadata.name]
         | @tsv
       '
     

2. Gather full specs for candidate pods

   • Run on: any machine with kubectl access
   • For each <namespace> <pod> from step 1:
     kubectl get pod <pod-name> -n <namespace> -o yaml > pod-<namespace>-<pod-name>.yaml
     

3. Review current securityContext settings

   • Open each pod-*.yaml and check at both pod and container levels for (examples of what to look for; you must decide what is appropriate for your workloads):
     • Missing securityContext: blocks
     • Privilege-related fields: privileged, allowPrivilegeEscalation, capabilities.add/drop, runAsUser, runAsGroup, runAsNonRoot, readOnlyRootFilesystem, seLinuxOptions, seccompProfile, procMount, hostPID, hostIPC, hostNetwork, hostPorts.
   • Identify pods/containers that run with unnecessary or overly broad privileges relative to their function.

4. Decide appropriate securityContext per workload

   • For each pod/container, decide:
     • The minimal user/group IDs (runAsUser, runAsGroup, runAsNonRoot: true)
     • Whether privileged is truly needed; if not, set privileged: false
     • Whether allowPrivilegeEscalation can be disabled: allowPrivilegeEscalation: false
     • Required and removable Linux capabilities (capabilities.drop and capabilities.add)
     • Whether the root filesystem can be read-only: readOnlyRootFilesystem: true
     • Whether host namespaces/ports are truly required (avoid hostPID, hostIPC, hostNetwork, host ports where possible).
   • Use your application and Docker image requirements plus the CIS Docker Benchmark as guidance.

5. Implement securityContext via manifests (preferred) or live edit

   • If workloads are managed by manifests/Helm/Kustomize:
     • Edit the deployment/statefulset/daemonset/job manifests (not the pods directly) to add/adjust securityContext at pod spec and container spec levels according to step 4. Example pattern (adapt as needed for each workload):
       spec:
         securityContext:
           runAsNonRoot: true
           runAsUser: 1000
           runAsGroup: 1000
         containers:
           - name: <container-name>
             image: <image>
             securityContext:
               allowPrivilegeEscalation: false
               privileged: false
               readOnlyRootFilesystem: true
               capabilities:
                 drop: ["ALL"]
       
     • Apply changes:
       kubectl apply -f <manifest-file>.yaml
       
   • If a pod is not managed by higher-level controllers (e.g., a standalone pod for debugging):
     • Edit directly:
       kubectl edit pod <pod-name> -n <namespace>
       
     • Add/adjust the securityContext blocks as decided in step 4; save to recreate the pod.

6. Verify that security contexts are now applied

   • Re-run the evidence command and confirm no workload you intend to secure is listed:
     kubectl get pods --all-namespaces -o json \
       | jq -r '
         .items[]
         | select(
             (.spec.securityContext // {} | length == 0)
             or
             ( [.spec.containers[], (.spec.initContainers // [])[]]
               | map(select((.securityContext // {} | length == 0))) | length > 0
             )
           )
         | [.metadata.namespace, .metadata.name]
         | @tsv
       '
     
   • Spot-check a few pods:
     kubectl get pod <pod-name> -n <namespace> -o yaml | sed -n '/securityContext:/,/^ *[^ ]/p'
     
   • Confirm that the configured securityContext values match your decisions from step 4 and that applications still function as expected.

Using kubectl

# 1. List all pods and their securityContext at pod level
# Run on: any machine with kubectl access
kubectl get pods -A -o custom-columns=\
NAMESPACE:.metadata.namespace,\
POD:.metadata.name,\
POD_SC:.spec.securityContext \
| column -t

Problem indicators:

• POD_SC column is empty (<none> or {}) for pods that should have restricted settings.
• You see no common baseline (some pods with strict settings, others with none, without a clear reason).

# 2. Show container-level securityContext for all pods (summarized)
kubectl get pods -A -o jsonpath='
{@.items[*].metadata.namespace}{"\n"}{@.items[*].metadata.name}{"\n"}{@.items[*].spec.containers[*].name}{"\n"}{@.items[*].spec.containers[*].securityContext}{"\n---\n"}'

Problem indicators (per container):

• securityContext is missing (null/[]) or {} for workloads that handle sensitive data or run user code.
• Known risky patterns, for example:
  • "privileged": true
  • "runAsUser": 0 or "runAsNonRoot": false without a strong justification
  • "allowPrivilegeEscalation": true
  • Broad capabilities like "capAdd": ["ALL"] or many capabilities with no clear need
  • Host access options such as "hostNetwork": true, "hostPID": true, "hostIPC": true at pod spec level.

# 3. Inspect full spec for a specific pod with suspected issues
# Replace NAMESPACE and POD_NAME with actual values
kubectl get pod POD_NAME -n NAMESPACE -o yaml

What to look for in the YAML:

• Missing securityContext at both .spec.securityContext and .spec.containers[].securityContext.
• Any of:
  • privileged: true
  • runAsNonRoot: false or absent, combined with runAsUser: 0
  • allowPrivilegeEscalation: true or absent when the container has extra capabilities
  • capabilities.add including unnecessary or broad capabilities (e.g., SYS_ADMIN, NET_ADMIN, ALL)
  • hostNetwork: true, hostPID: true, hostIPC: true without a strict operational reason
  • readOnlyRootFilesystem: false or absent when the container does not need to write to the root FS.

# 4. Focus on pods most likely to be risky (privileged / host access)
kubectl get pods -A -o json | jq '
  .items[]
  | select(
      (.spec.containers[]?.securityContext.privileged == true)
      or (.spec.securityContext.privileged == true)
      or (.spec.hostNetwork == true)
      or (.spec.hostPID == true)
      or (.spec.hostIPC == true)
    )
  | {namespace: .metadata.namespace, name: .metadata.name,
     hostNetwork: .spec.hostNetwork,
     hostPID: .spec.hostPID,
     hostIPC: .spec.hostIPC,
     podSC: .spec.securityContext,
     containers: [.spec.containers[] | {name, sc: .securityContext}]}
'

Problem indicators:

• Any application pod (not a low-level node/cluster agent) appearing in this list without a clear operational need.
• Cluster-wide patterns where many pods use privileged mode or host namespace access.

# 5. Identify pods without any securityContext on containers
kubectl get pods -A -o json | jq '
  .items[]
  | {ns: .metadata.namespace, pod: .metadata.name,
     containers: [.spec.containers[] | {name, sc: .securityContext}]}
  | select( ([.containers[].sc] | all(. == null)) )
'

Problem indicators:

• Business‑critical or multi‑tenant workloads listed here; they likely need explicit securityContext settings instead of inheriting defaults.

Automation

#!/usr/bin/env bash
# Report pods and containers missing recommended securityContext fields
# Run on: any machine with kubectl access and a current kube-context

set -euo pipefail

# Namespace filter (optional). Leave empty for all namespaces.
NAMESPACE_FILTER=""

if [[ -n "${NAMESPACE_FILTER}" ]]; then
  NS_ARG="-n ${NAMESPACE_FILTER}"
else
  NS_ARG="--all-namespaces"
fi

echo "Collecting pod securityContext summary..."
echo "Timestamp: $(date -Iseconds)"
echo

# 1) High-level summary: pods/containers missing securityContext
kubectl get pods ${NS_ARG} -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        podSC: .spec.securityContext,
        containers: (
          (.spec.containers // [])
          + (.spec.initContainers // [])
          + (.spec.ephemeralContainers // [])
        )
      }
    | .containers[]
    | {
        ns: .ns,
        pod: .pod,
        cName: .name,
        cSC: .securityContext
      }
    | [
        .ns,
        .pod,
        .cName,
        (if .cSC == null then "MISSING_SC" else "HAS_SC" end)
      ]
    | @tsv
  ' \
  | sort -u \
  | awk -F'\t' '
      BEGIN {
        printf "NAMESPACE\tPOD\tCONTAINER\tSECURITY_CONTEXT\n"
      }
      {
        print
      }
    '

echo
echo "Detail for containers missing any securityContext (one line per container)..."
echo "Columns:"
echo "  NAMESPACE | POD | CONTAINER | privileged | runAsUser | runAsNonRoot | readOnlyRootFilesystem | allowPrivilegeEscalation | capabilities.add | capabilities.drop"
echo

kubectl get pods ${NS_ARG} -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        podSC: .spec.securityContext,
        containers: (
          (.spec.containers // [])
          + (.spec.initContainers // [])
          + (.spec.ephemeralContainers // [])
        )
      }
    | .containers[]
    | select(.securityContext == null)
    | {
        ns: .ns,
        pod: .pod,
        cName: .name,
        sc: .securityContext
      }
    | [
        .ns,
        .pod,
        .cName,
        ( .sc.privileged // "unset" ),
        ( .sc.runAsUser // "unset" ),
        ( .sc.runAsNonRoot // "unset" ),
        ( .sc.readOnlyRootFilesystem // "unset" ),
        ( .sc.allowPrivilegeEscalation // "unset" ),
        ( ( .sc.capabilities.add | join(",") ) // "unset" ),
        ( ( .sc.capabilities.drop | join(",") ) // "unset" )
      ]
    | @tsv
  ' \
  | sort -u

echo
echo "Detail for containers with a securityContext but missing specific restrictive fields..."
echo "Only pods where the container has securityContext but at least one key is unset."
echo

kubectl get pods ${NS_ARG} -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        containers: (
          (.spec.containers // [])
          + (.spec.initContainers // [])
          + (.spec.ephemeralContainers // [])
        )
      }
    | .containers[]
    | select(.securityContext != null)
    | {
        ns: .ns,
        pod: .pod,
        cName: .name,
        sc: .securityContext
      }
    | select(
        (.sc.privileged == null)
        or (.sc.runAsNonRoot == null)
        or (.sc.readOnlyRootFilesystem == null)
        or (.sc.allowPrivilegeEscalation == null)
        or (.sc.capabilities == null)
        or (.sc.capabilities.drop == null)
      )
    | [
        .ns,
        .pod,
        .cName,
        ( .sc.privileged // "unset" ),
        ( .sc.runAsUser // "unset" ),
        ( .sc.runAsNonRoot // "unset" ),
        ( .sc.readOnlyRootFilesystem // "unset" ),
        ( .sc.allowPrivilegeEscalation // "unset" ),
        ( ( .sc.capabilities.add | join(",") ) // "unset" ),
        ( ( .sc.capabilities.drop | join(",") ) // "unset" )
      ]
    | @tsv
  ' \
  | sort -u

echo
echo "NOTE: This script is read-only. It highlights pods/containers that:"
echo "  - have no container-level securityContext at all (MISSING_SC), or"
echo "  - have a securityContext but are missing key restrictive fields."
echo
echo "You must review each workload and decide appropriate securityContext values"
echo "based on its function and your risk tolerance; there is no one-size-fits-all fix."

How to interpret the output

• In the first table, any row with SECURITY_CONTEXT = MISSING_SC indicates a pod container with no securityContext defined at the container level. These need manual review and likely a securityContext added.
• In the second and third sections:
  • Lines listed indicate containers of interest.
  • Fields with unset mean that aspect is not configured and should be reviewed (for example, consider setting runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, and dropping capabilities where possible).
• Absence of rows in these sections means all containers have a securityContext and the inspected fields are set, but you still must review whether the chosen values are appropriate and restrictive enough.