Kubernetes Security Context Checklist

Start with the workload’s actual needs

Ask which user the image runs as, which paths it writes, and whether it needs any Linux capabilities. A web application that writes temporary files has different requirements from an agent that inspects a host. Record the reason for each exception in the review. This gives the next engineer something more useful than an unexplained suppression.

For a typical Linux application container, review runAsNonRoot, allowPrivilegeEscalation, capabilities, and the root filesystem setting. Container and Pod security contexts have different scopes, so place each field at the correct level. The Kubernetes security context reference explains those distinctions.

Make privileges explicit

This fragment illustrates restrictions for an application that already supports a non-root user. It is not a complete Deployment. Check the image’s user and writable directories before applying it.

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

A read-only root filesystem can expose an undocumented dependency on a cache or temporary directory. Give the application a deliberately mounted writable path where needed; do not add broad host access simply to make the error disappear. Test startup and a representative request that writes data.

Review resources against observed behavior

Requests influence scheduling, while limits constrain resource use. CPU limits can throttle work; a memory limit can lead to termination when the workload exceeds it. Copying the same values into every service can hide capacity problems rather than solve them.

Use measurements from a representative environment to propose initial requests and limits. Include a burst, a slow downstream dependency, and the largest expected request. Check whether the workload remains healthy and whether its latency is acceptable. Read Kubernetes resource management for the behavior of requests and limits.

Separate readiness from recovery

A readiness probe determines whether a container should receive traffic. A liveness probe can restart it. A startup probe allows a slow-starting application to initialize before the other probes take over. Using one endpoint for all three without considering these meanings can create a restart loop during an outage.

Choose signals that match the failure you want to detect. Test a slow startup and a temporary dependency failure. Watch both probe events and request behavior, not just whether the Pod becomes Running. The official probe guide describes the controls and their consequences.

Turn the review into a small, testable change

1. Capture the manifest and image version you reviewed.
2. Resolve one related group of findings, such as process privileges.
3. Inspect the diff and deploy to a representative test environment.
4. Confirm startup, traffic handling, writes, and rollback behavior.
5. Repeat the scan and record any accepted exception with its reason.

Sentinel can surface configuration findings with their file context and show supported fix previews. It does not establish that a running cluster is secure or that a workload can tolerate a particular change. Keep runtime tests and human review in the workflow. See Sentinel’s processing and permission boundaries before connecting a repository.