An administrator has created a custom SCC named restricted-custom. During testing, pods using this SCC still fail because they are assigned the non-root UID range automatically, but the application container requires writing to a specific directory owned by UID 1000. How should the administrator configure the SCC to ensure the container runs consistently as UID 1000?
Trap 1: Set runAsUser.type to RunAsAny and add securityContext.runAsUser:…
RunAsAny allows pods to define their own UID, but if the container image enforces a different default user, it may fail unless overridden in the pod spec.
Trap 2: Configure fsGroup.type to MustRunAs with uid: 1000
fsGroup controls volume ownership and permissions, not the process execution user ID of the container.
Trap 3: Set privileged: true and map the container user via…
Privileged mode disables namespace isolation and is a severe security risk; it does not explicitly enforce a container user ID.
- A
Set runAsUser.type to RunAsAny and add securityContext.runAsUser: 1000 in the pod spec
Why it fails: RunAsAny allows pods to define their own UID, but if the container image enforces a different default user, it may fail unless overridden in the pod spec.
- B
Configure fsGroup.type to MustRunAs with uid: 1000
Why it fails: fsGroup controls volume ownership and permissions, not the process execution user ID of the container.
- C
Set privileged: true and map the container user via supplementalGroups
Why it fails: Privileged mode disables namespace isolation and is a severe security risk; it does not explicitly enforce a container user ID.
- D
Set runAsUser.type to MustRunAs and specify uid: 1000 in the uidRange
Setting runAsUser.type to MustRunAs with the appropriate UID ensures the container always runs as the specified user ID.