The Kubernetes Security Work That Actually Matters in 2026

In January, the Kubernetes Steering Committee and Security Response Committee published a joint statement with a sentence you rarely see from a project of that size: “Half of you will be affected. You have two months left to prepare.” They were talking about the retirement of ingress-nginx, the controller that routes traffic into roughly half of all cloud native environments. The deadline passed in March. There will be no more releases, no bug fixes, and no security patches, ever, for the component standing between the internet and half the world’s clusters.

That is what Kubernetes security actually looks like in 2026. Not zero-days in the kubelet, not container escapes from a conference talk. A load-bearing component nobody was paid to maintain, credentials nobody rotates, changes nobody reviews. When we look at real clusters, the same five findings account for nearly all of the actual risk, and none of them are exotic. Here they are, each with the incident that proves it is real and the fix that closes it.

Finding 1: A load-bearing component nobody maintains

The ingress-nginx story deserves to be told properly, because it is the security lesson of the year. The project served about 50 percent of cloud native environments and was maintained, for years, by one or two people in their free time. In March 2025 that arrangement produced IngressNightmare (CVE-2025-1974), a CVSS 9.8 unauthenticated remote code execution that could hand an attacker the whole cluster. Eight months later the project announced its retirement, and since maintenance ended this March, new vulnerabilities have already been catalogued against a codebase that will never be patched again. Existing deployments keep working, which is precisely the problem: nothing breaks, so nothing forces the migration, so the exposure quietly compounds.

Check whether this is you, right now:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

If that returns pods, you are running retired software on your network edge, and the community’s recommendation is to migrate to Gateway API or another maintained ingress controller. None of the alternatives are drop-in replacements, which is exactly why this belongs at the top of the backlog rather than the bottom.

The general lesson is bigger than one controller. Your cluster’s security posture is the union of every addon on it, and most teams cannot answer “what versions of what are running where” without an afternoon of kubectl archaeology. This is a place where structure beats vigilance: in Ankra, every addon is a pinned-version node in a stack, so the inventory question is a glance, the AI’s proactive insights flag vulnerable and end-of-life addon versions before they page you, and the migration itself is a stack change that rolls out with dependency ordering and a Git record instead of a hand-run weekend.

Finding 2: Kubeconfigs are the new SSH keys, and they are everywhere

Ask a team how many valid kubeconfigs exist for their production cluster and watch the faces. There is one on every engineer’s laptop, including two who left last year. There is one in CI, with cluster-admin because scoping it down was a ticket nobody took. There is one in a shared vault whose password is in Slack. Static, long-lived, rarely scoped, never rotated: Kubernetes credentials in most organizations are exactly where SSH keys were in 2010.

The fix is the same one SSH eventually got: stop distributing static credentials at all. Access should be identity-based, short-lived, and scoped to the task. This is what Ankra’s Cluster Access grants implement: an admin maps a user to a role (view, edit, admin, cluster-admin) at a scope (whole cluster or a single namespace), the platform reconciles that grant into native Kubernetes RBAC on the cluster, and the user’s kubectl flows through an authenticated proxy using short-lived tokens minted on demand. Nobody holds a static cluster secret, offboarding is deleting a grant, and the QA lead who needs to check one namespace gets view on that namespace instead of the keys to production.

ankra cluster access grant [email protected] --role view --namespace staging

The same principle applies to the machines: the pipeline agents we wired in the CI post hold one revocable API token, not a kubeconfig, and there is no kubeconfig anywhere in the pipeline to leak.

And one structural bonus that costs you nothing: the Ankra agent connects outbound only. Importing a cluster requires no inbound firewall rule and no publicly reachable API server, which removes the single most common Kubernetes exposure, the control plane endpoint that Shodan can find, from the board entirely.

Finding 3: The secret is in Git, and Git is forever

We wrote a full post on this, Secrets Belong in Git. Plaintext Does Not., so here is only the shape: 28.65 million hardcoded secrets landed in public GitHub commits last year, AI-assisted commits leak at roughly double the baseline rate, and the Sisense breach demonstrated what one plaintext credential in one private repo converts into. The fix is SOPS with AGE encryption, initialized once at the organisation level, with --strict-secrets in CI so a plaintext credential is a failed build instead of a code review comment. If you read nothing else on this list, read that one; secrets remain the most reliably exploited finding on it.

