Is Your Kubernetes Cluster Really Safe?

Five simple habits that keep a small problem from becoming a big one.

Your Kubernetes cluster is probably running fine today. The real question is what happens if someone gets a foothold inside it. This guide walks through the habits that answer that question, in plain language, whether you are new to Kubernetes or have run it for years.

Think of your cluster as an apartment building

Deploying an app on Kubernetes feels great. A few minutes later, everything is green and running. But a running cluster is not the same as a safe one. Out of the box, Kubernetes is built to be flexible, not locked down.

Picture an apartment building where every door is unlocked, every tenant holds a master key, and nobody has changed the locks in years. Nothing bad has happened yet, but you would not sleep well.

The five habits below fix exactly that: keys (RBAC), walls (Network Policies), house rules (Pod Security), safes (Secrets), and maintenance (upgrades).

1. RBAC: decide who gets which key

RBAC (Role-Based Access Control) decides who can do what in your cluster. That “who” includes people, groups, and applications.

Why you will be glad you did it:

• A stolen key opens fewer doors. If an account or token leaks, the attacker only gets what that account was allowed to do. A narrow account means a small incident. A cluster-admin account means the whole building.
• It saves you from honest mistakes. Many outages come from a well-meaning person running the right command in the wrong namespace. Least privilege makes that mistake impossible.
• You can answer the audit question. When permissions are written down and reviewed, “who can delete things in production?” has a real answer.
• Apps are users too. Pods talk to the Kubernetes API through service accounts. If every app shares one powerful account, one weak app exposes everything.

Take a look at what you have today:

kubectl get roles,rolebindings -A
kubectl get clusterroles,clusterrolebindings
kubectl auth can-i get pods --all-namespaces

Quick rules to live by:

• Give the least access that still gets the job done.
• Avoid cluster-admin unless you truly need it.
• Give each application its own service account.
• Review permissions regularly. Access piles up over time and rarely gets removed.

2. Network Policies: put walls between the rooms

By default, every Pod can talk to every other Pod. That is convenient, and it is also the apartment with no interior walls. Network Policies let you say exactly which Pods, namespaces, and outside endpoints may talk to each other.

One catch worth knowing first: they only work if your cluster’s networking plugin (CNI) supports them. Check this before you assume you are protected.

Why it matters:

• Attackers rarely stop at one room. They get a foothold, then move sideways. Network isolation keeps one compromised frontend Pod from reaching your database.
• Your design becomes a rule. The frontend talks to the backend, and only the backend talks to the database. A policy makes the cluster enforce that.
• Outbound traffic matters too. Limiting egress makes it harder for a compromised workload to reach the internet, download tools, or send data out.

See what is in place:

kubectl get networkpolicies -A
kubectl get pods -n kube-system

The second command helps you spot which networking components are running.

Quick rules to live by:

• Restrict ingress and egress traffic you do not need.
• Allow only the application-to-database connections that are required.
• Keep frontend, backend, and database workloads separate.
• Test policies before enforcing them in production. A policy that is too strict can quietly break good traffic.

3. Pod Security: no need for a master toolbox

Containers share the node’s kernel. A container running as root with extra powers has a much easier path to escape onto the host. Pod security settings take those extra powers away.

What each setting buys you:

• Run as non-root. Escaping to the host becomes far harder.
• Drop all capabilities. Attackers love powers that most apps never use.
• Block privilege escalation. A process cannot gain more rights than its parent.
• Use the RuntimeDefault seccomp profile. It filters dangerous system calls with very little effort.

Here is a solid starting point:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

A warning: check that your container image and app actually work with this user and these filesystem permissions. An app that expects to write to a root-owned folder will crash when it runs as user 10001. Try it in staging, fix the file ownership in your image, then roll it out.

4. Secrets: do not leave the spare key under the doormat

Passwords, API keys, and database credentials deserve special care. Here is why:

