Kubernetes Security Checklist 2026 | Corgea

A Kubernetes security checklist should cover cluster configuration, workload hardening, identity, network controls, secrets, image provenance, admission policy, observability, and CI/CD guardrails. In 2026, Kubernetes security is also software supply chain security: every container image, Helm chart, manifest, and pipeline can become a path to production risk.

Use this Kubernetes security checklist during platform reviews, new cluster launches, application onboarding, and quarterly audits.

Kubernetes security checklist for 2026

Cluster and control plane

• Use a supported Kubernetes version and patch clusters promptly.
• Restrict API server access to trusted networks and identities.
• Enable audit logging and retain logs centrally.
• Encrypt Kubernetes Secrets at rest.
• Disable anonymous access and unused legacy authentication paths.
• Separate production, staging, and development clusters or namespaces by risk.

Identity and RBAC

• Use least-privilege RBAC for users, groups, and service accounts.
• Avoid broad cluster-admin grants.
• Disable default service account token automounting where possible.
• Use short-lived workload identities or cloud-native identity federation.
• Review RoleBindings and ClusterRoleBindings regularly.

Workloads

• Enforce restricted Pod Security Standards.
• Run containers as non-root.
• Drop Linux capabilities and block privileged containers.
• Use read-only root filesystems where possible.
• Set CPU and memory requests and limits.
• Avoid host networking, host PID, host IPC, and hostPath mounts unless explicitly justified.

Network and ingress

• Start sensitive namespaces with default-deny network policies.
• Allow only required pod-to-pod traffic.
• Require TLS at ingress and service boundaries where appropriate.
• Restrict administrative endpoints and metrics.
• Review ingress annotations for risky controller behavior.

Images, secrets, and supply chain

• Scan container images before deployment.
• Use minimal base images and rebuild frequently.
• Pin image tags or digests for production.
• Generate SBOMs and track provenance.
• Keep secrets out of environment variables when stronger options exist.
• Prevent plaintext secrets from landing in Git, charts, or CI logs.

CI/CD and policy

• Scan manifests, Helm charts, and Kustomize overlays in pull requests.
• Enforce admission controls for privileged workloads, unsafe capabilities, and untrusted registries.
• Require review for namespace, RBAC, ingress, and workload identity changes.
• Treat cluster deployment pipelines as privileged infrastructure.

Corgea IaC scanning helps catch risky Kubernetes manifests before merge, while Corgea container scanning helps teams prioritize image risk before workloads run.

1. Keep the cluster patched and observable

Kubernetes moves quickly. Unsupported cluster versions accumulate control plane, kubelet, runtime, and dependency risk. Use managed upgrade channels where possible, but still test upgrades against your workloads.

At minimum:

• track cluster version support windows;
• patch node images and container runtimes;
• enable audit logs;
• centralize control plane, admission, and node logs;
• alert on unexpected RBAC changes, new privileged pods, and new public ingresses.

Audit logging is not a replacement for prevention, but it is essential for incident response.

2. Enforce least-privilege RBAC

RBAC drift is one of the most common Kubernetes security failures. Teams grant broad permissions during a deployment emergency and never remove them.

Avoid broad roles like this for application workloads:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: app-admin
subjects:
  - kind: ServiceAccount
    name: app
    namespace: payments
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Prefer narrow namespace-scoped roles:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: read-configmaps
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]

Review RBAC in pull requests and scan changes with Corgea IaC scanning before they reach a cluster.

3. Harden service accounts

Many pods do not need Kubernetes API access. Disable automatic token mounting by default and opt in only where needed.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web
  namespace: payments
automountServiceAccountToken: false

For cloud access, prefer workload identity federation over static cloud keys stored as Kubernetes Secrets. Short-lived identity reduces the value of a stolen token.

4. Apply restricted Pod Security Standards

Pod Security Standards help prevent risky workload settings. Label namespaces so the Kubernetes admission controller enforces the restricted profile.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Then harden pod specs:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: api
    image: registry.example.com/payments-api@sha256:...
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

