Yes, because cluster-by-cluster review misses duplicate grants, orphaned roles, and inconsistent bindings that appear only when you compare environments. Centralised review gives teams a reliable view of roles, role bindings, and service accounts before access drift becomes normal. Without that view, certification is mostly paperwork.
Why centralised Kubernetes access review is the safer operating model
Centralised review is the better default because Kubernetes access is distributed across clusters, namespaces, and binding layers, while the actual risk is often duplicated or inconsistent privilege. A single review view helps security and platform teams compare roles, role bindings, and service accounts across environments, instead of certifying each cluster in isolation and missing access drift that accumulates quietly.
In practice, the question is less about convenience than about whether reviewers can see the full entitlement picture. If the review process cannot compare identical patterns across clusters, it will miss the difference between a justified exception and a repeated overgrant. That is especially true when service accounts and workload permissions are reused across environments.
Centralisation also makes ownership clearer. One control plane for review does not mean one team must own every Kubernetes decision, but it does mean the certification evidence, approval logic, and exception handling can be standardised. That reduces the common failure mode where each cluster team interprets access rules slightly differently and the organisation treats those differences as acceptable by default.
What centralised review should actually cover
The review scope needs to include the Kubernetes objects that determine effective access, not just human accounts. That means roles, cluster roles, role bindings, cluster role bindings, service accounts, and any federated or externally granted access path that ends up with execution authority inside the cluster. If those are not reviewed together, the organisation is only seeing fragments of the real privilege model.
Centralised review is most useful when it highlights patterns, such as a service account that appears in several clusters with different permissions, a binding that exists in production but not lower environments, or a role that was copied forward long after the original use case changed. Those are the kinds of inconsistencies that do not look alarming inside one cluster but become obvious when compared across the estate.
A mature programme should also distinguish between administrative access, application access, and automation access. Kubernetes often blurs those lines, especially where platform teams, deployment tooling, and workloads all rely on related identities or tokens. A central review process is valuable because it lets reviewers test whether the same binding pattern is serving a legitimate platform function or simply surviving because nobody owns it anymore.
Why cluster-by-cluster certification breaks down at scale
Cluster-local review tends to produce fragmented decisions. The reviewer can approve access that looks reasonable in isolation, even when the same principal has equivalent access in multiple clusters and the combined effect is excessive. That creates privilege creep, duplicate grants, and orphaned bindings that are hard to detect when each review is conducted as a separate exercise.
It also encourages paper compliance. If the evidence package only shows one cluster at a time, the review may look complete while still missing the broader access pattern. Kubernetes NHI Security Guide is useful here because it ties together service accounts, RBAC, tokens, and admission controls, which is the level where the real review burden sits. IAM and IGA Basics and Access Reviews and Certification Guide both reinforce the point that certification should close access, not merely record that someone glanced at it.
At scale, the issue becomes lifecycle drift. A binding that was justified during an incident, a migration, or a temporary integration can remain in place long after the business reason is gone. Centralised review gives teams a better chance of finding those long-lived exceptions before they turn into normal operating access.
Risk and Threat Considerations
Centralising review reduces exposure from privilege accumulation, but it only works if the review dataset is complete and current. The main risk is false confidence: teams may believe access is controlled because reviews happen regularly, while duplicated grants, stale bindings, and overprivileged service accounts remain spread across clusters.
Failure mechanism: Review scope is limited to one cluster or one reviewer team, so equivalent access paths are never compared side by side. That allows excessive privilege, orphaned roles, and reused service accounts to persist unnoticed until a compromise or audit exposes the gap.
Impact: The organisation loses visibility into effective Kubernetes privilege, which increases blast radius, complicates incident response, and weakens audit evidence. In a real incident, an attacker or insider who obtains one cluster path may be able to reuse the same pattern elsewhere if central review never forced a cross-cluster comparison.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Centralised Kubernetes review exists to limit excessive cluster privilege. |
| IA-5 — Authenticator Management | Kubernetes service accounts and tokens are identity-bearing material that must be reviewed and rotated. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Cross-cluster review depends on consolidated evidence and exception analysis. | |
| Recommendation — Enforce least privilege across Kubernetes roles, bindings, and service accounts. Track and rotate Kubernetes tokens and secrets used for cluster access. Review audit evidence centrally to detect duplicated or stale Kubernetes access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cluster review concerns discovery, approval, and removal of active access paths. |
| Recommendation — Inventory and review Kubernetes accounts, roles, and service accounts centrally. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Cross-cluster certification is meant to catch repeated overgranting of non-human access. |
| Recommendation — Remove repeated overprivilege from Kubernetes service accounts and bindings. | ||
Practitioner Guidance
What to verify: Review the same principal across all clusters, not just per environment, and confirm that roles, bindings, and service accounts are reconciled against an authoritative inventory. The review should surface duplicates, stale grants, and differences in effective privilege, not merely confirm that each cluster has an owner.
Decision rule: If a Kubernetes identity or binding can be replicated across clusters, treat cross-cluster comparison as mandatory before approval. If the review cannot show that the access pattern is unique, time-bound, or intentionally reused, treat it as an exception that needs explanation.
What good looks like: Reviewers can see a consolidated entitlement view, exceptions are documented once, and revoked access disappears from every cluster rather than only from the one that happened to be reviewed. That is the difference between governance that reduces risk and governance that only produces records.
Practitioner takeaway: Centralised access review is valuable only when it changes the decision from “is this cluster acceptable?” to “is this access acceptable anywhere in the fleet?”
Related resources from NHI Mgmt Group
- When should organizations review access controls?
- What should organisations review first when automating Kubernetes access and deployment?
- Should organisations centralise all server, database, and Kubernetes access in one control plane?
- What breaks when organisations try to review access manually across nested groups and foreign security principals?