Configure security context
Security context is one of the common agent configurations. Agent pods support multiple levels of security context configuration.
When multiple security contexts are configured, the agent uses this precedence order (highest to lowest):
- Cluster-specific
agentValues(vialoft.sh/agent-valuesannotation) - Platform-wide
agentValues(in platform values.yaml) - Platform default
securityContextandpodSecurityContext
See Platform configuration for platform-wide settings.
Inspect the security context applied to agent pods:
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 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:
# 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:
# 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.