Notifications
Clear all
Topic starter
22/07/2026 4:37 pm
TL;DR: Remote Kubernetes fleets often sit behind NAT, CGNAT, and customer-controlled firewalls, while each kubeconfig file embeds long-lived credentials that expand blast radius as the fleet grows, according to Teleport. The governance shift is from device-by-device static access to short-lived, identity-bound sessions with unified auditability across the fleet.
NHIMG editorial — based on content published by Teleport: Securing kubectl on Remote Kubernetes Clusters Without Static Credentials or VPNs
Questions worth separating out
Q: How should teams replace kubeconfig-based access for remote Kubernetes clusters?
A: Use an identity-bound gateway that issues short-lived credentials at session start and keeps the cluster API private behind outbound-only connectivity.
Q: Why do remote Kubernetes fleets make access reviews harder?
A: Because each cluster often has its own kubeconfig, RBAC policy, and local audit trail.
Q: What breaks when Kubernetes authentication relies on static credentials?
A: Static credentials break the governance model because access persists until someone finds and revokes the secret.
Practitioner guidance
- Inventory every kubeconfig distribution path Map where kubeconfigs are stored, copied, and reused across laptops, CI/CD systems, and shared storage.
- Move edge cluster access to outbound-only paths Prefer a reverse-tunnel or proxy-mediated model that keeps the Kubernetes API private and avoids inbound ports on customer-controlled networks.
- Consolidate SSH and kubectl into one audit boundary Use one authenticated gateway for host access and cluster administration so session recording, attribution, and authorisation are logged in the same place.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step access flow for reverse tunnels across K3s and MicroK8s clusters behind NAT and CGNAT.
- Examples of how unified SSH and kubectl routing reduces separate policy and logging paths.
- Implementation details for short-lived certificate issuance tied to SSO authentication.
- Label-based discovery and enrollment patterns for managing large edge fleets.
👉 Read Teleport's guide on securing kubectl for remote Kubernetes clusters →
Edge Kubernetes access without kubeconfigs: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
22/07/2026 4:41 pm
Static kubeconfig sprawl is an identity governance failure, not a Kubernetes convenience issue. The file is a shared credential, so every extra copy adds a new revocation, audit, and containment burden. In edge fleets, that burden scales faster than the team that must manage it, which is why the governance model breaks before the infrastructure does. Practitioners should treat kubeconfig distribution as lifecycle-controlled identity material, not as a deployment artefact.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: Who is accountable when remote cluster access spans SSH, kubectl, and compliance evidence?
A: The organisation operating the access model remains accountable, even if the device is on a customer network. Governance teams should ensure one approved identity path, one policy boundary, and one evidence record cover all administrative access to the cluster.
👉 Read our full editorial: Securing kubectl on edge clusters without static credentials
