Why Kubernetes Has Won — and Why Running It Is Still Brutal

Kubernetes has become the de facto standard for container orchestration across the industry. The reasons are well-established: declarative configuration, self-healing workloads, horizontal scaling, service discovery, rolling deployments, and a rich ecosystem of tooling built on the Kubernetes API. Organizations that have invested in Kubernetes expertise and tooling have a platform that can run virtually any workload with consistent operational patterns.

And yet, running Kubernetes in production remains one of the most operationally demanding things an engineering team can take on. A 2024 CNCF survey found that while Kubernetes adoption continues to climb, operational complexity is still the top reported challenge — ahead of cost, security, and skills gaps. This is not a technology problem. Kubernetes itself is mature, well-documented, and battle-tested at extraordinary scale. The problem is that running it well requires sustained, expert attention across a sprawling set of concerns: control plane availability, etcd health, node provisioning, certificate rotation, network policy, admission controllers, RBAC, audit logging, image scanning, secrets management, and more.

For organizations that do not have a dedicated platform engineering team — or those that have one but want it focused on product work rather than cluster babysitting — managed Kubernetes hosting changes the equation significantly. But not all managed Kubernetes is created equal. Understanding what security properties you actually need, and which hosting models deliver them, is the difference between meaningful risk reduction and a false sense of security.

The Attack Surface of a Kubernetes Cluster

Before evaluating hosting options, it is worth being precise about what the Kubernetes attack surface actually looks like. Organizations often focus on application-layer security — vulnerability scanning, dependency audits, secret rotation — while underweighting the infrastructure layer. Kubernetes introduces several categories of risk that are distinct from traditional server-based deployments.

The API server is the single point of control for the entire cluster. All kubectl commands, all controller activity, all webhook calls flow through it. An exposed or misconfigured API server is a critical vulnerability. Shadowserver and other threat intelligence organizations have found tens of thousands of publicly reachable Kubernetes API servers on the open internet, many with weak or absent authentication. A compromised API server gives an attacker complete cluster control: they can read all secrets, deploy workloads, exfiltrate data, and pivot to any node.

The supply chain for container images is a persistent and underappreciated risk. A malicious or compromised base image can introduce backdoors that survive application deploys and are invisible to standard runtime monitoring. Without image signing, provenance verification, and admission control policies that reject unsigned or untrusted images, the container registry becomes a critical attack vector.

Workload isolation in Kubernetes is weaker than many teams assume. Containers share a kernel with their host. A container escape vulnerability — and several have been disclosed over the years in runc, containerd, and the Linux kernel itself — can give an attacker host-level access, from which the entire cluster is effectively compromised. Pod Security Admission, seccomp profiles, AppArmor, and restricted namespace policies all matter, but they require deliberate configuration that is rarely done correctly by default.

Lateral movement within a cluster is significantly easier than in traditional network environments. By default, Kubernetes allows all pods to communicate with all other pods across all namespaces. Without network policies enforcing a zero-trust posture — deny by default, allow only specific flows — a compromised workload can probe, attack, and exfiltrate data from any other workload in the cluster.

Secrets management remains problematic despite years of tooling improvements. Kubernetes Secrets are base64-encoded by default, not encrypted. Without encryption at rest enabled on etcd, anyone with access to the etcd data store has access to every secret in the cluster. Even with encryption at rest, Secret sprawl — credentials scattered across dozens of namespaces, mounted as environment variables, logged inadvertently — is endemic in real-world clusters.

What Managed Kubernetes Actually Handles

The appeal of managed Kubernetes — whether EKS, GKE, AKS, or a specialist provider — is the transfer of operational burden. But what specifically gets transferred, and what remains your responsibility, varies considerably between providers and service tiers.

At minimum, a managed Kubernetes service should handle control plane availability and upgrades. This means the API server, scheduler, controller manager, and etcd are operated by the provider, with SLAs on availability and a process for version upgrades that does not require manual etcd backups and cluster recreations. This alone eliminates a significant category of operational risk.

Better managed services add node management: automated node group scaling, OS patching, node replacement on health failures, and integration with the cluster's workload scheduling. This ensures nodes do not drift into unpatched states because no one had time to run the upgrade playbook.

The most comprehensive managed offerings extend to security posture management: baseline security configurations enforced on new clusters, continuous compliance scanning, network policy templates, built-in secrets encryption, audit log forwarding, and integration with runtime security tools. This is where managed Kubernetes transitions from operational convenience to genuine security capability.

