Agent Security Context

The runAsUser, runAsGroup, and fsGroup settings define the Linux user and group IDs under which the agent's container processes execute. This is a fundamental principle of least privilege.

• runAsUser: Specifies the primary user ID (UID). A non-zero UID (e.g., 1000) is standard to avoid running as the privileged root user (UID 0).
• runAsGroup: Specifies the primary group ID (GID).
• fsGroup: Defines a special supplemental group applied to mounted volumes, ensuring the agent can read/write to persistent storage.

Example: Setting runAsUser: 1001 and runAsGroup: 1001 ensures the agent runs with minimal inherent privileges.

Linux Capabilities break the monolithic root privilege into distinct units, allowing an agent to be granted specific high-level privileges without full root access. The security context controls which capabilities are added or dropped.

• Default Drop: Best practice starts with dropping all capabilities (capDrop: ["ALL"]) and then adding only those explicitly required.
• Common Grants: An agent performing network diagnostics might need CAP_NET_RAW. A sidecar managing packet filtering might require CAP_NET_ADMIN.
• Critical to Drop: Capabilities like CAP_SYS_ADMIN (mount, swapon) or CAP_SYS_MODULE (load kernel modules) are highly privileged and should rarely, if ever, be granted to an agent.

Misconfigured capabilities are a primary vector for container escape.

These are boolean flags that represent extreme security states.

• privileged: When set to true, the agent container runs in privileged mode, effectively disabling most security boundaries. The container has almost all capabilities, ignores device restrictions, and can access host resources. Its use is highly discouraged outside of system-level agents (e.g., node monitoring DaemonSets).
• allowPrivilegeEscalation: This controls whether a process can gain more privileges than its parent (e.g., via setuid binaries). It should be set to false to prevent privilege escalation attacks, even if specific capabilities are granted. Setting privileged: true implicitly sets this to true.

These are Mandatory Access Control (MAC) systems that enforce kernel-level security policies beyond standard Linux Discretionary Access Control (DAC).

• SELinux: Uses security labels (e.g., selinuxOptions) to define a type enforcement policy. An agent can be assigned a specific context like container_t to restrict its access to files, ports, and processes labeled for containers.
• AppArmor: Enforces profiles via path-based rules. An agent's security context can specify an AppArmor profile (e.g., runtime/default or a custom profile like custom-agent-profile) that denies actions like raw socket access or writing to /proc.

These provide a critical second layer of defense, containing the agent even if other controls are bypassed.

Seccomp (Secure Computing Mode) restricts the system calls an agent's processes can make to the Linux kernel. It is the most granular form of syscall-level sandboxing.

• RuntimeDefault: The recommended profile, which provides a safe default set of allowed syscalls for containers.
• Localhost Profiles: Custom JSON profiles can be loaded from a node file to allow or deny specific syscalls. For example, a highly restricted agent could have a profile that denies clone, fork, and execve syscalls, preventing process spawning.
• Unconfined: Disables seccomp filtering (high risk).

Blocking unnecessary syscalls drastically reduces the attack surface available to a compromised agent.

The security context governs how an agent interacts with mounted filesystems and volumes.

• readOnlyRootFilesystem: A critical hardening setting. When true, the agent's root filesystem is mounted as read-only, preventing malicious code from writing to or modifying system binaries, libraries, or logs within the container image.
• fsGroup Change Behavior: As mentioned, the fsGroup modifies ownership of volumes to ensure writability, but this can be problematic for NFS or certain CSI drivers. The fsGroupChangePolicy can control this behavior.
• Volume SELinux Relabeling: For volumes like emptyDir, the seLinuxOptions can dictate if and how SELinux labels are applied to volume contents.

These controls ensure agents can only write to explicitly defined and sanctioned persistent storage locations.

Agent Role-Based Access Control (RBAC) is a security model that regulates what actions an agent's identity (its service account) can perform within the orchestration platform and on cluster resources.

• Bindings: Roles (collections of permissions) are bound to agent service accounts.
• Least Privilege: An agent should only have permissions necessary for its function (e.g., a monitoring agent may only get pods, not delete them).
• Cluster vs. Namespace: Roles can be cluster-wide (ClusterRole) or scoped to a specific namespace (Role).

RBAC defines the authorization layer, while the security context defines the operating system-level privileges (like user ID) the agent uses to execute those authorized actions.

Agent admission webhooks are HTTP callbacks that intercept requests to the orchestration API (like creating or updating a pod) to validate or mutate agent specifications before they are persisted.

• ValidatingWebhook: Checks if the incoming agent spec complies with security policies (e.g., runAsNonRoot: true, disallows privileged: true). Can reject the request.
• MutatingWebhook: Automatically modifies the agent spec to add security defaults (e.g., injecting a specific security context, setting resource limits) before creation.

This is a critical enforcement point for ensuring all agents in the system adhere to a baseline security context configuration.

These are Linux kernel security modules that provide granular, system-call-level confinement for containers, acting as a critical enforcement layer defined within the security context.

• Seccomp (Secure Computing Mode): Restricts the system calls an agent's process can make. A RuntimeDefault profile is commonly applied.
• AppArmor & SELinux: Mandatory Access Control (MAC) systems that define what files, network ports, and capabilities a process can access.
• Context Annotation: Profiles are specified in the security context (e.g., seccompProfile.type: RuntimeDefault).

Using these profiles significantly reduces the attack surface of a compromised agent by limiting its interaction with the host kernel.