Cross-Cluster Authentication

Cluster connections must be authenticated and authorized. For the special case of a cluster that targets itself, a Kubernetes service account and role-based access control (RBAC) work just fine. For the general case, considering the connection between two distinct source and target clusters:

  1. the Admiralty agent in the source cluster needs a kubeconfig to find the target cluster and mutually authenticate their connection;
  2. the kubeconfig must be saved in a Kubernetes secret to be mounted by Admiralty agent pods;
  3. the kubeconfig's client certificate or token must be trusted;
  4. the kubeconfig's identity (claimed by its certificate or token) must be authorized to perform the Admiralty agent's requests.

(1) and (2) are source cluster concerns, while (3) and (4) are target cluster concerns.

(1) and (2) use a standard kubeconfig as their interface, so:

  • you can use any of the methods described below to generate kubeconfigs, including Admiralty's cluster identity federation, and
  • you can use kubeconfigs generated by Admiralty's cluster identity federation for third-party (or custom) multi-cluster controllers, e.g., Linkerd, Argo CD, or even kubefed.
Security Notice

Kubeconfigs generated by Admiralty's cluster identity federation are more secure than those generated using Kubernetes service account tokens from target clusters, which is typically and unfortunately what other projects use. Those tokens never expire and aren't automatically rotated, making them as weak as passwords. Also, they are handled by the operator during setup, who must be careful not to leave traces.

In this document, we'll focus on (1) and (3), the different ways to generate kubeconfigs and ensure they're trusted.

Looking Ahead

Details about (2) and (4) can be found in the Operator Guide. In a nutshell:

  • The Admiralty agent watches Targets and ClusterTargets (custom resources introduced by Admiralty) to know which kubeconfig secrets to mount for which target clusters, and whether to use them for features like multi-cluster scheduling at the namespace or cluster level, respectively.
  • Authorization uses Kubernetes RBAC and optional higher-level APIs (Sources and ClusterSources) to simplify configuration.

Cluster Identity Federation

Cluster identity federation is available in Admiralty Cloud and Admiralty Enterprise.

Under Construction

We're working on documenting how this feature works. For now, please check out the Operator Guide on how to use it.

Using Kubernetes Service Account Tokens From Target Clusters

Under Construction

While we work on this section, please refer to the Open Source tab of the Cross-Cluster Authentication section in the quick start guide.

Other Solutions

  • cloud service accounts, also known as roles or service principals
  • Kubernetes service account issuer discovery
  • custom webhooks and proxies, potentially using SPIFFE/SPIRE, if access to Kubernetes API server flags
Edit this page