How to manage Kubernetes access across multiple clusters and cloud providers
Multi-cluster Kubernetes fails at the credential and audit layer, not the network layer. The fix is propagating IdP identity directly into native RBAC so there are no separate cluster credentials to manage, lose, or audit after the fact.
Multi-cluster is the default now. The CNCF's January 2026 annual survey put Kubernetes production use at 82% of container users, and in September 2026 CNCF graduated Karmada, a project whose entire reason to exist is scheduling workloads across clusters and clouds. If you're running one production cluster today, you'll probably be running several in eighteen months, across at least two providers.
The networking story for this is largely solved. Service meshes, CNI plugins, and tools like Karmada handle east-west traffic and workload placement. The part nobody has solved cleanly is who gets to run kubectl exec against a pod in prod-eu-west-1 at 2 am, how they prove who they are, and where the record of that session actually lives.
That's a credential and audit problem, and most platform teams are losing ground on it.
The real failure mode isn't network, it's identity sprawl
Walk into any mid-sized platform team and ask to see the kubeconfigs. You'll find:
Static admin credentials sitting in
~/.kube/configon engineer laptops, often with contexts for clusters nobody has touched in monthsService account tokens checked into CI runner secrets, with no clear owner and no rotation story
A different auth mechanism for every provider: EKS uses IAM with
aws-iam-authenticator, GKE uses Google OAuth tokens, AKS uses Entra ID, self-managed clusters use whatever the team wired upRBAC definitions that started identical across clusters and have drifted for a year because changes were made in whichever cluster was on fire that week
None of this is a networking problem. The clusters can be perfectly firewalled off, the control planes private, the pod networks isolated. The access model is still broken because the identity of the person at the keyboard has been laundered through two or three credential handoffs before it reaches the API server, and the audit trail is scattered across cloud providers, CI logs, and whatever shell history survived.
The question "who ran that kubectl delete" should take thirty seconds to answer. In most multi-cluster shops, it takes a day.
Why multi-cluster broke the old patterns
Single cluster was manageable. One kubeconfig, one RBAC file, one audit log to ship to your SIEM. Multi-cluster multiplied every one of those by N, and multi-cloud multiplied it again by the number of providers, each with its own auth model.
Here's what happens to each common access pattern as cluster count grows:
Pattern 1: Bastion hosts and jump boxes
Platform teams put a bastion in each VPC, SSH to it, run kubectl from there. The cluster API is private, the bastion is the only ingress, and in theory everything is contained.
In practice:
Every bastion needs its own user accounts, SSH keys, and patching cycle
Kubeconfigs end up on the bastion, which means the bastion itself holds cluster admin credentials
Session recording is DIY:
script,auditd, or nothingA compromised bastion is a compromised cluster, and bastions are high-value targets precisely because they aggregate access
This scales terribly. Ten clusters means ten bastions, or one mega-bastion that holds credentials for everything, which is worse.
Pattern 2: Cloud-native IAM per provider
Lean on each cloud's IAM: EKS with IAM roles, GKE with Google groups, AKS with Entra ID. Users authenticate with their cloud identity, assume a role, and get a short-lived token.
This works reasonably well inside one provider. Across providers, you now maintain:
Three distinct identity-to-RBAC mappings
Three different auth plugins in every kubeconfig
Three different audit log destinations (CloudTrail, Cloud Audit Logs, Azure Activity Log)
Zero cross-provider policy enforcement
And none of this applies to your self-managed clusters, your edge clusters, or the K3s instances somebody spun up for a POC.
Pattern 3: VPN plus shared kubeconfigs
Connect everyone to a VPN that reaches the private cluster endpoints, distribute kubeconfigs through a secret manager, done. This is the most common pattern we see at startups moving from one cluster to several.
The failure modes:
The VPN gives network-level access to everything on the other side, so a compromised laptop can probe any cluster endpoint it can resolve
Kubeconfigs with embedded tokens or long-lived credentials end up cached locally and in CI
Revoking a departing engineer means rotating credentials in N clusters, hoping you got them all
Session audit lives in the cluster's own audit log, if it's turned on, with no concept of "this kubectl session came from Priya on her laptop"
The VPN secures the pipe. It does nothing for the identity flowing through it.
What a working model looks like
The pattern that actually scales has three properties, and they're all about identity and audit rather than networking:
Clusters stay off the public internet. No public API server endpoints, no inbound firewall rules. This is table stakes, and solved by any decent private connectivity layer.
IdP identity flows directly into Kubernetes RBAC. No separate cluster credentials. The user authenticates once to your IdP (Okta, Entra, Google), and that identity is what the API server sees. RBAC bindings reference IdP groups, not local service accounts.
Every session is recorded centrally, to infrastructure the team controls. Not CloudTrail. Not scattered across providers. One place to answer "who did what, where, when."
If you hit all three, the credential sprawl problem evaporates. There's nothing to steal off a laptop because there's no long-lived kubeconfig token to steal. Offboarding is a single IdP action. Audit queries work across every cluster the same way.
How Twingate Privileged Access for Kubernetes implements this
Twingate Privileged Access for Kubernetes access works through three pieces that map directly to the properties above:
Layer 7 Gateway. Rather than terminating a VPN at a network boundary, the Twingate Gateway inspects authenticated kubectl traffic at the application layer. The user's IdP identity is attached to every API call, and the gateway can enforce per-request policy, including session recording.
Operator. Deployed inside the cluster, the Twingate Kubernetes Operator connects outbound to Twingate (no inbound firewall rules, no public API endpoint). It maps authenticated users to Kubernetes identities, so your RBAC bindings reference IdP groups and the API server sees the real user, not a shared service account.
Kubeconfig sync. Instead of distributing static kubeconfigs, Twingate generates them dynamically for authenticated users. There's no long-lived credential sitting on a laptop. Access is granted at session time and revoked when the IdP session ends or policy changes.
The session recording lands in your own infrastructure, not a third-party SaaS log store you can't query. When someone asks who ran a destructive command in a cluster, the answer is a single query against your audit pipeline, with the IdP identity, the cluster, the namespace, the command, and the full session transcript.
What this changes operationally
A few things that stop being painful:
Offboarding. Deactivate the user in your IdP. Done. No kubeconfig rotation across clusters, no scrambling to figure out which CI runners had their key.
New cluster onboarding. Deploy the Operator, map your existing IdP groups to RBAC roles. The access model is identical to every other cluster you run, regardless of cloud provider.
Incident response. When something breaks and you need to know who touched what, the audit trail is in one place with real identities attached. Not three cloud audit logs plus bastion shell history plus "ask the team on Slack."
CI access. Service accounts for CI can be short-lived and scoped per pipeline, pulled from the same identity layer as human users, with the same audit trail.
What doesn't change: your RBAC. Twingate propagates identity into native Kubernetes RBAC. You keep whatever role structure you've built, whatever Helm charts manage it, whatever GitOps workflow you use. The identity flowing in is just real now.
The takeaway
If you're running Kubernetes across more than two clusters, the next outage report you write that includes the phrase "we're still trying to determine who ran the command" is a credential and audit problem, not a network one. Buying a better VPN won't fix it. Standing up another bastion won't fix it. Writing a Terraform module to sync RBAC across clusters helps, but it doesn't address the fact that the identities being bound to those roles are still fragmented across providers.
The clusters being private is necessary. It isn't sufficient. The identity model has to collapse down to one source of truth, and the audit trail has to live somewhere you can actually query.
Closing
For more details on how Twingate handles Kubernetes access, including the Layer 7 Gateway, Operator deployment, and kubeconfig sync, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
How to manage Kubernetes access across multiple clusters and cloud providers
Multi-cluster Kubernetes fails at the credential and audit layer, not the network layer. The fix is propagating IdP identity directly into native RBAC so there are no separate cluster credentials to manage, lose, or audit after the fact.
Multi-cluster is the default now. The CNCF's January 2026 annual survey put Kubernetes production use at 82% of container users, and in September 2026 CNCF graduated Karmada, a project whose entire reason to exist is scheduling workloads across clusters and clouds. If you're running one production cluster today, you'll probably be running several in eighteen months, across at least two providers.
The networking story for this is largely solved. Service meshes, CNI plugins, and tools like Karmada handle east-west traffic and workload placement. The part nobody has solved cleanly is who gets to run kubectl exec against a pod in prod-eu-west-1 at 2 am, how they prove who they are, and where the record of that session actually lives.
That's a credential and audit problem, and most platform teams are losing ground on it.
The real failure mode isn't network, it's identity sprawl
Walk into any mid-sized platform team and ask to see the kubeconfigs. You'll find:
Static admin credentials sitting in
~/.kube/configon engineer laptops, often with contexts for clusters nobody has touched in monthsService account tokens checked into CI runner secrets, with no clear owner and no rotation story
A different auth mechanism for every provider: EKS uses IAM with
aws-iam-authenticator, GKE uses Google OAuth tokens, AKS uses Entra ID, self-managed clusters use whatever the team wired upRBAC definitions that started identical across clusters and have drifted for a year because changes were made in whichever cluster was on fire that week
None of this is a networking problem. The clusters can be perfectly firewalled off, the control planes private, the pod networks isolated. The access model is still broken because the identity of the person at the keyboard has been laundered through two or three credential handoffs before it reaches the API server, and the audit trail is scattered across cloud providers, CI logs, and whatever shell history survived.
The question "who ran that kubectl delete" should take thirty seconds to answer. In most multi-cluster shops, it takes a day.
Why multi-cluster broke the old patterns
Single cluster was manageable. One kubeconfig, one RBAC file, one audit log to ship to your SIEM. Multi-cluster multiplied every one of those by N, and multi-cloud multiplied it again by the number of providers, each with its own auth model.
Here's what happens to each common access pattern as cluster count grows:
Pattern 1: Bastion hosts and jump boxes
Platform teams put a bastion in each VPC, SSH to it, run kubectl from there. The cluster API is private, the bastion is the only ingress, and in theory everything is contained.
In practice:
Every bastion needs its own user accounts, SSH keys, and patching cycle
Kubeconfigs end up on the bastion, which means the bastion itself holds cluster admin credentials
Session recording is DIY:
script,auditd, or nothingA compromised bastion is a compromised cluster, and bastions are high-value targets precisely because they aggregate access
This scales terribly. Ten clusters means ten bastions, or one mega-bastion that holds credentials for everything, which is worse.
Pattern 2: Cloud-native IAM per provider
Lean on each cloud's IAM: EKS with IAM roles, GKE with Google groups, AKS with Entra ID. Users authenticate with their cloud identity, assume a role, and get a short-lived token.
This works reasonably well inside one provider. Across providers, you now maintain:
Three distinct identity-to-RBAC mappings
Three different auth plugins in every kubeconfig
Three different audit log destinations (CloudTrail, Cloud Audit Logs, Azure Activity Log)
Zero cross-provider policy enforcement
And none of this applies to your self-managed clusters, your edge clusters, or the K3s instances somebody spun up for a POC.
Pattern 3: VPN plus shared kubeconfigs
Connect everyone to a VPN that reaches the private cluster endpoints, distribute kubeconfigs through a secret manager, done. This is the most common pattern we see at startups moving from one cluster to several.
The failure modes:
The VPN gives network-level access to everything on the other side, so a compromised laptop can probe any cluster endpoint it can resolve
Kubeconfigs with embedded tokens or long-lived credentials end up cached locally and in CI
Revoking a departing engineer means rotating credentials in N clusters, hoping you got them all
Session audit lives in the cluster's own audit log, if it's turned on, with no concept of "this kubectl session came from Priya on her laptop"
The VPN secures the pipe. It does nothing for the identity flowing through it.
What a working model looks like
The pattern that actually scales has three properties, and they're all about identity and audit rather than networking:
Clusters stay off the public internet. No public API server endpoints, no inbound firewall rules. This is table stakes, and solved by any decent private connectivity layer.
IdP identity flows directly into Kubernetes RBAC. No separate cluster credentials. The user authenticates once to your IdP (Okta, Entra, Google), and that identity is what the API server sees. RBAC bindings reference IdP groups, not local service accounts.
Every session is recorded centrally, to infrastructure the team controls. Not CloudTrail. Not scattered across providers. One place to answer "who did what, where, when."
If you hit all three, the credential sprawl problem evaporates. There's nothing to steal off a laptop because there's no long-lived kubeconfig token to steal. Offboarding is a single IdP action. Audit queries work across every cluster the same way.
How Twingate Privileged Access for Kubernetes implements this
Twingate Privileged Access for Kubernetes access works through three pieces that map directly to the properties above:
Layer 7 Gateway. Rather than terminating a VPN at a network boundary, the Twingate Gateway inspects authenticated kubectl traffic at the application layer. The user's IdP identity is attached to every API call, and the gateway can enforce per-request policy, including session recording.
Operator. Deployed inside the cluster, the Twingate Kubernetes Operator connects outbound to Twingate (no inbound firewall rules, no public API endpoint). It maps authenticated users to Kubernetes identities, so your RBAC bindings reference IdP groups and the API server sees the real user, not a shared service account.
Kubeconfig sync. Instead of distributing static kubeconfigs, Twingate generates them dynamically for authenticated users. There's no long-lived credential sitting on a laptop. Access is granted at session time and revoked when the IdP session ends or policy changes.
The session recording lands in your own infrastructure, not a third-party SaaS log store you can't query. When someone asks who ran a destructive command in a cluster, the answer is a single query against your audit pipeline, with the IdP identity, the cluster, the namespace, the command, and the full session transcript.
What this changes operationally
A few things that stop being painful:
Offboarding. Deactivate the user in your IdP. Done. No kubeconfig rotation across clusters, no scrambling to figure out which CI runners had their key.
New cluster onboarding. Deploy the Operator, map your existing IdP groups to RBAC roles. The access model is identical to every other cluster you run, regardless of cloud provider.
Incident response. When something breaks and you need to know who touched what, the audit trail is in one place with real identities attached. Not three cloud audit logs plus bastion shell history plus "ask the team on Slack."
CI access. Service accounts for CI can be short-lived and scoped per pipeline, pulled from the same identity layer as human users, with the same audit trail.
What doesn't change: your RBAC. Twingate propagates identity into native Kubernetes RBAC. You keep whatever role structure you've built, whatever Helm charts manage it, whatever GitOps workflow you use. The identity flowing in is just real now.
The takeaway
If you're running Kubernetes across more than two clusters, the next outage report you write that includes the phrase "we're still trying to determine who ran the command" is a credential and audit problem, not a network one. Buying a better VPN won't fix it. Standing up another bastion won't fix it. Writing a Terraform module to sync RBAC across clusters helps, but it doesn't address the fact that the identities being bound to those roles are still fragmented across providers.
The clusters being private is necessary. It isn't sufficient. The identity model has to collapse down to one source of truth, and the audit trail has to live somewhere you can actually query.
Closing
For more details on how Twingate handles Kubernetes access, including the Layer 7 Gateway, Operator deployment, and kubeconfig sync, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
How to manage Kubernetes access across multiple clusters and cloud providers
Multi-cluster Kubernetes fails at the credential and audit layer, not the network layer. The fix is propagating IdP identity directly into native RBAC so there are no separate cluster credentials to manage, lose, or audit after the fact.
Multi-cluster is the default now. The CNCF's January 2026 annual survey put Kubernetes production use at 82% of container users, and in September 2026 CNCF graduated Karmada, a project whose entire reason to exist is scheduling workloads across clusters and clouds. If you're running one production cluster today, you'll probably be running several in eighteen months, across at least two providers.
The networking story for this is largely solved. Service meshes, CNI plugins, and tools like Karmada handle east-west traffic and workload placement. The part nobody has solved cleanly is who gets to run kubectl exec against a pod in prod-eu-west-1 at 2 am, how they prove who they are, and where the record of that session actually lives.
That's a credential and audit problem, and most platform teams are losing ground on it.
The real failure mode isn't network, it's identity sprawl
Walk into any mid-sized platform team and ask to see the kubeconfigs. You'll find:
Static admin credentials sitting in
~/.kube/configon engineer laptops, often with contexts for clusters nobody has touched in monthsService account tokens checked into CI runner secrets, with no clear owner and no rotation story
A different auth mechanism for every provider: EKS uses IAM with
aws-iam-authenticator, GKE uses Google OAuth tokens, AKS uses Entra ID, self-managed clusters use whatever the team wired upRBAC definitions that started identical across clusters and have drifted for a year because changes were made in whichever cluster was on fire that week
None of this is a networking problem. The clusters can be perfectly firewalled off, the control planes private, the pod networks isolated. The access model is still broken because the identity of the person at the keyboard has been laundered through two or three credential handoffs before it reaches the API server, and the audit trail is scattered across cloud providers, CI logs, and whatever shell history survived.
The question "who ran that kubectl delete" should take thirty seconds to answer. In most multi-cluster shops, it takes a day.
Why multi-cluster broke the old patterns
Single cluster was manageable. One kubeconfig, one RBAC file, one audit log to ship to your SIEM. Multi-cluster multiplied every one of those by N, and multi-cloud multiplied it again by the number of providers, each with its own auth model.
Here's what happens to each common access pattern as cluster count grows:
Pattern 1: Bastion hosts and jump boxes
Platform teams put a bastion in each VPC, SSH to it, run kubectl from there. The cluster API is private, the bastion is the only ingress, and in theory everything is contained.
In practice:
Every bastion needs its own user accounts, SSH keys, and patching cycle
Kubeconfigs end up on the bastion, which means the bastion itself holds cluster admin credentials
Session recording is DIY:
script,auditd, or nothingA compromised bastion is a compromised cluster, and bastions are high-value targets precisely because they aggregate access
This scales terribly. Ten clusters means ten bastions, or one mega-bastion that holds credentials for everything, which is worse.
Pattern 2: Cloud-native IAM per provider
Lean on each cloud's IAM: EKS with IAM roles, GKE with Google groups, AKS with Entra ID. Users authenticate with their cloud identity, assume a role, and get a short-lived token.
This works reasonably well inside one provider. Across providers, you now maintain:
Three distinct identity-to-RBAC mappings
Three different auth plugins in every kubeconfig
Three different audit log destinations (CloudTrail, Cloud Audit Logs, Azure Activity Log)
Zero cross-provider policy enforcement
And none of this applies to your self-managed clusters, your edge clusters, or the K3s instances somebody spun up for a POC.
Pattern 3: VPN plus shared kubeconfigs
Connect everyone to a VPN that reaches the private cluster endpoints, distribute kubeconfigs through a secret manager, done. This is the most common pattern we see at startups moving from one cluster to several.
The failure modes:
The VPN gives network-level access to everything on the other side, so a compromised laptop can probe any cluster endpoint it can resolve
Kubeconfigs with embedded tokens or long-lived credentials end up cached locally and in CI
Revoking a departing engineer means rotating credentials in N clusters, hoping you got them all
Session audit lives in the cluster's own audit log, if it's turned on, with no concept of "this kubectl session came from Priya on her laptop"
The VPN secures the pipe. It does nothing for the identity flowing through it.
What a working model looks like
The pattern that actually scales has three properties, and they're all about identity and audit rather than networking:
Clusters stay off the public internet. No public API server endpoints, no inbound firewall rules. This is table stakes, and solved by any decent private connectivity layer.
IdP identity flows directly into Kubernetes RBAC. No separate cluster credentials. The user authenticates once to your IdP (Okta, Entra, Google), and that identity is what the API server sees. RBAC bindings reference IdP groups, not local service accounts.
Every session is recorded centrally, to infrastructure the team controls. Not CloudTrail. Not scattered across providers. One place to answer "who did what, where, when."
If you hit all three, the credential sprawl problem evaporates. There's nothing to steal off a laptop because there's no long-lived kubeconfig token to steal. Offboarding is a single IdP action. Audit queries work across every cluster the same way.
How Twingate Privileged Access for Kubernetes implements this
Twingate Privileged Access for Kubernetes access works through three pieces that map directly to the properties above:
Layer 7 Gateway. Rather than terminating a VPN at a network boundary, the Twingate Gateway inspects authenticated kubectl traffic at the application layer. The user's IdP identity is attached to every API call, and the gateway can enforce per-request policy, including session recording.
Operator. Deployed inside the cluster, the Twingate Kubernetes Operator connects outbound to Twingate (no inbound firewall rules, no public API endpoint). It maps authenticated users to Kubernetes identities, so your RBAC bindings reference IdP groups and the API server sees the real user, not a shared service account.
Kubeconfig sync. Instead of distributing static kubeconfigs, Twingate generates them dynamically for authenticated users. There's no long-lived credential sitting on a laptop. Access is granted at session time and revoked when the IdP session ends or policy changes.
The session recording lands in your own infrastructure, not a third-party SaaS log store you can't query. When someone asks who ran a destructive command in a cluster, the answer is a single query against your audit pipeline, with the IdP identity, the cluster, the namespace, the command, and the full session transcript.
What this changes operationally
A few things that stop being painful:
Offboarding. Deactivate the user in your IdP. Done. No kubeconfig rotation across clusters, no scrambling to figure out which CI runners had their key.
New cluster onboarding. Deploy the Operator, map your existing IdP groups to RBAC roles. The access model is identical to every other cluster you run, regardless of cloud provider.
Incident response. When something breaks and you need to know who touched what, the audit trail is in one place with real identities attached. Not three cloud audit logs plus bastion shell history plus "ask the team on Slack."
CI access. Service accounts for CI can be short-lived and scoped per pipeline, pulled from the same identity layer as human users, with the same audit trail.
What doesn't change: your RBAC. Twingate propagates identity into native Kubernetes RBAC. You keep whatever role structure you've built, whatever Helm charts manage it, whatever GitOps workflow you use. The identity flowing in is just real now.
The takeaway
If you're running Kubernetes across more than two clusters, the next outage report you write that includes the phrase "we're still trying to determine who ran the command" is a credential and audit problem, not a network one. Buying a better VPN won't fix it. Standing up another bastion won't fix it. Writing a Terraform module to sync RBAC across clusters helps, but it doesn't address the fact that the identities being bound to those roles are still fragmented across providers.
The clusters being private is necessary. It isn't sufficient. The identity model has to collapse down to one source of truth, and the audit trail has to live somewhere you can actually query.
Closing
For more details on how Twingate handles Kubernetes access, including the Layer 7 Gateway, Operator deployment, and kubeconfig sync, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions