How should teams govern proxy-based access to databases and Kubernetes?

Why This Matters for Security Teams

Proxy-based access often looks safer than direct database or Kubernetes access because the proxy hides backend endpoints and centralises policy enforcement. The risk is that teams stop at the proxy and assume the identity problem is solved. In reality, a proxy is only effective when the underlying workload identity, secret handling, and auditability are also designed for non-human identities. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why proxy layers so often mask, rather than remove, privilege sprawl.

This matters because databases and Kubernetes clusters are high-value targets for lateral movement. If a proxy still brokers long-lived credentials, preserves direct entitlements, or allows fallback access, it can become an extra hop for an attacker instead of a control point for defenders. The OWASP Non-Human Identity Top 10 and current NIST guidance both point toward least privilege, strong lifecycle controls, and traceable machine identity as the baseline, not optional hardening.

In practice, many security teams discover proxy weakness only after a service account, kubeconfig, or database secret has already been reused outside the intended path.

How It Works in Practice

Governance starts with treating the proxy as an enforcement layer that brokers access, not as the authority that defines trust. For databases, that means the proxy should issue short-lived sessions, hide backend credentials from application code, and log the protocol-level action set so investigators can reconstruct what happened. For Kubernetes, the proxy or access gateway should mediate cluster entry without exposing static kubeconfigs or broad RBAC bindings that outlive the task.

Teams usually need three controls working together:

• Ephemeral credentials or certificates issued just in time, then revoked automatically when the task ends.
• Workload identity that proves what the service or agent is, rather than relying on a shared secret alone.
• Policy checks at request time, so access depends on current context such as namespace, database, workload, environment, or approval state.

This is where proxy design intersects with the broader NHI lifecycle. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs emphasises rotation, offboarding, and visibility as lifecycle controls, while the Top 10 NHI Issues highlights how often excess privilege and leaked secrets remain the real root cause. The practical test is simple: if an attacker steals the proxy’s backend credential, can they still reach the target directly, or has the proxy fully isolated that trust path? Current best practice suggests the latter must be true, because proxy-mediated access without backend secret suppression leaves the original attack surface intact.

Security teams should also validate that logs capture the database statements, Kubernetes API actions, and identity context needed for incident response, not just a generic “proxy allowed access” event. These controls tend to break down in legacy clusters and shared database estates because direct entitlements and hard-coded secrets remain embedded in deployment pipelines, admin tooling, or operator-run break-glass paths.

Common Variations and Edge Cases

Tighter proxy control often increases operational overhead, requiring organisations to balance stronger containment against developer friction and incident-response complexity. That tradeoff becomes especially visible in hybrid estates, where some databases support fine-grained session brokering and others only tolerate coarse connection-level mediation.

There is no universal standard for this yet, but current guidance suggests a few common exceptions need explicit handling. Break-glass access may still require standing privilege for a very short, audited window. Long-running batch jobs may need renewable credentials rather than one-shot access. Kubernetes service-to-service flows can also be complicated by namespace sharing, admission controllers, and operators that need elevated access for maintenance. In those cases, proxy governance should be paired with boundary rules, approval workflows, and measurable expiry.

The most dangerous edge case is a proxy that protects the front door while leaving a second, direct path open through cloud IAM, admin credentials, or an internal network route. When that happens, the proxy creates a false sense of confinement. The Ultimate Guide to NHIs — Key Challenges and Risks makes clear that overexposure and weak offboarding remain common failure modes, so the governance question is always whether the proxy eliminated standing privilege or merely obscured it.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern privileged access to databases, servers, and Kubernetes?
• How should security teams govern privileged access as NHI use expands?