Kubernetes Security Basics: A Practical Starting Checklist

Kubernetes is not secure or insecure out of the box. It is permissive by default, and most real incidents trace back to defaults nobody changed: pods that can talk to every other pod, Secrets stored without encryption, service accounts with far more access than they need, and containers running as root. The basics come down to six controls: lock down access with RBAC, restrict pod traffic with network policies, protect Secrets, enforce Pod Security standards, harden the nodes and control plane, and watch what happens at runtime.

This guide walks through each one in the order we would tackle them on a cluster that has never been reviewed, with the specific settings to look for and the mistakes that cause outages along the way.

TL;DR

• Kubernetes networking is open by default: until you apply NetworkPolicies with a CNI plugin that enforces them, every pod can reach every other pod.
• Secrets are not encrypted in etcd by default. Turn on encryption at rest and move long-lived credentials to an external secret store.
• Use RBAC with least privilege: namespace-scoped Roles, no wildcards, and no casual use of cluster-admin.
• Enforce Pod Security Admission, but start in audit and warn modes so you do not break production workloads.
• Harden the control plane and nodes against a published benchmark, then add runtime detection so you can see attacks that get past the preventive controls.

Table of Contents

• Why Kubernetes security is different from server security
• The main Kubernetes security risks in plain terms
• Start with access: RBAC best practices
• Kubernetes network policies: close the default-open network
• Kubernetes secrets management: encrypt, scope and rotate
• Pod Security Admission: stop risky pods at the door
• Harden the control plane and nodes
• Container runtime security and the build pipeline
• Patching and prioritizing what you find
• Our perspective: fragmentation is the real Kubernetes risk
• A first-week checklist
• When to bring in help
• FAQ
• Sources

Why Kubernetes security is different from server security

A traditional server has a clear edge: a firewall, a host, a handful of services. A Kubernetes cluster has layers, and each one can fail on its own. There is the control plane (API server, scheduler, controllers, etcd), the worker nodes, the container runtime, the network between pods, the workloads themselves, and the build pipeline that produces the images.

The Kubernetes STIG published through NIST's checklist repository reflects this layering. It treats hardening of the master components (API server, scheduler, controllers and etcd) and the worker nodes as the baseline, and expects the extra components you add, such as container runtimes and CNI plugins, to be secured according to their own vendors' guidance. In other words, "secure Kubernetes" is really a set of separate jobs, and a gap in any one of them is enough.

Containers also share the host's kernel. The CISA and NSA Kubernetes hardening guidance notes that a container escape from a privileged container can give an attacker access to Secrets and a path to move laterally through the cluster. That is why so much of the basic work is about limiting what a single compromised pod can reach.

The main Kubernetes security risks in plain terms

Before the fixes, here is what usually goes wrong on clusters we would review first:

The rest of this article takes these in order.

Start with access: RBAC best practices

Role-based access control decides who and what can do what against the Kubernetes API. Because every other control is configured through that API, over-broad permissions undermine everything else.

The Kubernetes project's own RBAC good practices page gives the core rules, and they are worth following literally:

1. Assign permissions at the namespace level where possible. Use RoleBindings rather than ClusterRoleBindings so a user or service account has rights only within one namespace.
2. Avoid wildcard permissions. A wildcard grants access not only to the object types that exist now but to any that are created later, including custom resources installed by future tools.
3. Limit cluster-admin. Treat it as a break-glass role, not a daily account. Audit who holds it every quarter.
4. Give each workload its own service account and grant it only what the application calls the API for. Most applications call the API for nothing, and can run with token auto-mounting disabled.
5. Review bindings regularly. Departed employees, retired CI pipelines and test accounts are where stale access hides.

If you run a managed service on a public cloud, remember that there are two permission systems: Kubernetes RBAC inside the cluster and the cloud provider's IAM outside it. Mapping cloud identities to cluster roles is a frequent source of accidental over-permissioning. Our AWS IAM checklist for DevOps and security teams covers the cloud side of that boundary.

Kubernetes network policies: close the default-open network

This is the control readers search for most, and it is the one teams most often postpone. Kubernetes networking is open by default. According to the Kubernetes documentation on network policies, NetworkPolicies let you set rules for traffic at the IP address or port level (OSI layers 3 and 4), both within the cluster and between pods and the outside world. Without them, a single compromised pod in a front-end namespace can reach your database pods directly.

Two details trip people up:

• A NetworkPolicy does nothing unless the CNI plugin enforces it. Creating the objects on a cluster whose network plugin does not support them gives a false sense of safety. Confirm enforcement in your plugin's documentation, and test it.
• Policies are additive and selective. A pod with no policy selecting it stays fully open. Once a policy selects a pod for ingress, only the traffic you allow gets through.

A sensible rollout pattern

1. Start with a default-deny policy in each namespace, for ingress first and then egress.
2. Add narrow allow rules: the front end may reach the API, the API may reach the database on its port, everything may reach DNS.
3. Restrict egress to the internet. Many attacks depend on a compromised pod calling out to download tools or send data away.
4. Test with a throwaway pod before and after each change, and keep the policies in version control next to the application manifests.

