Kubernetes access, secrets and IaC controls need tighter governance

At a glance

What this is: This release focuses on identity-driven Kubernetes access, centralized secrets handling, and infrastructure-as-code governance to reduce direct access and hard-coded credential risk.

Why it matters: It matters because Kubernetes, secrets, and automation now sit in the same governance chain, and IAM, PAM, and NHI teams need controls that cover all three without losing auditability.

👉 Read SSH Communications Security's analysis of Kubernetes access, secrets, and IaC governance

Context

Kubernetes access becomes an identity governance problem when users, applications, and automation all need privileged paths into the same clusters. The core issue is not convenience versus control, but whether access is brokered, recorded, and revoked before it reaches critical infrastructure.

This release frames that problem across three layers: interactive cluster access, secret retrieval for workloads, and configuration management for privileged policies. For IAM and PAM teams, the operational question is how to remove direct access paths without creating opaque automation paths that are harder to review, certify, or offboard.

Key questions

Q: How should security teams govern Kubernetes access without giving users direct cluster credentials?

A: Use a brokered access model that authenticates the user, authorises each request, and records the session before the command reaches the Kubernetes API server. That approach reduces standing exposure and creates a reviewable audit trail. The key is to make the intermediary the enforcement point, not a convenience layer.

Q: Why do hard-coded Kubernetes secrets create lasting governance risk?

A: Because the problem is not only where the secret is stored, but whether its full lifecycle is controlled. If credentials remain in manifests, images, or repositories, rotation and offboarding are already compromised. Governance has to cover creation, distribution, update, and deletion across the entire path.

Q: How do teams know whether infrastructure as code is increasing privilege risk?

A: Look for policy files, roles, or automation credentials that can reproduce the same access pattern across multiple environments without review. If a bad entitlement can be propagated by pipeline, the organisation has encoded privilege creep into software. Effective governance requires approvals, version control, and separation of duties around the automation itself.

Q: What should organisations review first when automating Kubernetes access and deployment?

A: Start with the identities used by the automation, the scope of permissions assigned to them, and the evidence they generate during change execution. If automation can modify access, deliver secrets, or upgrade components without clear accountability, the governance model is too weak for production use.

How it works in practice

API proxy brokering for kubectl and Kubernetes API access

An API proxy changes the trust boundary by placing an intermediary between the operator and the Kubernetes API server. Instead of granting direct cluster credentials, the access layer intercepts requests, authenticates the user, authorises the action, and can record the session before the request reaches the cluster. That design reduces exposure from standing credentials and gives security teams a point to enforce RBAC and monitor activity. The technical value is not just masking the cluster endpoint, but making the access path visible and enforceable at runtime.

Practical implication: replace direct cluster access with brokered access paths that can enforce authentication, authorisation, and session logging centrally.

Kubernetes external secrets and vault-backed credential delivery

External Secrets Operator patterns decouple application configuration from embedded secrets by syncing values from an external vault into Kubernetes Secret objects. This reduces the risk of hard-coded credentials in manifests, images, and repositories, but it also introduces a synchronisation trust chain: the workload now depends on the vault, the operator, and the cluster object lifecycle staying in sync. From a governance perspective, this is stronger than embedding secrets, but only if rotation, scope, and deletion are controlled across both the source vault and the target cluster object.

Practical implication: treat secret synchronisation as a governed distribution channel, not as a substitute for secret lifecycle control.

Terraform and Ansible as privilege and deployment control planes

Infrastructure as code turns access and deployment into versioned configuration, which is useful only if the code is treated as a privileged control surface. Terraform can define roles, access groups, targets, permissions, and policies, while Ansible can standardise installation and upgrade steps. The benefit is consistency, but the security challenge is that policy drift, mis-scoped roles, or reused automation credentials can propagate quickly across environments. IaC improves repeatability, but it also makes the blast radius of a bad change larger unless change control and approvals are explicit.

Practical implication: govern IaC repositories and automation credentials as privileged assets with review, approval, and separation of duties.

NHI Mgmt Group analysis

Identity-driven Kubernetes access is only safer when the broker becomes the enforcement point, not just the convenience layer. Direct cluster credentials are the old failure mode, but proxying access does not automatically solve governance unless the proxy is the place where authentication, authorisation, and session evidence are enforced. The structural gain is reduced direct exposure, yet the control still depends on whether every privileged path actually traverses the broker. Practitioners should treat the broker as part of the access perimeter, not a cosmetic wrapper around legacy trust.

