Four Kubernetes CVE records now show unfixed design risks affecting all versions; map scanner findings to RBAC, DNS, and admission controls. Full breakdown.
What “unfixed” Kubernetes CVEs actually mean
When CVE records for Kubernetes stay open as design risks rather than patchable bugs, scanners will keep flagging them on every cluster. That is not a failure of your upgrade pipeline. Design-class findings usually describe behavior that is intentional in the control plane or node stack, so there is no version you can jump to that removes the underlying model. The practical response is to treat those findings as permanent control requirements: reduce who can exercise the risky path, limit how far it reaches, and prove those limits with policy you can audit.
Read each finding as a capability story. What principal can trigger it? From which network path? With which API verbs or in-cluster services? If the answer is “any authenticated subject with broad defaults,” your work is to shrink that surface, not to wait for a green scan.
Map scanner noise to RBAC first
Most Kubernetes design risks become exploitable only when identities are over-privileged. Start by tying each unfixed CVE finding to the Role, ClusterRole, ServiceAccount, or user group that would need elevated verbs to abuse it. Prefer namespaced Roles over ClusterRoles, drop wildcard verbs and resources, and separate controllers so a single leaked token cannot both read secrets and mutate cluster-scoped objects.
Use short-lived tokens, bound ServiceAccounts, and least-privilege bindings for CI, operators, and human break-glass accounts. After you tighten bindings, re-run the scanner and confirm the same CVE still appears only as residual design risk—while related misconfiguration findings for excess privileges disappear. That distinction tells you the control is working even though the CVE ID will not vanish from the report.
Contain DNS and network paths
Several long-lived Kubernetes concerns sit at the intersection of cluster DNS, pod networking, and trust in in-cluster resolution. Harden by assuming name lookup and east-west traffic are hostile until proven otherwise. Restrict which namespaces can resolve or reach sensitive services, prefer NetworkPolicies that default-deny and allow only explicit egress to the DNS service and required backends, and avoid granting pods the ability to rewrite DNS-related ConfigMaps or CoreDNS configuration unless that is a dedicated, tightly bound admin role.
Where scanners cite DNS or service-discovery design issues, document the compensating controls next to the finding: which NetworkPolicies apply, which ServiceAccounts own DNS admin paths, and which workloads are isolated from cross-namespace resolution. That turns a permanent CVE line item into an evidence package for platform review.
Close the gap with admission controls
RBAC and network policy define who may do what at runtime; admission controls stop unsafe objects before they land. Map each unfixed design risk to validating or mutating policies that enforce the behaviors you actually want: deny privileged or host-namespace pods unless labeled and approved, require non-root and drop dangerous capabilities, block hostPath and unrestricted volume types where they are not needed, and reject wildcard RBAC or cluster-admin bindings created outside a controlled process.
- Gate images and pull policies so only known registries and digests enter the cluster.
- Require explicit labels for break-glass exceptions and alert when those exceptions are used.
- Store policy as code, review changes like application code, and test deny rules in a staging cluster before enforce mode.
Platform hardening for unfixed Kubernetes CVEs is not about clearing every scanner row. It is about owning the residual risk: RBAC that cannot reach the dangerous API path, DNS and network boundaries that limit blast radius, and admission rules that keep unsafe workloads from ever scheduling. Treat the four standing design CVEs as a fixed checklist you re-verify on every cluster, not as noise to mute.