sample-app: harden pod/container securityContext#5
Conversation
- Pod: runAsNonRoot, runAsUser/Group 1000 (matches Dockerfile's USER 1000), seccompProfile RuntimeDefault - Container: allowPrivilegeEscalation false, readOnlyRootFilesystem true, drop all capabilities - Verified locally with 'docker run --read-only --user 1000:1000 --cap-drop ALL --security-opt no-new-privileges' — app has no disk writes, so no emptyDir volume needed for /tmp etc.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request enhances the security configuration of the sample-app deployment by adding pod-level and container-level securityContext settings, such as running as a non-root user, dropping all capabilities, and enforcing a read-only root filesystem. The feedback suggests explicitly setting privileged: false in the container's security context to ensure compliance with strict Pod Security Standards and security scanners.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
1 participant
Closes the pod hardening gap. Non-root (matches Dockerfile USER 1000), read-only rootfs, all caps dropped, no privilege escalation, RuntimeDefault seccomp.
Verified locally with docker run under the equivalent restrictions (--read-only --user 1000:1000 --cap-drop ALL --security-opt no-new-privileges) — app has no disk writes, so no emptyDir needed.
Independent of #4 (PDB/rollout strategy), touches a different part of the same file — no conflict expected, both can merge in either order.