Hard-coded secrets in Kubernetes are a lifecycle failure, not just a storage mistake. The article’s secrets narrative is really about where credential lifecycle is controlled. If application manifests, container images, or repositories still contain secrets, rotation and offboarding are already broken before runtime begins. The relevant framework lens is OWASP-NHI because the problem is non-human credential exposure across build, deploy, and runtime stages. The practitioner conclusion is that secret origin, distribution, and expiry must be governed as one chain.

Infrastructure as code turns privilege into repeatable software, which means privilege creep can now be replicated at machine speed. Terraform and Ansible make access and deployment more consistent, but consistency is not the same as correctness. A mis-scoped role, reused automation credential, or stale policy file can be propagated into every environment that consumes the pipeline. The relevant control question is whether the organisation can certify the automation itself, not just the environment it manages. Practitioners should govern IaC as a privileged system with the same review discipline applied to production access.

"Brokered access, distributed secrets, and coded privilege" is the right concept for this release. The article connects three separate control planes that often fail in isolation and then amplify each other in production. Kubernetes access, secret delivery, and automation policy should be evaluated together because a weakness in one layer can undermine the others. The field implication is that modern infrastructure governance now spans runtime access, secret lifecycle, and policy-as-code in one operating model.

This release validates the shift from manual administration to governed automation, but it also raises the standard for evidence. When access, secret delivery, and deployment are all automated, organisations need stronger proof that the right identity performed the right action at the right time. Session records, policy versioning, and change history become the minimum audit surface. Practitioners should expect access governance to move closer to continuous verification across both human and machine-operated paths.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 59% of infrastructure leaders cite "confidently wrong" AI configuration as their top fear, which shows that access decisions and configuration trust are now tightly coupled in modern operations.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams map provisioning, rotation, and offboarding across machine identities and automation.

What this signals

Brokered access is becoming the default pattern for high-risk infrastructure, but the governance burden shifts to the intermediary itself. Teams should expect more access control to move into proxies, vaults, and automation layers rather than the target platform. That creates a new accountability question: if the broker fails, the whole access model fails. The practical response is to treat the broker as a production identity control plane, not a utility service.

Secrets distribution and privilege automation now belong in the same operating model. Once credentials are retrieved dynamically and access policies are expressed in code, the boundary between secret management and IAM weakens. For practitioners, that means lifecycle controls, review cadence, and rollback must cover the source vault, the cluster object, and the automation pipeline together.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within the next three years, per the 2026 Infrastructure Identity Survey, infrastructure teams need governance models that can absorb machine-driven change without losing evidence or accountability. That is the direction this release points toward, even if the current use case remains human-operated.

For practitioners

• Broker Kubernetes access through a single enforcement layer Route kubectl and API traffic through an intermediary that can authenticate users, authorise requests, and record sessions before cluster interaction. Preserve audit evidence for every privileged command path and remove direct cluster credentials where possible.
• Separate secret storage from application manifests Move credentials out of code repositories, container images, and deployment manifests. Use an external vault as the source of truth, then govern the synchronisation path into Kubernetes Secret objects as part of the secret lifecycle.
• Treat IaC repositories as privileged control surfaces Apply peer review, change approval, and least-privilege access to Terraform and Ansible workflows that define roles, permissions, and deployment steps. Reuse of automation credentials should be restricted and monitored as tightly as production admin access.
• Verify offboarding and rotation across the full credential chain Check that revocation, rotation, and policy retirement occur across the vault, the cluster object, and the automation that delivers them. A secret is not fully controlled until every dependent path has been updated or removed.

Key takeaways

• This release shows that Kubernetes security, secrets management, and IaC governance now have to be treated as one identity problem.
• Direct cluster access, embedded credentials, and unreviewed automation each widen the blast radius when privilege is still being provisioned like static infrastructure.
• Practitioners should move toward brokered access, external secret delivery, and reviewed automation because those are the controls that preserve accountability at scale.

Key terms

• Brokered Kubernetes Access: A model where requests to a Kubernetes cluster pass through an identity-aware intermediary instead of using direct cluster credentials. The broker authenticates, authorises, and records the session, which reduces standing exposure and creates a reviewable control point for privileged activity.
• External Secrets Synchronisation: The controlled flow that copies secrets from an external vault into Kubernetes Secret objects on demand. It separates secret storage from application configuration, but it still requires lifecycle governance for rotation, expiry, and deletion across both systems.
• Infrastructure As Code Privilege: The practice of expressing roles, permissions, targets, and policies in versioned automation rather than manually configuring them. It improves consistency, but it also turns the codebase and its credentials into privileged assets that need approval and audit controls.

Deepen your knowledge

Kubernetes access brokered through identity-aware controls is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening cluster, secrets, and automation governance at the same time, it is a relevant starting point.

This post draws on content published by SSH Communications Security: modern infrastructure access, secrets, and automation governance in the latest PrivX release. Read the original.