Kubernetes Security Testing Basics for Small Teams

On 19 March 2026 the Kubernetes Security Response Committee announced CVE-2026-4342, a comment based nginx configuration injection in ingress-nginx, rated high at CVSS 3.1 8.8. The advisory says it can lead to arbitrary code execution in the controller and disclosure of Secrets the controller can access, and that in a default installation the controller can read all Secrets cluster wide.

That is a clean example of what a Kubernetes security test is for. The flaw was in a component many clusters run, the blast radius depended on RBAC, and the fix was an upgrade nobody had put on a calendar.

What's affected

The advisory covers ingress-nginx below v1.13.9, below v1.14.5 and below v1.15.1. Fixed versions are v1.13.9, v1.14.5 and v1.15.1. The advisory's mitigation section is blank: upgrading is the only remedy it lists. Clusters without ingress-nginx pods are not affected.

More broadly, a cluster test usually looks at four layers: who can reach the API, what each identity may do, what a compromised pod can reach, and what is running that nobody patches.

How to check if you're exposed

Start with the advisory's own check:

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

Then five checks a tester would run in the first hour:

# 1. Who is cluster-admin?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

# 2. What can the default service account do?
kubectl auth can-i --list --as=system:serviceaccount:default:default

# 3. Which namespaces have no network policy?
kubectl get networkpolicy --all-namespaces

# 4. Is anything running privileged?
kubectl get pods -A -o json | \
  jq -r '.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.namespace + "/" + .metadata.name'

# 5. Run the CIS benchmark checks
kubectl apply -f job.yaml        # from the kube-bench repository
kubectl logs job/kube-bench

kube-bench runs the checks in the CIS Kubernetes Benchmark and the repository ships platform specific job files for EKS, GKE and AKS.

What to do now

1. Upgrade ingress-nginx to a fixed version if you run it, and watch for suspicious data in the rules.http.paths.path field of Ingress resources, which the advisory names as a detection signal.
2. Remove system:masters from daily use. The Kubernetes checklist says after bootstrapping neither users nor components should authenticate as system:masters, which is a break glass mechanism.
3. Tighten RBAC. The Kubernetes RBAC good practices page warns about wildcard permissions, about list and watch on Secrets (which reveal contents just like get), and about permission to create workloads, which implicitly grants access to Secrets, ConfigMaps and any service account in the namespace.
4. Enforce Pod Security Standards. Baseline disallows privileged pods, host namespaces and hostPath volumes. Restricted adds further hardening such as non-root users and no privilege escalation.
5. Add default deny network policies in every namespace, then open only what each workload needs.
6. Block pod access to the cloud metadata address 169.254.169.254 unless a workload needs it.
7. Check API exposure. The checklist warns that many managed distributions expose the API server publicly by default, and that the API server, kubelet and etcd should not be reachable from the internet.

How to avoid this trap

• Track cluster add-ons like applications. Ingress controllers sit on the edge and often hold broad Secret access, so they belong on your patch calendar.
• Give controllers the least RBAC that works. The advisory's impact was large because the default controller reads all Secrets.
• Review RBAC on a schedule. The Kubernetes checklist suggests access reviews no more than 24 months apart; for a small team, quarterly is easy.

Why it matters

Clusters grow by accretion. Each tool added to the cluster brings a service account, and each service account is a path an attacker can walk after one foothold. A test is a way of walking those paths before someone else does, and the findings are usually configuration rather than code.

Try it yourself

Run the five checks above on a non production cluster. Write down anything you cannot justify, such as a cluster-admin binding for a CI tool or a namespace with no network policy, and bring that list to the tester as your starting scope.

Quick check

Sources

• Kubernetes security advisory: CVE-2026-4342 ingress-nginx (19 March 2026)
• Kubernetes security checklist
• Kubernetes RBAC good practices
• Kubernetes Pod Security Standards
• kube-bench