Should organisations centralise all server, database, and Kubernetes access in one control plane?

Why This Matters for Security Teams

Centralising server, database, and Kubernetes access can improve visibility, revocation speed, and policy consistency, but it also creates a higher-value control plane that must be secured like production infrastructure. For non-human identities, the core question is not whether access is centralised for convenience, but whether privileged paths are discoverable, scoped, and revocable without leaving long-lived secrets behind. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which explains why distributed access often survives unnoticed.

Security teams often assume one platform automatically means stronger control, yet the real risk is hidden entitlements in kubeconfigs, database roles, bastions, CI/CD tokens, and cloud-native service accounts. The OWASP Non-Human Identity Top 10 treats credential sprawl and over-privilege as first-order failure modes, not edge cases. In practice, many security teams encounter account sprawl only after an incident review reveals that the “centralised” system was still being bypassed through legacy paths.

How It Works in Practice

Effective centralisation is less about forcing every access request through one login portal and more about establishing one policy and identity layer that can govern many targets. For servers, that usually means brokered SSH or session-based access with short-lived certificates, session recording, and approval workflows. For databases, it means role-scoped access, just-in-time elevation, and revocation tied to workload or operator identity rather than shared passwords. For Kubernetes, it means controlling cluster-admin exposure, mapping human and non-human access separately, and replacing static kubeconfigs with time-bound tokens and audited access paths.

The practical model is a control plane that evaluates access at request time, not a static role list assigned months earlier. Guidance from the NIST AI Risk Management Framework and zero-trust approaches aligns with this pattern: authenticate the requester, verify the context, issue the minimum necessary privilege, and revoke it quickly. NHIMG’s Key Challenges and Risks research shows why this matters: many organisations still store secrets outside proper managers, which means “centralised access” can be undercut by scattered credentials.

• Use one identity authority, but not necessarily one user interface, for all infrastructure access.
• Prefer short-lived credentials and brokered sessions over static SSH keys, kubeconfigs, or database passwords.
• Separate privileged human access from workload identity and service-to-service access.
• Record sessions and changes where the target system is sensitive enough to warrant forensic review.
• Revoke centrally, but also hunt for direct paths that bypass the control plane.

These controls tend to break down in highly elastic multi-cluster environments when teams allow local emergency access paths that are never reconciled back to the central policy layer.

Common Variations and Edge Cases

Tighter centralisation often increases operational overhead, requiring organisations to balance standardisation against platform resilience and team autonomy. That tradeoff is real: database administrators, SRE teams, and incident responders may need different workflows, and there is no universal standard for exactly how much should be centralised. The best practice is evolving toward central policy with environment-specific enforcement, rather than forcing identical tooling across every estate.

Edge cases usually appear where the target system cannot support modern federation, short-lived tokens, or session recording. Legacy databases, air-gapped servers, and some Kubernetes add-ons still depend on static credentials or local admin accounts, so a full control-plane model may need compensating controls such as vaulting, stronger rotation, and break-glass governance. NHIMG’s 52 NHI Breaches Analysis shows a recurring pattern: breaches often follow privilege accumulation and credential reuse, not the mere fact that access was centralised. Where operations demand fast emergency access, the control plane should allow time-boxed exceptions with post-incident review instead of permanent bypasses.

For teams working toward Kubernetes and infrastructure convergence, the safest rule is to centralise policy and telemetry first, then gradually centralise issuance and revocation as systems can support it. That sequence reduces risk without pretending every workload can be forced into the same access model today.

Related resources from NHI Mgmt Group

• When should organisations re-evaluate database access controls for AI workloads?
• What do IAM and security teams get wrong about GenAI access control?
• What should organisations do when agent access keeps expanding during pilots?
• Should organisations treat MCP server collaboration as a Zero Trust problem?