Agent Container Security Context, Seccomp, and Capabilities

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

Container security context evidence tells agents whether a failure comes from code, runtime permissions, blocked system calls, or an over-broad privilege setting.

## Core Explanation

Agents often see container failures as permission errors, mount errors, network errors, or unexplained process exits. Security context settings and seccomp profiles can be the root cause even when the application code is unchanged.

Useful evidence includes the Pod spec, container securityContext, effective user and group, capabilities added or dropped, privileged mode, read-only root filesystem, seccomp profile, runtime class, admission policy, and recent deployment changes. Agents should separate least-privilege remediation from broad privilege escalation.

## Source-Mapped Facts

- Kubernetes documentation says a security context defines privilege and access control settings for a Pod or Container. ([source](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/))
- Kubernetes documentation says Pod-level securityContext settings apply to all containers in the Pod. ([source](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/))
- Docker documentation describes seccomp as a Linux kernel feature that can restrict actions available within a container. ([source](https://docs.docker.com/engine/security/seccomp/))

## Further Reading

- [Kubernetes Configure a Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
- [Docker Seccomp Security Profiles](https://docs.docker.com/engine/security/seccomp/)