Finding 4: Changes nobody reviewed, by humans or their agents

Most production incidents with a security flavor do not start with an attacker. They start with a change: a values edit applied straight to the cluster, a hotfix kubectl’d in during an incident and never written down, a well-meaning AI agent with production credentials doing something “entirely on its own initiative,” as the PocketOS postmortem memorably put it after an agent destroyed their production database and backups in nine seconds. The 2025 wave of AI-agent incidents, which we dissected when we built our guardrails, all reduce to the same missing property: no separation between proposing a change and applying it, and no audit trail the actor could not rewrite.

The fix is a property of your delivery system, not a policy document. Every change, from every surface and every actor, human or AI, goes through the same gate: it lands as a draft or a pull request, a human approves it, and Git records it immutably. In Ankra this is the architecture rather than a convention: the UI, CLI, API, Terraform, and the AI all write through the same engine, the engine writes to Git, and the cluster reconciles from Git. When the auditor asks “who changed the ingress config and who approved it,” the answer is a commit hash, not an interview process. Drift, the gap between what Git says and what the cluster runs, is detected and self-healed by the engine’s reconcile loop, so the unreviewed hotfix does not quietly become the new production state.

Finding 5: latest is not a version, and floating tags are a supply chain

Every unpinned dependency in your cluster definition is a change you have agreed to accept, sight unseen, at a time of someone else’s choosing. A floating chart version means next week’s deploy installs code nobody reviewed. A latest image tag means your rollback target is a moving object. The supply chain attacks that make headlines, poisoned packages, hijacked maintainer accounts, all need a victim who auto-ingests updates, and floating versions are the standing invitation.

The fix costs nothing but discipline: pin exact chart_version on every addon, immutable tags on every image, so that a Git commit fully determines what runs, and an upgrade is a visible diff that says 65.1.1 became 66.0.2, reviewable like any other change. Ankra’s validation checks your cluster definition against your connected registries on every pull request, which turns “does this chart version actually exist where we think it does” into a CI answer instead of a deploy-time surprise.

While we are here, the honorable mention that nearly made the list: unauthenticated internal dashboards. Researchers found roughly 336,000 Prometheus endpoints facing the public internet in late 2024, leaking credentials and API keys through a tool everyone assumes is behind a firewall. If a human can open your Grafana or Prometheus without authenticating, so can everyone else. (Ankra reads metrics through the agent, so powering dashboards and AI analysis requires no publicly exposed endpoint at all.)

What did not make the list, and why

Notice what is absent: service meshes, runtime eBPF sensors, admission controller frameworks, CVE scanners producing four-digit finding counts. Not because those tools are bad, but because they are layer-seven answers bought by teams that have not done the layer-one work. A mesh’s mTLS does not help you when the ingress controller in front of it is unpatched by design, the intern’s kubeconfig is on a stolen laptop, and the database password is in a public repo. Sequence matters. The five findings above are cheaper than any security product, and they close the doors that real incidents actually walked through.

There is also a pattern across all five worth naming. None of them are fixed by vigilance, training, or a wiki page. All of them are fixed by structure: making the safe path the default path, so the insecure option requires effort rather than the secure one. Pinned versions in a stack, grants instead of kubeconfigs, encryption at save time, drafts before deploys. Security that depends on everyone remembering everything fails on the first busy Friday. Security that is a property of the delivery system does not care how busy Friday gets.

The checklist

Run these five checks this week; none takes more than an hour:

1. kubectl get pods -A --selector app.kubernetes.io/name=ingress-nginx. If it returns pods, migration planning starts today.
2. Count the valid kubeconfigs for production. If the answer is not “zero static ones,” move to grant-based, short-lived access.
3. ankra cluster validate -f cluster.yaml --strict-secrets (or grep your repo for password:). Encrypt what you find, then make the check a CI gate.
4. Pick a recent production change and reconstruct who made it, who approved it, and where that is recorded. If the answer involves asking someone, your audit trail is a person.
5. Grep your cluster definition for latest and unpinned versions. Pin them, and let every future upgrade be a reviewable diff.

Five findings, five checks, and none of them require a security team, which is rather the point: a platform that makes them structural means the five-person company and the fifty-person one pass the same review.

Get started: Create a free account on Ankra.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]