Inventory identities and exposed interfaces
List the people, service accounts, workloads, and external endpoints that can reach the cluster. Review access against actual tasks. Separate application responsibilities from cluster administration and remove permissions that no longer serve a purpose.
Constrain containers and credentials
Assess whether containers need elevated privileges, host access, or writable filesystems. Use appropriate workload security settings and keep credentials out of images and repositories. Restrict access to secrets and plan how credentials will be rotated.
Example: a public API and a background worker
A worker that processes jobs may need access to a queue but no inbound public traffic. The API may require ingress without the worker’s data permissions. Give them separate identities and communication rules instead of using one broad account for both.
Verify that network controls are enforced
Writing a NetworkPolicy object is not enough: the cluster networking implementation must support enforcement. Test expected and prohibited traffic in a safe environment. Record required DNS and dependency access so a restrictive policy does not silently break application behavior.
Keep the operating process current
Review images, dependencies, admission controls, and configuration as the application changes. Define owners for alerts and remediation. This is a starting point for a workload-specific review, rather than a claim that one checklist makes every cluster secure.