TL;DR: Public Kubernetes API access, VPN tunnels and bastion hosts all treat cluster administration as a network problem, according to Twingate, but the real requirement is identity-bound access to one endpoint plus cluster RBAC and pod-level isolation. That shift makes lateral movement harder because compromise no longer grants broad VPC reachability.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Kubernetes API access remains overexposed when teams rely on network reachability instead of identity-bound, endpoint-specific access and cluster RBAC.
Why it matters: This matters because Kubernetes clusters often become reachable to more users and more network paths than intended, which increases blast radius when a laptop, credential or admin workflow is compromised.
Context
Kubernetes administration is often secured as though the problem were network reachability, when the actual control question is who can reach the API server and what they can do once there. IAM and IGA basics remains the right foundation for separating authentication, authorization and entitlement scope in this pattern.
When a cluster API sits behind public endpoints, VPNs or bastion paths, security teams inherit broader network exposure than they need for a single administrative workflow. That is a governance problem as much as an access problem, because the cluster remains reachable through more paths than the task requires.
Key questions
Q: How do I secure kubectl access without exposing the Kubernetes network?
A: Use the Kubernetes API server with strong authentication, then restrict kubectl permissions through Kubernetes RBAC so users and service accounts can only perform approved actions. Avoid exposing the API server on broad networks, and prefer private endpoints, MFA-backed access to the control plane, and short-lived credentials such as OIDC-issued tokens or client certificates.
Q: What is the difference between GKE IAM and Kubernetes RBAC for cluster access control?
A: GKE IAM governs access at the Google Cloud layer, including who can authenticate and request a managed identity path. Kubernetes RBAC governs what that authenticated identity can do inside the cluster, such as reading pods or listing resources in a namespace. Practitioners need both layers aligned, because one without the other leaves gaps in authorization.
Technical breakdown
Why public Kubernetes API endpoints expand exposure
A public API endpoint makes the control plane discoverable from the internet, which shifts the problem from authenticated access to internet-reachable service hardening. Even with an OIDC token or IP allowlist, the cluster still presents an externally reachable surface that can be scanned, probed and misused if surrounding controls are weak. The operational issue is not only authentication, but the fact that the endpoint itself is exposed before identity comes into play.
Practical implication: Make private API access the default and remove public exposure once a controlled alternative is working.
How identity-based kubectl access changes the trust boundary
Identity-based kubectl access separates endpoint reachability from cluster authorization. A user first proves identity through the organisation's IdP, then receives access to a specific resource, and only after that does Kubernetes RBAC decide what actions are allowed. That is a narrower trust boundary than VPN access, because the user does not join the broader network just to manage a cluster. See the IAM and IGA Basics.
Practical implication: Bind kubectl access to IdP groups and keep cluster permissions separate from transport access.
Why network policy still matters after external access is locked down
External access controls do not stop movement between pods once an attacker or malicious insider is already inside the cluster. Kubernetes NetworkPolicy works at the pod-to-pod layer, so it prevents a compromise in one namespace from turning into unrestricted cluster-wide traversal. Without it, the access boundary ends at the API server and the internal network remains open to sideways movement.
Practical implication: Enforce default-deny policies in each namespace and then allow only the traffic each workload actually needs.
Threat narrative
Attacker objective: The objective is to turn one valid administrative foothold into broader cluster or network access that supports lateral movement and operational disruption.
- Entry occurs through an exposed Kubernetes API server, a VPN path, or a bastion workflow that grants wider network access than the task requires.
- Credential use is then authenticated through OIDC or another identity path, but the real weakness is that endpoint reach was already broad enough to be useful.
- Escalation follows when an authenticated user or compromised laptop can reach more of the VPC or cluster than the intended admin workflow.
- Impact is cluster abuse, lateral movement or control-plane misuse that is harder to contain because access was granted at the network layer instead of the resource layer.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Network-based kubectl access is a governance failure, not just an engineering shortcut. When teams use VPNs, bastions or IP allowlists to solve cluster administration, they enlarge the trust boundary far beyond the API server. The right model is endpoint-specific access tied to identity, then RBAC for action scope. Practitioners should treat every extra network path to the control plane as avoidable blast-radius expansion.
The decisive control is separating reachability from authorization. A user reaching the API server does not mean that user should inherit broad network presence, and a network path does not prove entitlement to act. That distinction matters in Kubernetes because IdP groups, cluster RBAC and pod isolation each answer a different governance question. Teams should map those questions to separate controls instead of collapsing them into one access mechanism.
Private cluster design should be the default for admin workflows that do not require public reach. Public endpoints create unnecessary exposure even when authentication is strong, because the service remains visible and testable from the internet. In an identity-sensitive programme, that visibility is an avoidable control gap. Security architects should prefer private endpoints, resource-based access and per-session auditability.
CNI-level isolation is the missing internal boundary in many clusters. Once a pod is compromised, the control problem shifts from who can log in to what that workload can reach laterally. NetworkPolicy gives the cluster an internal segmentation layer that external access tools cannot replace. Practitioners should recognise this as a pod isolation problem, not a remote access problem.
Named concept: control-plane reachability inflation. This is the tendency to grant broad network access when the real need is a narrow administrative action on one endpoint. It matters because the extra reach often survives longer than the task and expands the attack surface for every user who touches the cluster. Security teams should measure kubectl access by resource scope, not by whether the user can get onto the network.
What this signals
Control-plane reachability inflation: security teams should stop treating cluster administration as a network access problem and start measuring it as a resource-scope problem. Once that framing changes, the control set becomes clearer: endpoint reach, RBAC and pod isolation each need their own boundary.
The operational signal to watch is whether a cluster can still be administered without placing users onto the broader VPC or a standing VPN. If the answer is no, the environment is probably over-granting reachability and under-segmenting internal traffic.
For practitioners
- Define kubectl access as resource-based access Register the API server as a specific resource and grant reachability to IdP-backed groups only for that endpoint, not for the whole VPC.
- Separate transport access from Kubernetes authorization Use the identity provider to control who can reach the API server, then use RBAC to limit what that identity can do inside the cluster.
- Disable the public API endpoint after validation Move the cluster to private-only access once the identity-based path works end to end, then verify kubectl still functions from the controlled route.
- Enforce default-deny pod traffic Apply NetworkPolicy in each namespace and open only the service-to-service paths the workload actually needs.
- Audit session logs for attributable cluster access Correlate user-to-resource logs with Kubernetes audit records so every kubectl session is tied to a specific user and time window.
Key takeaways
- Kubernetes access becomes safer when the API server is treated as a specific resource instead of a network perimeter.
- VPNs, bastions and public endpoints all widen the trust boundary beyond what cluster administration actually needs.
- Private reachability, RBAC and pod isolation work together because each one governs a different stage of access.
Related NHI Mgmt Group resources: IAM and IGA Basics · Secure API Design Guide · Joiner-Mover-Leaver (JML) Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Kubernetes API reachability and group-based access are an entitlement problem. |
| Recommendation — Apply PR.AA-05 to separate endpoint reachability from cluster permissions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Engineers access the cluster through federated external identities rather than local accounts. |
| Recommendation — Use IA-9 to bind cluster access to authenticated external identities and federated trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Group assignment, offboarding and access removal govern who can administer the cluster. |
| Recommendation — Use CIS-5 to keep kubectl access aligned to active accounts and current group membership. | ||
| NIST Zero Trust (SP 800-207) | 4.1 — Access Enforcement Point | The access path is moved to a controlled enforcement point before cluster access is granted. |
| Recommendation — Place the Kubernetes API behind an enforcement point that checks identity before reachability. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The access pattern is about limiting credential-enabled reach and preventing sideways movement inside the cluster. |
| Recommendation — Map cluster exposure to credential access and lateral movement, then reduce both with segmented access. | ||
Key terms
- Kubernetes Api Server: The Kubernetes API server is the central control point for a Kubernetes cluster. It receives requests from users, controllers, and other cluster components, then validates and stores desired state in the cluster datastore. It also enforces authentication, authorization, admission controls, and serves the canonical interface for managing workloads and resources.
- Private Cluster: A private cluster is a Kubernetes cluster whose control plane endpoint is not exposed to the public internet. Access is usually limited to private networks, VPNs, peered networks or a bastion path, which reduces direct attack surface on the API server and its administrative interfaces.
- Kubernetes RBAC: Kubernetes RBAC is the permission system that decides what users, groups, and service accounts can do inside a cluster. It uses roles and cluster roles, then binds them to subjects so access is limited to specific resources, verbs, and namespaces, reducing unnecessary control over workloads and infrastructure.
- Network Policy: A Kubernetes Network Policy is a rule that controls which pods can communicate with each other and with external endpoints. It is a policy object, not a complete security boundary, and its effectiveness depends on accurate labels, current topology, and continuous maintenance as the cluster changes.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps identity and security practitioners connect access design to the broader controls that govern privileged and non-human access.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org