securityContext in kubernetes
Security contexts in kubernetes is confusing, partly because it uses the same name and appears both in deployment.spec.template.securitycontext and also deployment.spec.template.containers.securitycontext.
But you will see below in yaml below. So the securitycontext defined in the container level OVERRIDES the security context in the template level.
Have a look at the yaml below: you'll noticed that we have 2 securitycontext.
I have provided the link to the docs so you can have some fun there.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
securityContext:
# https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#podsecuritycontext-v1-core
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
# https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#securitycontext-v1-core
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Notice how the first securitycontext comes about and you'll notice we have sysctls configurations.
template:
metadata:
labels:
app: nginx
spec:
securityContext:
# https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#podsecuritycontext-v1-core
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
Then we have another sections. Hopefully you will be able to see clearly.
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Comments