Managing Kubernetes across several clouds means keeping three things identical everywhere: who can reach each cluster, which workloads may run, and what gets logged. The clusters will differ in networking and storage. Your access rules, admission policy and audit trail should not.
Why does multicloud make Kubernetes harder to secure?
One cluster has one API server, one set of roles and one place to look. Three clusters on three providers have three login paths, three sets of default settings and, within a year, three slightly different versions of every policy.
Kubernetes itself assumes the person who runs kubectl may hold access to several clusters. Its documentation on configuring access to multiple clusters explains that clusters, users and contexts live in kubeconfig files, and that you switch with the kubectl config use-context command. It also carries a warning worth reading twice: only use kubeconfig files from trusted sources, because a crafted file can lead to malicious code execution or file exposure.
That one warning shows the shape of the problem. The tools that make multicloud easy for an engineer, a laptop with a dozen contexts, are also a pile of credentials.
What should be the same on every cluster?
Identity and access. Use short-lived credentials from your identity provider rather than long-lived tokens in a file. The Kubernetes RBAC good practices page recommends least privilege, minimizing the distribution of privileged tokens, and periodic review of roles. It also lists risky permissions to watch for, such as listing secrets, creating workloads, and the escalate, bind and impersonate verbs, because each can be turned into broader access.
Workload rules. Pod Security Standards and Pod Security Admission give a shared baseline for what a pod may ask for, such as privileged mode or host networking. Apply the same level by namespace on every cluster.
Tenant boundaries. If teams or customers share a cluster, the Kubernetes multi-tenancy documentation describes isolation in both the control plane (namespaces, access controls, quotas) and the data plane (network, storage, node isolation). It notes that data planes usually have a larger attack surface, so the strongest separation needs extra work there.
Audit and logs. Send audit logs from every cluster to one place that cluster admins cannot edit.
How do teams usually drift?
A constructed example: a company runs production on cloud A and a recently acquired product on cloud B. Cloud A has a rule that blocks privileged pods. Cloud B was set up by another team and never got it. A contractor with edit rights on cloud B deploys a debugging pod with host access to a node. Nothing in cloud A's policy would have caught it, and no dashboard compares the two.
The usual causes:
- Policies copied by hand into each cluster instead of stored in one repository.
- Different Kubernetes versions with different default behavior.
- Break-glass admin accounts created per cloud, never rotated.
- Cluster add-ons installed with cluster-wide permissions and never reviewed.
How to check or apply this
- Make a table: cluster, cloud, version, owner, how people log in, where audit logs go. Empty cells are your first findings.
- Store admission policies and RBAC roles in one Git repository and apply them to every cluster from there, so differences show up as diffs.
- Remove long-lived kubeconfig tokens from laptops. Use short-lived credentials from your identity provider.
- Run a role review per cluster. Search for subjects that can list secrets, create pods, or use escalate, bind or impersonate.
- Apply one Pod Security level per namespace type, with the same exceptions list everywhere.
- Forward audit logs from all clusters to a separate store and set one retention period.
- Test one change. Add a deliberately non-compliant pod to each cluster in a test namespace and confirm all of them reject it.
Quick check
Do I need a single tool to manage all clusters?
Not necessarily. What matters is that policy and access are defined once and applied everywhere, with a way to see differences. A Git repository and a pipeline can do that.
Is it safe to keep many contexts in one kubeconfig?
It is common, but the file holds credentials for every cluster in it. Keep tokens short-lived, protect the file like a password, and never load kubeconfig files from sources you do not trust.
Sources
- Kubernetes docs: Configure Access to Multiple Clusters
- Kubernetes docs: Role Based Access Control Good Practices
- Kubernetes docs: Multi-tenancy
- Kubernetes docs: Security overview
Last reviewed: 18 October 2026.
