Notifications
Clear all
Topic starter
06/06/2026 11:19 am
TL;DR: The governance question is no longer whether access can be automated, but whether IAM can still see and control the resulting privilege paths, according to SSH Communications Security research. Its latest PrivX release adds API-Proxy controls for Kubernetes, external secrets integration, Terraform-based access configuration, and Ansible deployment automation, aiming to reduce direct cluster access, hard-coded credentials, and manual privilege management.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Separate secret storage from application manifests Move credentials out of code repositories, container images, and deployment manifests.
- 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.
What's in the full announcement
SSH Communications Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step PrivX configuration for Kubernetes API brokering and session monitoring
- Operational details on external secrets synchronisation into Kubernetes Secret objects
- Terraform role, target, and policy management examples for privileged access governance
- Ansible installation and upgrade playbooks for standardised deployment lifecycle automation
👉 Read SSH Communications Security's analysis of Kubernetes access, secrets, and IaC governance →
Kubernetes access and secrets governance: what changes for IAM teams?
Explore further
06/06/2026 12:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes access, secrets and IaC controls need tighter governance
