What does securing a Kubernetes cluster involve beyond firewalls and scans?

Think about what happens after a workload is running. A firewall mostly controls traffic at the edge, and image scanning can find known issues, but neither automatically limits what a compromised pod can access inside the cluster.

Start with workload defaults: run as a non-root user, drop unnecessary Linux capabilities, use a read-only root filesystem where practical, and avoid mounting a service account token when the workload does not need Kubernetes API access. Apply resource requests, limits, and quotas too, since resource exhaustion can become an availability problem.

I’d make the build and deployment path part of the security plan. Use maintained, minimal base images, keep dependencies controlled, and scan images before deployment and over time. Tags can move, so pinning deployments to immutable image digests gives you a clearer record of what actually ran.

Scanning is useful, but it does not guarantee an image is safe. Admission policies can require approved registries, signed images, or other checks before workloads are allowed to start. Roll those rules out in a warning or audit mode first, then enforce them once you know what existing workloads depend on.

RBAC and network policy are the parts people tend to underestimate. Give human users and service accounts only the permissions they need, and review permissions periodically. In particular, check whether workloads actually need their default service account token mounted.

Network policies can restrict which workloads talk to each other, rather than assuming everything inside the cluster is trusted. Their behavior depends on the network plugin, so confirm that the policies are enforced in your environment and test the rules you write.

Don’t treat the control plane and cloud identity as someone else’s problem just because the service is managed. Review cluster access, node and workload IAM permissions, admission controllers, and webhook configurations. Overly broad permissions or a poorly configured webhook can undermine other safeguards.

Also check how secrets are stored and delivered. An external secret manager can keep secret values outside Kubernetes storage if configured for that purpose, but some integrations copy them into Kubernetes Secrets. Verify the behavior rather than relying on the product label. For managed clusters, ask what encryption and control-plane settings the provider handles and what remains your responsibility.

Security needs an operational side too. Keep cluster components and node images patched, collect audit logs, and have a process for responding when a workload or credential is exposed. Test backups and recovery instead of assuming they will work when needed.

You do not have to turn on every control at once. Pick a small baseline, such as least-privilege access, non-root workloads, restricted network paths, and tested recovery, then measure gaps and expand it.