This reduces container escape and post-compromise impact.

5. Use network policies to limit lateral movement

Kubernetes networking is often open by default. A default-deny policy changes the baseline.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Then allow required traffic explicitly:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

Network policies are especially valuable for multi-tenant clusters and namespaces that process sensitive data.

6. Protect Kubernetes Secrets

Kubernetes Secrets are base64-encoded by default, not encrypted by default in every environment. Use encryption at rest and restrict who can read secrets.

Better patterns:

• use cloud secret managers with CSI drivers or external secret operators;
• avoid exposing secrets as environment variables when file mounts are safer;
• rotate secrets regularly;
• restrict get, list, and watch permissions on secrets;
• scan manifests and Helm values for accidental plaintext secrets with Corgea secrets scanning.

7. Scan images and track provenance

Kubernetes security depends on the images you run. Image controls should include:

• trusted registries;
• vulnerability scanning;
• minimal base images;
• rebuilds for patched OS packages;
• SBOM generation;
• image signing or provenance where supported;
• admission policy that blocks untrusted images.

Corgea container scanning helps teams move beyond raw image alert volume and focus on high-impact container risk. Corgea SBOM and license enforcement supports software inventory and supply chain governance.

8. Secure ingress and external exposure

Ingress resources can expose internal services to the internet with a few lines of YAML. Review:

• hostnames and wildcard domains;
• TLS configuration;
• authentication at the edge;
• dangerous ingress controller annotations;
• administrative endpoints accidentally exposed;
• public load balancers in sensitive namespaces.

Use Corgea attack surface mapping to connect reachable endpoints back to the code and packages that create exploitable application risk.

9. Add admission controls and pre-merge checks

Admission controls catch policy violations at deploy time. Pre-merge scanning catches them earlier, when developers have context.

Look for controls that block:

• privileged containers;
• host namespace usage;
• writable root filesystems;
• images from untrusted registries;
• missing resource limits;
• broad RBAC grants;
• plaintext secrets;
• unsafe ingress exposure.

CI/CD should scan Kubernetes manifests, Helm charts, Kustomize overlays, Terraform, and container images before deployment. For broader pipeline controls, read the GitHub Actions security checklist and the guide to integrating static analysis into CI/CD.

Try Corgea scanning for Kubernetes manifests and containers

Want this Kubernetes security checklist enforced before workloads reach production?

• Corgea IaC scanning identifies risky Kubernetes manifests, Helm charts, and infrastructure changes in review.
• Corgea container scanning prioritizes image risk before release.
• Corgea secrets scanning catches leaked credentials in manifests and config.
• Corgea developer experience delivers actionable findings inside pull requests.
• Corgea SBOM and license enforcement strengthens supply chain governance.

Try Corgea today or book a custom demo for your Kubernetes platform.

If you are comparing Kubernetes and cloud-native security coverage across AppSec platforms, review Corgea vs Snyk, Corgea vs Checkmarx, Corgea vs Semgrep, and Corgea vs GitHub Advanced Security.

FAQ

What should a Kubernetes security checklist include?

A Kubernetes security checklist should include API server hardening, RBAC, service account controls, Pod Security Standards, network policies, secret management, image scanning, admission controls, audit logging, and CI/CD scanning for manifests and Helm charts.

What Kubernetes security controls should teams implement first?

Start with least-privilege RBAC, default-deny network policies for sensitive namespaces, restricted Pod Security Standards, image scanning, secret encryption, and review controls for manifests before they reach the cluster.

How do network policies improve Kubernetes security?

Network policies reduce lateral movement by limiting which pods can communicate. They are most effective when teams start with default-deny rules and then explicitly allow required service-to-service traffic.

Can Corgea scan Kubernetes manifests?

Yes. Corgea IaC scanning helps identify risky Kubernetes manifest and Helm chart patterns, while Corgea container scanning helps prioritize image risk before workloads are deployed.