Kubernetes Security

Kubernetes security covers all layers of a cluster: images, pods, network policies, RBAC, and secrets. This article explains how the protective layers interlock, why default values rarely suffice, and where microsegmentation goes beyond what NetworkPolicies can do.

Kubernetes has established itself as the standard for running containers, in your own data center as well as a managed service in the public cloud. As it spreads, the attack surface grows: a cluster concentrates the applications and credentials of many teams in one place, and many default settings are geared toward smooth operation rather than isolation. Kubernetes security therefore looks at all layers of the cluster, from the container image to the network policy.

What is Kubernetes security?

The term brings together all measures that protect a Kubernetes cluster and the workloads running on it. The 4C model is often used as a framework, with the layers cloud, cluster, container, and code: each layer builds on the one beneath it, and a weakness further down undermines protective measures further up. Understanding the default values is important. Without your own configuration, every pod is allowed to communicate with every other one, service accounts receive generous permissions, and secrets are merely encoded rather than encrypted. In Kubernetes, security arises through deliberate decisions that are stored as configuration in the cluster and checked continuously. Responsibility is spread across several roles: platform teams harden the cluster and set guardrails, application teams deliver clean images and manifests.

How it works

Effective protection is spread across several layers that interlock:

Image layer: Only vetted and signed images from trusted registries reach the cluster. Vulnerability scans run in the build pipeline, and admission controllers enforce these rules at deployment.
Pod layer: Security contexts limit what a container may do: no root processes, read-only file systems, no extended kernel privileges, and no access to the host. Pod Security Standards define the minimum level per namespace.
Network layer: NetworkPolicies restrict traffic to defined relationships between pods and namespaces. Without such policies, the cluster is a flat network in which attackers move freely.
RBAC and access: Role-based permission assignment applies equally to people and service accounts. The principle of least privilege prevents a compromised account from immediately controlling the entire cluster.
Secrets management: Credentials are stored encrypted and ideally come from an external vault; regular rotation limits the damage of leaked keys. Cleartext secrets in manifests or repositories are the most common avoidable mistake.
Control plane and audit: The API server belongs behind strict authentication, and the etcd data store is encrypted. Audit logs make every change to the cluster traceable and provide the basis for detection.

Why it matters

Concentration risk: a cluster often runs dozens of applications. A single misconfiguration therefore affects many services at once.
Open default values: those who restrict nothing operate with far-reaching communication freedom and generous permissions in the cluster without noticing it.
High rate of change: deployments alter the state several times a day. Protection must be defined as code so that it automatically survives every change.
Open supply chain: base images and dependencies come from public sources and regularly bring vulnerabilities into the cluster.
Auditability: evidence of hardening and access control is increasingly demanded for container platforms as well in audits, for example under NIS2.

Typical scenarios

When building a container platform from scratch, the permission model, policies, and pipeline checks can be anchored from the start; this is considerably cheaper than any retrofit. In grown clusters, by contrast, the work starts with an inventory: which workloads run privileged, which communication actually takes place, where do secrets lie in cleartext? Multi-tenant clusters shared by several teams or tenants require clean separation via namespaces, quotas, and network policies. With managed services in the public cloud, the provider takes over the control plane, but the secure configuration of workloads and access remains the customer's task. And after a security incident, the analysis almost always points to the same issues: overly broad permissions and missing network segmentation. Regulated industries additionally bring evidence obligations; here it pays off when policies exist as code and audit reports are produced without manual collection work.

NetworkPolicies and microsegmentation: what does what?

NetworkPolicies are the built-in tool for segmentation within a cluster. They act at pod level, follow labels, and are quick to define. Their limits: they end at the cluster boundary, show no actual traffic flows, and behave differently depending on the network plugin in use. Zero Trust Microsegmentation takes a cross-cutting approach: it captures data flows across clusters, includes virtual machines and traditional servers, and enforces uniform policies across the entire environment. The two approaches complement each other well: NetworkPolicies for fine control within the cluster, microsegmentation for visibility and control across all platforms. The difference becomes visible at the latest in operation: a policy that works correctly within the cluster quickly comes to nothing at the transition to database servers outside the cluster.

KAEMI as your partner

KAEMI operates hardened container platforms as part of Compute & AI , including a permission model, policy enforcement, and ongoing monitoring. Through Application Security , KAEMI additionally secures the applications and pipelines that run on these platforms. If you would like to have the security posture of your cluster reviewed, reach us via contact .

Frequently asked questions about Kubernetes Security

Is a managed Kubernetes service automatically secure?

No. The provider hardens and operates the control plane, that is the API server and data store. Everything above that remains the customer's task: permission assignment, network policies, image scanning, secrets, and the configuration of the workloads. It is precisely in these areas that most incidents arise. A managed service significantly reduces operational effort, but does not replace your own security concept.

What are Pod Security Standards?

Kubernetes defines three graduated security profiles for pods: privileged without restrictions, baseline against known escalation paths, and restricted with strict requirements such as forgoing root privileges. The profiles are assigned per namespace and enforced at deployment. Restricted is recommended as the default; exceptions get their own namespace with a documented justification.

Are NetworkPolicies enough for segmentation?

Within a single cluster they are the right tool for fine control. As soon as multiple clusters, virtual machines, or traditional servers come into play, gaps arise: NetworkPolicies end at the cluster boundary and show no real traffic flows. For continuous visibility and uniform policies across the entire environment, microsegmentation is needed as a cross-cutting layer.

How do I handle secrets correctly in Kubernetes?

Basic rule: no credentials in cleartext in manifests or repositories. Enable encryption of secrets in the cluster data store and obtain sensitive values from an external vault with access control and logging. Short lifetimes and regular rotation limit the damage if a key does leak after all.

Where should I begin with hardening?

With the points that best combine effort and impact: review and reduce RBAC permissions, bring image scans into the pipeline, identify privileged pods, and restrict communication between namespaces. In parallel, it is worth looking at actual data flows, because this shows which connections a policy really needs. After that come audit logging and secrets hardening.