On Google Kubernetes Engine, the provider documents how to enable and use network policy enforcement, including egress controls to external endpoints. Other managed services have their own equivalents, so check the one you use.

Network policies are the practical expression of zero trust inside a cluster. CISA's guidance calls out pod-to-pod traffic as a frequently overlooked vector, and the same principle appears in broader cloud guidance on preventing lateral movement in cloud infrastructure.

Kubernetes secrets management: encrypt, scope and rotate

A Kubernetes Secret holds a small amount of sensitive data, such as a password, token or key. The Secrets documentation explains that using a Secret keeps that data out of your pod specification and container images. That is an improvement, but it is not the same as being encrypted. Values are only base64-encoded, and by default they are stored unencrypted in etcd.

The OWASP Kubernetes Top 10 entry on secrets management failures identifies relying on native Secret objects without encryption at rest, and using them for long-lived credentials, among the most common and damaging failures. Here is how to deal with it:

1. Enable encryption at rest for Secrets. The Kubernetes documentation on encrypting confidential data at rest shows how to write an encryption configuration for the API server. It also warns that storing the raw key in the configuration file offers only moderate protection, so prefer a KMS provider where you can.
2. Move the real secrets outside the cluster. An external secret store, or your cloud provider's key management service, automates rotation and avoids static credentials spread across namespaces.
3. Prefer short-lived credentials. Workload identity and tokens that expire beat a database password that has not changed in three years.
4. Restrict who can read Secrets. In RBAC, get, list and watch on Secrets are all sensitive. Listing Secrets in a namespace exposes every value in it.
5. Keep Secrets out of Git and images. Scan repositories and image layers for credentials as a routine pipeline step.

Two of our own guides go deeper on the surrounding pieces: cloud secrets management for IT teams and choosing the encryption layer, then securing the keys. If you have to show an auditor how keys are handled, see audit-ready encryption key management.

Pod Security Admission: stop risky pods at the door

Network policies limit what a pod can talk to. Pod Security limits what a pod is allowed to be. The built-in Pod Security Admission controller, stable since Kubernetes v1.25, enforces three standard levels at the namespace level:

• Privileged: unrestricted.
• Baseline: minimally restricted, blocking the known worst escalations.
• Restricted: heavily restricted, following current hardening practice.

Each level can be applied through namespace labels in one of three modes: enforce rejects violating pods, audit records violations, and warn shows a warning to the user.

The settings these levels push you toward match CISA and NSA's advice: do not run containers in privileged mode, do not run processes as root, and do not allow privilege escalation. Those three changes remove a large share of container escape paths.

Do not flip straight to enforce

A common assumption is that Pod Security Admission is set and forget. It is not. Applying a restricted standard to existing production workloads can cause immediate outages, because pods that run as root or request extra capabilities will be rejected the next time they are rescheduled. The Kubernetes documentation's approach is the safe one:

1. Label the namespace with audit and warn at the level you want.
2. Collect the violations for a couple of weeks and fix the workloads, or document the justified exceptions.
3. Move to enforce namespace by namespace, starting with the least critical.

Treat the security context of each pod as part of the application's definition: run as a non-root user, drop all Linux capabilities and add back only those required, use a read-only root filesystem where the app allows it, and set a seccomp profile.

Harden the control plane and nodes

The control plane is the most valuable target in the cluster. Basics to verify:

• Keep the API server off the public internet or restrict it to known address ranges. On managed services, this is usually a setting for private endpoints or authorized networks.
• Use TLS everywhere between control plane components, and protect etcd with client certificate authentication, since it holds the whole cluster state.
• Turn on audit logging and ship the logs somewhere an attacker with cluster access cannot delete them.
• Disable anonymous access and unused authentication methods on the API server and kubelets.
• Keep versions current. Kubernetes supports only recent minor releases with security patches, so a cluster left alone for a year or two becomes an unpatched cluster.

For a defined checklist rather than ad hoc judgment, use a recognized benchmark. The Kubernetes STIG is one, and the CISA and NSA hardening guidance is another. Both are free, and both give you concrete pass or fail items, which matters if your organization answers to HIPAA, PCI-DSS or SOC 2 auditors.

On the worker nodes, use a minimal, hardened node operating system, patch it on a schedule, and avoid giving nodes broad cloud permissions. A pod that can reach the node's metadata endpoint can often obtain the node's cloud credentials, so block that path with network policy or provider settings.

Container runtime security and the build pipeline

Prevention controls will not catch everything. Runtime security is about seeing what containers actually do once they are running: unexpected shell sessions, a web server process spawning a network scanner, writes to sensitive paths, outbound connections to unusual destinations.

The basics here:

