The Kubernetes security checklist in 2026 is a list of the things that the security team has agreed the engineering team has to do, and the list is a starting point for the conversation rather than the end of the conversation. The checklist is useful. The checklist is necessary. The checklist becomes the artefact the security team can show the auditor. The checklist is also not the work, the checklist is not the protection, and the checklist is not the thing that is going to keep the cluster secure. The checklist serves as the input to the work, and the work is what the cluster security actually requires.
The first five: day one items
The first five items on the checklist are the items that have to be right from day one of the cluster. The items are the foundation for the rest of the checklist. The items are the most expensive to fix if the items are not right from day one.
1. Role based access control. RBAC is what controls who can do what in the cluster. RBAC should follow the principle of least privilege, RBAC should use the Kubernetes built in roles rather than the custom roles where possible, and RBAC should be audited regularly. The cluster without the least privilege RBAC runs as the cluster that the compromised developer account can use to take down the production, and the cluster that the compromised developer account can use to take down the production becomes the cluster the security team is going to be on the news for.
2. Network policy. The network policy is what controls the traffic between the pods. The network policy should be default deny. The network policy should explicitly allow the traffic that is needed. The network policy should be tested regularly. The cluster without the default deny network policy amounts to the cluster where every pod can talk to every other pod, and the cluster where every pod can talk to every other pod amounts to the cluster where the lateral movement is trivial.
3. Pod security standards. The pod security standards are the Kubernetes successor to the pod security policies, and the pod security standards should be set to the restricted level. The restricted level prevents the privileged containers, the host network, the host PID, the host IPC, and the other capabilities the pods do not need. The cluster without the restricted pod security standards sits as the cluster where the pods run as root, and the cluster where the pods run as root counts as the cluster where the container escape is one kernel exploit away.
4. Image provenance. The image provenance sits as the verifiable chain from the source code to the running container. The image should be built from a reproducible build, signed with a verifiable key, and deployed through a provenance aware admission controller (Kyverno, OPA, Connaisseur). The cluster without the image provenance serves as the cluster where the attacker can push the malicious image, and the cluster where the attacker can push the malicious image becomes the cluster the supply chain attack is going to be successful against.
5. Secret management. The secret management is what stores the database credentials, the API keys, the TLS certificates. The secret should be stored in a secret manager (HashiCorp Vault, AWS Secrets Manager, the cloud provider native secret managers), the secret should be rotated regularly, and the secret should never be committed to the repository. The cluster without the secret management runs as the cluster where the credentials are in the environment variables, and the cluster where the credentials are in the environment variables runs as the cluster where the secret gets exfiltrated with the next build log.
The next five: the things that take longer to get right
6. Runtime threat detection. Falco, Tetragon, Tracee. The runtime threat detection is what catches the suspicious behaviour in the running pod. The cluster without the runtime threat detection runs as the cluster where the attacker runs for months without anyone noticing, and the cluster where the attacker runs for months without anyone noticing stands as the cluster where the breach stands as the kind that takes a year to discover.
7. Admission control. The admission controller is what enforces the policies on every Kubernetes resource. The admission controller should be set up to enforce the image provenance, the pod security standards, the resource limits, the label requirements. The cluster without the admission controller becomes the cluster where the policy is documentation, and the policy that is documentation runs as the policy that is not going to be followed.
8. Resource limits and quotas. The resource limits are what prevent the noisy neighbour, the runaway container, the denial of service. The resource quotas are what prevent the namespace from consuming the entire cluster. The cluster without the resource limits becomes the cluster where one misbehaving pod can take down the production.
9. Audit logging. The audit logging is what records who did what in the cluster, and the audit logging is what the security team uses to investigate the incident. The cluster without the audit logging becomes the cluster where the post incident analysis is guesswork.
10. Backup and disaster recovery. The backup and disaster recovery is what restores the cluster when the cluster gets accidentally deleted, when the cluster gets maliciously encrypted, when the cluster gets corrupted by the failed upgrade. The backup and disaster recovery should be tested regularly. The backup and disaster recovery that is not tested stands as the backup and disaster recovery that is going to fail when the backup and disaster recovery is needed.
What to do this quarter
Pick the five day one items. Get them right on the next new cluster, or migrate the existing cluster to be compliant with the five. The five day one items are the items that have the largest impact on the cluster security, and the cluster security serves as the thing the security team is going to be judged on.
Add one item from the next five per month. The next five items take longer to implement. The next five items are the items that the engineering team has to budget time for. The next five items are the items that the cluster security is going to be the next layer of.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
