A securityContext That Passes the Restricted Standard
The previous guide ended with a refusal listing four fields. This one turns that list into a Pod that is admitted, then checks each control from inside the running container - and finishes with the field restricted never asks for and you should set anyway.
Microservice Vulnerabilities Guide 19 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 18 min
The four fields are runAsNonRoot, seccompProfile, allowPrivilegeEscalation and capabilities.drop - two at Pod level and two at container level.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a restricted namespace has refused your Pod and listed the fields it wanted. This matters because adding those four fields is only half the job - each control has a measurable effect you can confirm from inside the running container.
- starting from the plainest possible spec, refused in a restricted namespace
- adding the four fields, and being admitted
- proving each control from inside - four fields, four measurements
- finding the field restricted does not require, and the two different errors it produces
Before you start
-
The Pod that will not be admitted
-
Add them, and be admitted
-
Prove each control from inside
-
The field restricted does not require