Three profiles make three promises
Pod Security Standards define Privileged, Baseline, and Restricted profiles. Privileged is intentionally open, Baseline blocks known privilege-escalation paths, and Restricted follows a stronger hardening model.
Restricted is a sensible target for application namespaces. Baseline can be a migration step, but it should not quietly become the final state because older workloads are inconvenient to change.
Fail before deployment
If policy is enforced only by the production admission controller, developers discover incompatibility too late. Run equivalent checks in pull requests and test clusters so a violation becomes ordinary engineering feedback.
Pin the policy version deliberately. Otherwise a cluster upgrade can change the interpretation of Restricted and break a release even though the application manifest did not change.
- Disallow privileged containers and privilege escalation.
- Drop unnecessary Linux capabilities and apply an appropriate seccomp profile.
- Run as non-root and use a read-only root filesystem where practical.
- Separate system and application namespaces with different exception owners.
An exception is security debt
Some infrastructure agents need broader privileges. Give each exception an owner, a precise reason, the smallest possible scope, and a review date. A shared namespace with policy disabled becomes a permanent bypass for unrelated services.
The goal is not a green compliance badge. It is to reduce what an attacker can do after compromising a container, while making risky configuration visible before runtime.