What managed services almost never handle — regardless of provider — is the security of your workloads themselves. Pod Security policies, RBAC design, secret management practices, image provenance, network policy rules: these remain your responsibility. A managed cluster running on a hardened control plane is not a secure cluster if the workloads on it have overprivileged service accounts, unscanned images, and no network isolation.

Security Baselines That Should Be Non-Negotiable

CIS Kubernetes Benchmark compliance is the starting point for any serious security posture. The Center for Internet Security publishes a detailed benchmark covering API server configuration, controller manager settings, scheduler configuration, etcd security, node configuration, and RBAC policies. Running kube-bench against your cluster gives you a baseline assessment. Providers that have pre-configured their managed clusters to CIS benchmark standards save significant hardening effort.

Pod Security Admission should be configured at minimum in the baseline profile for all namespaces, with restricted enforced wherever feasible. The restricted profile prevents privilege escalation, requires non-root containers, prohibits host namespace access, and enforces read-only root filesystems. These controls directly mitigate container escape scenarios and limit what an attacker can do with a compromised workload.

Network policies should be deployed with a default-deny-all posture. Every namespace should have an ingress and egress deny-all policy as its baseline, with explicit allow rules layered on top for required communication paths. This is the Kubernetes equivalent of firewall whitelisting and is fundamental to containing lateral movement. Calico, Cilium, and other CNI implementations extend this with more granular policy and Layer 7 controls.

RBAC design should follow least privilege rigorously. Service accounts should have only the permissions required for their specific function, bound to specific namespaces rather than cluster-wide. ClusterAdmin bindings should be audited and minimized. Periodic RBAC audits help identify over-provisioned identities before they become a liability in an incident.

Secrets encryption at rest should be confirmed, not assumed. For managed clusters, confirm with the provider that etcd encryption is enabled by default and that key management is handled with appropriate isolation from the encrypted data.

Runtime security via tools like Falco provides behavioral monitoring that catches threats static analysis cannot: unexpected process execution inside containers, suspicious network connections, filesystem access to sensitive paths, and privilege escalation attempts. Alerts should be forwarded to your SIEM for correlation and response.

The Norwegian Compliance Context

Organizations operating in Norway face a specific regulatory environment that shapes how Kubernetes security must be approached. GDPR implementation in Norway is enforced by Datatilsynet, which has demonstrated a willingness to issue substantive fines for data protection failures. The Norwegian Security Act (Sikkerhetsloven) imposes additional requirements on organizations handling sensitive national security information. NSM's security recommendations (Grunnprinsipper for IKT-sikkerhet) provide a national baseline that increasingly aligns with international frameworks like NIST CSF and ISO 27001.

For Kubernetes specifically, Norwegian compliance requirements have several concrete implications. Data residency — where container data, logs, and secrets physically reside — matters for GDPR. Running workloads on a managed Kubernetes platform whose underlying infrastructure is located in EU or EEA data centers is a prerequisite for many Norwegian organizations. Providers that route cluster management traffic or store audit logs outside the EU introduce GDPR complications that legal teams will rightly flag.

Audit logging is another area where compliance requirements align with security best practice. Datatilsynet expects organizations to be able to demonstrate who accessed what data and when. Kubernetes API server audit logs provide this trail for cluster-level operations. Both infrastructure and workload-level logging should be centralized, tamper-evident, and retained for the periods required by applicable regulation.

Incident response preparedness is increasingly scrutinized in Norwegian regulatory contexts. Organizations should be able to demonstrate not just that they have security controls in place, but that those controls are tested, that incidents can be detected and contained, and that breach notification processes work within the 72-hour GDPR notification window.

Evaluating Hosted Kubernetes Providers

When evaluating managed Kubernetes hosting providers, the marketing language is almost uniformly positive. The questions that actually differentiate providers are more specific.

Where is the control plane running, and can you confirm data residency? For Norwegian organizations, this means EU/EEA data centers with documented data processing agreements that meet GDPR requirements. Ask specifically where etcd data is stored, where audit logs are written, and whether any cluster management operations transit infrastructure outside the EU.

What is the upgrade cadence and how are upgrades handled? Kubernetes releases a minor version approximately every four months, and upstream support windows are relatively short. A managed provider that cannot keep pace with upstream releases leaves you running end-of-life versions with unpatched CVEs.

