Why do shared kubeconfigs and shared database users create compliance risk?

Why Shared Credentials Create Audit and Compliance Exposure

Shared kubeconfigs and shared database users are risky because they erase individual accountability at the point where auditors need it most. If a kubeconfig is copied across engineers or a database login is reused by multiple services, the record shows that the credential acted, not who initiated the action. That weakens evidence for access reviews, incident response, and segregation-of-duties testing. NHI Management Group’s research shows that visibility gaps are common, with only 5.7% of organisations having full visibility into service accounts, which makes shared access even harder to govern.

This is why regulators and auditors care about attribution, not just reachability. A shared identity can make a compliant control look present while making the audit trail practically unusable. The issue is described in broader NHI guidance in the Top 10 NHI Issues and in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, both of which frame identity evidence as a governance requirement, not an optional logging enhancement.

In practice, many security teams discover the problem only after an investigation cannot tie an action to a specific operator or service.

How It Works in Practice

A compliant design starts by separating the identity of the workload from the identity of the operator. For Kubernetes, that means treating kubeconfigs as privileged secrets, not convenience files, and avoiding reuse across people, teams, or automation jobs. For databases, it means replacing shared users with named application identities, service-specific roles, or session-based access that can be traced back to an owner. The goal is to preserve attribution without making operations brittle.

Current guidance suggests pairing least privilege with per-actor traceability. In practice, that usually means:

• Each human user authenticates with a unique identity and receives access through role binding, not a shared kubeconfig.
• Each workload uses its own service account or database principal, with narrow permissions and defined ownership.
• Credential issuance, rotation, and revocation are automated so access can be reviewed and removed without waiting for manual cleanup.
• Audit logs preserve both the shared resource that was touched and the upstream identity that approved or initiated the action.

This approach aligns well with NIST Cybersecurity Framework 2.0 because the framework expects organisations to manage access in a way that supports detection, response, and governance. It also maps to NHI lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where creation, rotation, and offboarding are treated as control points. Where possible, use short-lived credentials and tie every privileged action to a named person or workload owner.

These controls tend to break down in legacy clusters and shared enterprise databases because the platform only supports one reusable login, making attribution dependent on compensating controls rather than native identity design.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, so organisations have to balance auditability against deployment speed and support burden. That tradeoff becomes obvious in older environments, emergency break-glass access, and vendor-managed systems where shared users are embedded in the product design. Best practice is evolving here, and there is no universal standard for how much shared access is acceptable in every environment.

One common exception is a temporary administrative account used during an incident. Even then, the account should be time-bound, approved, and attributable to a specific responder. Another edge case is service-to-service database access, where the service user may be shared by a replica set or app tier. In that case, the risk can be reduced only if the application emits strong internal attribution, such as request IDs, operator approval records, and immutable logs that identify the initiating workload or change ticket.

The compliance concern is strongest when shared credentials cross trust boundaries, support multi-user admin teams, or grant write access to regulated data. The same principle appears in NHI research on secrets exposure and audit readiness in Ultimate Guide to NHIs — Key Challenges and Risks and in the broader breach patterns covered by Ultimate Guide to NHIs — Key Research and Survey Results. The practical test is simple: if an auditor cannot tell who really acted, the control is not complete.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do AI power users create more governance risk than casual users?
• Why do inaccurate identities create compliance risk?
• Why do unmanaged USBs and printers create CMMC compliance risk?