Skip to main content
Version: main 🚧

Configure security context

Security context is one of the common agent configurations. Agent pods support multiple levels of security context configuration.

Security Context Precedence

When multiple security contexts are configured, the agent uses this precedence order (highest to lowest):

  1. Cluster-specific agentValues (via loft.sh/agent-values annotation)
  2. Platform-wide agentValues (in platform values.yaml)
  3. Platform default securityContext and podSecurityContext

See Platform configuration for platform-wide settings.

Inspect the security context applied to agent pods:

Modify the following with your specific values to generate a copyable command:
View security contexts
kubectl get pod -n vcluster-platform -l app=loft -o yaml | grep -A 10 "securityContext:"

Example output:

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
privileged: false
runAsNonRoot: true
Container vs Pod Security Context
  • Container Security Context (securityContext): Applied to individual containers within a pod. Controls settings like user ID, privilege escalation, and capabilities.
  • Pod Security Context (podSecurityContext): Applied at the pod level. Controls settings like filesystem group, supplemental groups, and sysctls that affect all containers in the pod.

Both Agent Pod and Agent Proxy Pod (deployed during upgrades) follow the same precedence order.

Platform-wide security context​

As mentioned here, the platform agents by default inherit values from the platform configuration but you can use agentValues section of values.yaml to override the configuration values.

Configure security contexts in your vcluster-platform chart values file values.yaml during platform installation:

Example of vcluster-platform values.yaml
# Platform-wide default security contexts
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1000
capabilities:
drop:
- ALL

podSecurityContext:
fsGroup: 2000
runAsGroup: 3000

# Default agent values that apply to all connected clusters
agentValues:
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1001
capabilities:
drop:
- ALL
podSecurityContext:
fsGroup: 2001
runAsGroup: 3001

Cluster-specific security context​

As mentioned here, you can customize the agent in each connected host cluster independently.

To achieve cluster-specific security context, you can override security contexts for specific clusters using the loft.sh/agent-values annotation:

Example of cluster-specific-agent-values.yaml
# Applied via loft.sh/agent-values annotation on the Cluster resource
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1002
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE

podSecurityContext:
fsGroup: 2002
runAsGroup: 3002
supplementalGroups:
- 4000
- 5000

Or you can apply cluster-specific security context through the UI by following the steps in Setting Agent Values via UI and add your security context configuration in the Extra Agent Values text area.