What security certifications does the provider hold, and what do they cover? ISO 27001 and SOC 2 Type II are not guarantees of security, but they demonstrate that the provider has implemented and audited controls. Confirm whether the certification scope includes the Kubernetes control plane infrastructure.

What runtime security monitoring is built in versus add-on? Understanding what you get without additional configuration or cost avoids discovering gaps at incident time.

What is the incident response SLA, and how does communication work? If the provider detects a security event affecting your cluster, what is the notification process and what actions can they take unilaterally? These questions are rarely asked during procurement and are consistently important when incidents occur.

ZeroSubnet Managed Kubernetes

ZeroSubnet operates managed Kubernetes infrastructure from Norwegian and Nordic data centers, with a security model designed for organizations that need both operational simplicity and genuine compliance assurance. The platform implements CIS benchmark recommendations by default, with Pod Security Admission in restricted mode, network policies enforcing zero-trust pod communication, and etcd encryption using KMS-managed keys.

Audit log forwarding, runtime security monitoring, and RBAC review tooling are included in the standard service tier. For Norwegian organizations subject to Datatilsynet oversight or NSM recommendations, ZeroSubnet provides the data processing agreements and technical documentation required to demonstrate compliance — including data residency confirmation, audit log retention configurations, and incident notification procedures.

The Build Versus Buy Decision

The decision between self-managed Kubernetes and a managed hosting service comes down to where you want to invest engineering time and expertise. Self-managed clusters offer maximum flexibility and can be cheaper at scale if you have the platform engineering talent to operate them correctly. Managed clusters offer predictable operational overhead, faster time to production, and — if the provider is chosen carefully — a security baseline that is difficult to replicate without dedicated effort.

The hidden cost of self-managed Kubernetes is often underestimated. The engineering time required to stay current with Kubernetes releases, maintain cluster security configurations, respond to CVEs, manage certificate renewal, and operate etcd reliably is substantial. When that time is not allocated deliberately, it gets deferred — and deferred maintenance in security-critical infrastructure is how incidents happen.

For most organizations that are not operating Kubernetes as a core competency, managed hosting is the rational choice. The operational overhead is predictable, the security baseline is higher than what most teams achieve on their own, and the engineering time freed up has real value when applied to product development.

Operational Runbooks for Common Security Scenarios

Suspected pod compromise: Isolate the affected pod by applying a network policy blocking all ingress and egress. Capture the running container filesystem and process list for forensic analysis. Terminate the pod. Review the image provenance. Check audit logs for API calls made by the pod service account in the preceding 24 hours. Rotate any credentials mounted into the pod.

Exposed Kubernetes secret: Identify all workloads with access to the secret. Immediately rotate the underlying credential. Update the Kubernetes Secret. Audit API server logs for any external access to the secret. Review the external system access logs if the secret contained credentials for an external service.

Unauthorized API server access: Identify the source IP and service account. Revoke relevant credentials or RBAC bindings immediately. Review audit logs for all API calls made in the session. Check for new deployments, config map changes, or secret reads. If a node credential was compromised, consider cordoning and draining the affected node.

Node compromise: Cordon the node to prevent new pod scheduling. Drain workloads to healthy nodes. Terminate the node instance. Review what workloads ran on the node and what service account credentials they had access to. Rotate any credentials mounted on affected pods.

Getting to Production Securely

The path to running Kubernetes securely in production is not a single project but an ongoing practice. The cluster you deploy today will face a different threat landscape in twelve months. Kubernetes will have released several new versions. Your workloads will have evolved, introducing new dependencies and new attack surface.

The organizations that run Kubernetes most securely treat cluster security as engineering work rather than a compliance checkbox. They invest in tooling that makes the right behavior the default. They practice incident response before incidents happen. And they use managed infrastructure where it reduces operational overhead without compromising control.

For Norwegian and Nordic organizations, the combination of strong local data residency requirements, a mature regulatory environment, and a growing Nordic cloud provider ecosystem creates both constraints and opportunities. The constraints — data must stay in the EU/EEA, compliance must be demonstrable, incidents must be reportable — are real but manageable with the right infrastructure choices. The opportunity is to build security practices that are genuinely robust, aligned with the regulatory context in which these organizations actually operate.