Breaking Down Silos: Seamless Cross-Cloud Authentication with k8xauth

Introduction

In the rapidly evolving landscape of cloud computing, we see businesses increasingly adopting a multi-cloud strategy to leverage the strengths of different cloud providers. However, one of the challenges that organisations face is the complexity of managing credentials and authentication across diverse cloud environments.

In this series of articles we will explore our solution for cross-cloud Kubernetes authentication: the k8xauth Kubernetes Exec Credentials Plugin, which facilitates authentication between Kubernetes clusters running on different cloud providers without relying on long-term credentials.

The Challenge of Multi-Cloud Authentication

As organisations embrace a multi-cloud approach, we see them often finding themselves managing a myriad of access credentials, API keys, and secrets for different cloud providers. This not only introduces security risks but also creates operational challenges and overhead, making it difficult to navigate and orchestrate workloads across diverse cloud environments.

We at Trhyo wanted to address one of the pain points often presented to us, authenticating from one Kubernetes cluster to another Kubernetes cluster running on a different cloud provider infrastructure. Use cases presented to us ranged from launching machine learning jobs on GKE from a supervisor running on EKS to orchestrating application deployments using single ArgoCD instance across all three major cloud providers.

Enter k8xauth

K8xauth is a Kubernetes Exec Credentials Plugin that allows authentication between Kubernetes cluster runnin on different cloud providers.

• It uses source identity which is the identity the programs runs as. Typically this is provided via GKE, AKS Workload identity or AWS IRSA, although other authentication sources can be used (such as AWS EC2 IAM role or GCE compute roles).

• It uses credential exchange (federation) mechanisms available in supported cloud providers to provision IAM credentials for the destination cloud provider IAM and returns it a execCredential to be used by Kubernetes client libraries or applications. K8sAuth is an open source project which we are commited to maintaining and extending in the future. It allows for easy integration of both additional identity sources and destination cloud providers.

Before diving into usage and particular use cases, in this part of the series we will look at principles of cross cloud authentication and how we can leverage those to implement keyless authentication between different cloud providers.

Cross cloud authentication

Identity federation

Most major cloud providers provide support for federating their identities with specified external identities. An identity federation enables secure access to cloud providers APIs and resources using credentials issued by identity providers other than cloud provider's own. In the case of the cloud providers currently supported by k8xauth, those are:

• AWS supports IAM role federation using external identity providers and IAM roles trust policies

• Azure supports federated credentials for managed identities or Azure Entra apps

• Google Cloud supports federated credentials via Workload Identity Federation For the remainder of this article, we will focus on OIDC federation methods, since those are used by the k8xauth to provision Kubernetes credentials. Let's dive in:

General cloud provider login flow

A sequence chart below visualizes general authentication that uses credentials provided by cloud provider X (or any kind of OIDC provider) to authenticate with a different cloud provider Y.

K8xauth uses this model of authentication/token exchange. A real world example scenario would be for k8xauth running on AWS EKS cluster, and using IRSA provided temporary IAM credentials exchanging these credentials for Google Cloud GKE credentials via Google Cloud workload identity federation.

One clear advantage of this approach it that no long term credentials are used in any steps of the process. Only temporary credentials are used in both source and destination cloud providers. This brings following advantages when using k8xauth:

• Significant reduction of risk of credentials exposure: Short term credentials are valid only for a short period of time (typically 1 hour) after which new credentials are generated.

• Improved cloud systems operability: No need to store any kind of sensitive data resulting in reduced risk and complexitity of management. Easy to replicate Infrastructure-as-a-code (IaC) system can be used to manage systems access and permissions without the need of including secret stores into it's configuration.

• Reduced maintenance costs: No need to rotate long term credentials or maintaining secrets infrastructure.

The road ahead

k8xauth currently supports Azure AKS, AWS EKS and Google Cloud GKE, but the journey doesn’t stop here. Going further, support for authenticating on-premise clusters with cloud provider’s managed Kubernetes platforms is planned, as well as support for additional cloud providers.

k8xauth is open source and free to use. We at Trhyo want to help to make the internet safer and more enjoyable place to be and we see this a small contribution in a great effort undertaken by many.

If you have a use case for k8xauth, we encouraged you to head over to the documentation and give it a try. (and please let us know your thoughts :-)

Please reach out to us with your specific needs and we will be able to help you out!

In the following parts of this series, we will take more detailed look into k8xauth internals and explore practical ways of taking advantage of it's capabilities. Stay tuned!