• Code and images get copied everywhere. A secret baked into a repository or image lives in every clone, registry, and build cache, often forever.
• Leaked credentials are the easiest way in. Attackers do not need an exploit if they can simply log in.
• Kubernetes Secrets are not automatically safe. By default they are only base64-encoded, which is not encryption. Without access controls and encryption at rest, anyone who can read the API data can read them.
• Rotation shortens the damage. A credential that changes regularly has a short useful life once stolen.

What to do about it:

• Restrict who can read Kubernetes Secrets.
• Turn on encryption at rest for Kubernetes API data.
• Consider an external secrets manager, such as OpenBao, where it fits.
• Rotate credentials and audit who accessed them.

5. Upgrades: even great locks need maintenance

Security policies protect you from what you configured. Upgrades protect you from what you did not know about.

• Security fixes. New vulnerabilities are found all the time, and the fixes only reach supported versions.
• Bug fixes. Many mysterious cluster problems are already solved in newer releases.
• Supported features. Old versions eventually stop getting patches, and then you are exposed with no fix available.
• Small steps beat giant leaps. Teams that upgrade regularly face small, manageable changes. Teams that wait years face a risky, painful jump.

Upgrades can also bring compatibility surprises, which is why they deserve a plan instead of a gamble.

Before you start

Take a snapshot of how things look right now. If something is already broken, you want to know before the upgrade, not blame it afterwards

kubectl version
kubectl get nodes -o wide
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp

Then go through this checklist:

• Back up cluster state and persistent application data.
• Read the release notes and look for deprecated APIs.
• Check compatibility of your CNI, CSI, Helm charts, and workloads.
• Make sure you have enough CPU, memory, and disk space.
• Have a rollback or recovery plan ready.

The upgrade, step by step

1. Pick your target version and confirm the supported upgrade path. Skipping versions is often not allowed.
2. Back up the cluster and its configuration. This is your safety net.
3. Upgrade the control plane following your distribution’s documentation.
4. Upgrade worker nodes one by one, so capacity stays available and workloads can move around.
5. Validate system components and your applications.
6. Review logs, resource usage, and network connectivity.

Running K3s? Follow the official K3s upgrade documentation and check the supported version-skew rules. Do not assume standard kubeadm upgrade commands apply to K3s. Using the wrong procedure is a classic way to break a healthy cluster.

Did it actually work? Check after every upgrade

An upgrade is not done when the command finishes. It is done when you have proved the cluster works.

kubectl get nodes
kubectl get pods -A
kubectl get networkpolicies -A
kubectl get events -A --sort-by=.lastTimestamp

Then confirm that:

• All nodes are Ready.
• Critical Pods are Running or Completed, as expected.
• Network policies still allow the traffic you need. Upgrades can change networking behavior.
• RBAC permissions are still correct.
• Applications can reach their databases and other services.
• Monitoring and logging are working, so you can see the next problem coming.

Here the cheat sheet

Habit	In the building	Protects you from
RBAC	Who holds which key	Stolen or misused accounts doing too much
Network Policies	Walls between rooms	Attackers moving sideways
Pod Security	Then confirm that:All nodes are Ready.Critical Pods are Running or Completed, as expected.Network policies still allow the traffic you need. Upgrades can change networking behavior.RBAC permissions are still correct.Applications can reach their databases and other services.Monitoring and logging are working, so you can see the next problem coming.House rules for guests	Container escapes and privilege escalation
Regular Upgrades	Ongoing maintenance	Known vulnerabilities and unsupported software
Secrets Management	A real safe	Credential leaks

No single layer is perfect. Together, an attacker has to beat several independent defenses instead of just one.

One last thing

Security and upgrades are not a one-time project. They are a habit, like locking the door when you leave. Least-privilege access, network isolation, secure Pod settings, good secrets handling, and a tested upgrade process all add up to a calmer, more reliable cluster.

And the golden rule: always test security changes and version upgrades in staging before touching production. Staging is where mistakes are cheap. Production is where they are expensive.