1. Scan images before they deploy and keep them small. Fewer packages means fewer vulnerabilities to chase.
2. Pin and sign images from trusted registries, and block unsigned or latest-tag images with admission policy.
3. Collect runtime events from nodes and pods, and alert on behaviour that does not fit the workload's normal profile.
4. Isolate sensitive workloads on dedicated nodes, or use stronger sandboxing for untrusted code.

The DoD's published description of its enterprise DevSecOps approach is a useful model: security baked into the platform through automatically injected sidecar security stacks, rather than left to each team's manual configuration. You do not need a defence-sized budget to copy the idea. Put your controls in infrastructure-as-code, apply them through the pipeline, and scan continuously, so a rebuilt cluster comes up secure rather than needing someone to remember the steps.

For how this fits in the wider picture, see our overview of runtime application security for IT teams and examples of cloud-native security tools. If your clusters sit in Google Cloud, turning Security Command Center findings into SIEM playbooks is a practical next step. Teams that want a broader grounding in security protocols for applications can use that to see how transport and authentication standards connect to the cluster controls above.

Patching and prioritizing what you find

Scanning a typical cluster produces hundreds of findings. You cannot fix them all at once, and you should not try. Rank by what is actually being exploited and what is reachable, not only by severity score. Our write-ups on prioritizing vulnerabilities with KEV rather than CVSS alone and on a CISA-aligned remediation process explain how to do that with a small team. If you plan to test your clusters offensively, read how to run cloud penetration tests without provider suspension first.

Our perspective: fragmentation is the real Kubernetes risk

When we look at a cluster that has had an incident, the missing control is rarely exotic. It is usually a basic from this article that fell between teams. The platform group owned RBAC, the application group owned the manifests, someone else owned the cloud account, and nobody owned the question "what happens if this pod is compromised?"

That is why we push clients toward one accountable provider for IT, cloud and security rather than a patchwork of vendors. When detection, cloud management and compliance sit under one roof, a runtime alert can be matched to the network policy that should have stopped it and the RBAC change that made it possible, without three tickets and three finger-pointing calls. It is also how we keep costs predictable: flat monthly pricing for the ongoing work, so a team without a dedicated Kubernetes specialist is not surprised by an invoice.

Our advice for a small team: do not try to adopt every tool. Get the six basics in this guide in place, put them into code, and review them on a schedule. Mature tooling helps once the foundations hold. It rarely rescues a cluster that is open by default.

— Nick - Sr. Executive

A first-week checklist

Then repeat for production, one namespace at a time, and schedule a review of RBAC bindings and policy exceptions every quarter.

When to bring in help

If you run Kubernetes in a regulated setting, such as patient data under HIPAA, card data under PCI-DSS, or a SOC 2 or ISO 27001 audit, the checklist above is a starting point, not evidence. Auditors want documented, repeatable controls and proof they are working. We provide 24/7 threat detection and monitoring, cloud management across AWS, Azure and Google Cloud, and compliance assessments, all under one contract and one SLA. You can see the full list on our services page, or start from the Nexus home page to talk to our team about a cluster review.

FAQ

Is Kubernetes secure by default?

No. Out of the box, pods can communicate freely, Secrets are stored unencrypted in etcd, and nothing stops a pod from running as root unless you configure Pod Security. Managed services harden some of the control plane for you, but workload, network and access settings remain your responsibility.

Do I need a special plugin for network policies?

Yes, in the sense that your CNI plugin must enforce them. The NetworkPolicy objects are part of Kubernetes, but if the network plugin ignores them they have no effect. Check your plugin's documentation, then test with a pod that should be blocked.

Are Kubernetes Secrets safe to use?

They are safer than putting values in manifests or images, but only when you also enable encryption at rest and restrict who can read them. For long-lived credentials, an external secret store with automated rotation is the better choice, as OWASP's Kubernetes Top 10 advises.

What should a small team do first?

Start with RBAC cleanup and Secrets encryption, because they close the most direct paths to your data. Then add default-deny network policies and Pod Security in audit mode. Use a published benchmark such as the CISA and NSA guidance to keep the work measurable.

Sources

• Kubernetes STIG checklist, NIST National Checklist Program
• CISA and NSA Release Kubernetes Hardening Guidance
• Network Policies, Kubernetes documentation
• Control communication between Pods and Services using network policies, GKE documentation
• Security Guidance for 5G Cloud Infrastructure Part II, CISA
• Role Based Access Control Good Practices, Kubernetes documentation
• Secrets, Kubernetes documentation
• K03: Secrets Management Failures, OWASP Kubernetes Top 10
• Encrypting Confidential Data at Rest, Kubernetes documentation
• Pod Security Admission, Kubernetes documentation
• DoD Enterprise DevSecOps Initiative, NIST CSRC

Recommended

• GCP security monitoring: Turn SCC findings into SIEM playbooks
• Security Teams: 7 Domains to Harden Your Azure Security Baseline
• 8 Step AWS IAM Checklist for DevOps and Security Teams
• Vulnerability Prioritization: Why KEV Beats CVSS Alone