Building Multi-Cloud
Workload Identity Federation

Modern cloud platforms rarely operate within a single cloud provider. The platform I worked on managed infrastructure across AWS, Google Cloud, and Microsoft Azure while providing a unified operational experience for internal engineering teams. Rather than exposing cloud-specific workflows, the platform abstracted infrastructure management behind Kubernetes-native APIs and automation.

Kubernetes served as much more than a container orchestration platform. It became the execution environment for controllers, workflow engines, infrastructure automation, networking services, and operational tooling responsible for provisioning and managing cloud resources across multiple providers.

Every controller running inside the cluster eventually needed to interact with one or more cloud provider APIs. Some provisioned infrastructure, others managed networking resources, synchronized DNS records, reconciled cloud resources, or continuously maintained the desired state of the platform.

As the platform expanded, one architectural challenge became increasingly important: how should Kubernetes workloads authenticate to cloud providers in a way that remained secure, scalable, and operationally simple across multiple clouds?

Authenticating applications to cloud providers is often treated as a deployment concern: generate credentials, store them securely, and inject them into workloads as secrets. While this approach is simple to bootstrap, it becomes increasingly difficult to manage as the number of workloads, cloud accounts, and operational environments grows.

Every new controller, operator, or automation service introduces another credential lifecycle to manage. Platform engineers must create credentials, distribute them securely, rotate them periodically, audit their usage, and eventually revoke them when they are no longer needed. Over time, credential management becomes a significant operational responsibility rather than a one-time setup task.

More importantly, static credentials weaken the identity model that Kubernetes already provides. Inside the cluster, every workload has a well-defined identity through its ServiceAccount. Outside the cluster, cloud providers see only an access key or service account credential, making it difficult to associate cloud activity with the originating Kubernetes workload.

The objective of this project was not simply to replace one authentication mechanism with another. It was to redesign how workloads establish trust with cloud providers while improving security, reducing operational complexity, and making identity a first-class architectural concern.

Before introducing workload identity federation, Kubernetes workloads authenticated to cloud providers using static credentials. Cloud identities were created outside Kubernetes, stored as Kubernetes Secrets, and mounted into Pods at runtime. Each workload received the credentials required to interact with cloud APIs.

This approach was straightforward to implement and worked well during the early stages of the platform. Controllers could provision infrastructure, update DNS records, manage networking resources, and interact with cloud services using familiar SDKs without requiring any special authentication flow.

Authentication followed a familiar pattern. Credentials were generated in the cloud provider, securely stored as Kubernetes Secrets, mounted into application Pods, and automatically discovered by the cloud SDK. From the application's perspective, cloud authentication was completely transparent.

As the platform expanded across multiple cloud providers and hundreds of workloads, however, this seemingly simple model became increasingly difficult to operate. Every workload introduced another credential that had to be created, distributed, rotated, audited, and eventually removed.

The original authentication model was practical and easy to adopt. Kubernetes Secrets provided a familiar mechanism for distributing cloud credentials, and workloads could authenticate using standard cloud SDKs without additional configuration.

As the platform matured, however, authentication became an operational challenge rather than an implementation detail. Each new controller, operator, or automation service introduced another credential lifecycle to manage. Platform engineers were responsible for provisioning credentials, distributing them securely, rotating them regularly, auditing their usage, and ensuring unused credentials were eventually removed.

The problem extended beyond operational overhead. Static credentials were disconnected from Kubernetes' native identity model. While Kubernetes understood exactly which ServiceAccount a workload was running as, cloud providers only observed an access key or service account credential. This made auditing, authorization, and least-privilege enforcement significantly more difficult.

Security was also affected. Long-lived credentials remained valid long after they had been issued, increasing the potential impact of accidental exposure or compromise. Even with regular rotation policies, managing credentials at scale introduced complexity that grew alongside the platform.

After evaluating the limitations of static credentials, it became clear that simply improving secret management would not solve the underlying problem. Automating credential rotation or introducing a more secure secret store would reduce operational burden, but workloads would still rely on credentials that existed independently of their Kubernetes identity.

The real challenge was not how to distribute credentials more efficiently, but how to eliminate the need for long-lived credentials altogether. Instead of asking "How should workloads obtain cloud credentials?", the question became "How should cloud providers trust Kubernetes workloads?"

This shift in perspective fundamentally changed the direction of the project. Rather than treating authentication as a credential management problem, it became an identity and trust problem. If Kubernetes already knew the identity of every workload, could that identity become the basis for authenticating with external cloud providers?

Answering this question required looking beyond traditional cloud credentials and understanding how Kubernetes identifies workloads internally. That exploration ultimately led to workload identity federation and a design centered around trust rather than secrets.

Once authentication was reframed as an identity problem, the next step was defining what a successful solution should achieve. Any replacement for static credentials needed to improve security without introducing additional operational complexity or forcing application teams to change how they built and deployed workloads.

The platform already operated across AWS, Google Cloud, and Microsoft Azure, each with its own identity model and authentication mechanisms. Rather than building cloud-specific workflows, the objective was to create a consistent authentication experience while allowing each cloud provider to continue enforcing its native authorization policies.

Equally important, the solution needed to integrate naturally with Kubernetes. Workloads already had identities through theirServiceAccount, so introducing another identity layer would only increase complexity. The authentication model should extend Kubernetes' existing identity system instead of replacing it.

Kubernetes was never designed around anonymous workloads. Every Pod runs with an identity represented by a ServiceAccount. While ServiceAccounts are commonly associated with Kubernetes RBAC, they also provide a cryptographic identity that workloads can use to prove who they are.

When a Pod starts, Kubernetes automatically mounts a ServiceAccount token into the container. This token is digitally signed by the Kubernetes API server and contains claims describing the workload, including its namespace, ServiceAccount, and intended audience. The token can be verified using the cluster's public signing keys, allowing other systems to trust identities issued by Kubernetes.

Inside the cluster, this identity enables Kubernetes to enforce Role-Based Access Control (RBAC). The API server evaluates the ServiceAccount associated with a request and determines whether the workload is permitted to perform the requested operation.

The important realization was that Kubernetes already had everything needed to uniquely identify workloads. Instead of creating separate cloud credentials for every application, we could extend this existing identity beyond the cluster boundary.

At this point, Kubernetes already appears to have everything needed for workload authentication. Every Pod has a unique identity through its ServiceAccount, and that identity is represented by a cryptographically signed token.

The problem is that this identity is only meaningful within the Kubernetes cluster. AWS, Google Cloud, and Azure have no inherent reason to trust identities issued by an arbitrary Kubernetes API server. From their perspective, the token could have been issued by any cluster unless there is a trusted mechanism for verifying both its authenticity and its issuer.

In other words, Kubernetes can confidently say,"This workload is running as the platform-controller ServiceAccount in the production namespace."The cloud provider's response is naturally,"How do I know I can trust you?"

Solving this challenge requires more than a signed token. It requires a standardized trust relationship that allows cloud providers to verify the token's signature, validate who issued it, and determine whether that issuer has been explicitly configured as a trusted identity provider.

Kubernetes can securely identify workloads within a cluster, but cloud providers operate outside that trust boundary. To allow external systems to verify workload identities, Kubernetes exposes its ServiceAccount tokens through the OpenID Connect (OIDC) standard.

OpenID Connect provides a standardized way for an identity provider to issue signed identity tokens. Instead of relying on proprietary authentication mechanisms, cloud providers can validate these tokens using the Kubernetes cluster's public signing keys and determine whether they trust the workload requesting access.

In this model, Kubernetes acts as the identity provider. When a workload requests access to a cloud service, it presents its signed ServiceAccount token. The cloud provider verifies the token's signature, confirms that it was issued by a trusted Kubernetes cluster, validates its claims, and then decides whether the workload is authorized to assume a cloud identity.

This approach separates authentication from authorization. Kubernetes is responsible for proving the identity of the workload, while AWS, Google Cloud, and Azure remain responsible for deciding what that workload is allowed to do.

OpenID Connect defines the trust relationship, but the actual identity is carried inside a JSON Web Token (JWT). Every ServiceAccount token issued by Kubernetes is a signed JWT containing claims that describe the workload's identity.

Unlike traditional access keys, a JWT is not a secret that grants permission by itself. Instead, it serves as a verifiable identity document. Cloud providers validate the token's signature, ensure it was issued by a trusted Kubernetes cluster, and inspect its claims before deciding whether to issue temporary cloud credentials.

Because the token is digitally signed by the Kubernetes API server, its contents cannot be modified without invalidating the signature. This allows cloud providers to trust the identity information without sharing any long-lived secrets with the workload.

A validated JWT is not used directly to access cloud APIs. Instead, it is exchanged for temporary credentials issued by the cloud provider. This exchange is the core of workload identity federation and eliminates the need for long-lived access keys or service account credentials inside Kubernetes.

When a workload presents its ServiceAccount token, the cloud provider verifies the token's signature, issuer, audience, and subject. If the workload satisfies the configured trust policy, the provider issues short-lived credentials associated with the appropriate cloud identity.

From that point onward, the application interacts with cloud services using native cloud credentials. AWS issues temporary IAM role credentials, Google Cloud issues access tokens for the target service account, and Azure issues tokens for the associated managed identity. Existing cloud SDKs continue to work without modification.

Because these credentials are temporary, they expire automatically after a limited duration. Workloads simply repeat the federation process when new credentials are required, removing the need for manual credential rotation and significantly reducing the impact of credential exposure.

The underlying authentication pattern is remarkably consistent across AWS, Google Cloud, and Microsoft Azure. Each provider allows an external OIDC identity to be exchanged for temporary cloud credentials after validating the workload's identity.

Although the terminology differs, the authentication flow remains the same. A Kubernetes workload presents its signed ServiceAccount token, the cloud provider verifies the token against a trusted OIDC issuer, evaluates the workload's identity, and issues short-lived credentials with the permissions assigned to that workload.

The differences lie primarily in configuration rather than architecture. Each provider has its own mechanism for defining trust relationships and authorization policies, but all of them follow the same fundamental federation model.

Understanding workload identity federation solved only part of the problem. AWS, Google Cloud, and Azure all supported federated authentication, but configuring that trust relationship across a production platform proved significantly more challenging than the authentication flow itself.

The platform continuously created and removed feature environments for development and testing. Every feature environment consisted of one or more Kubernetes namespaces generated automatically through Argo CD ApplicationSets. As engineers created branches or preview environments, new namespaces appeared dynamically without manual intervention.

Each namespace contained workloads that required access to cloud resources. Before a workload could authenticate successfully, the cloud provider needed to trust the Kubernetes ServiceAccount associated with that workload. This meant every new namespace potentially required new workload identity bindings across one or more cloud providers.

While the authentication model was standardized through OIDC, the configuration model differed considerably between providers. These differences made manual provisioning increasingly difficult as the number of namespaces and workloads continued to grow.

Rather than treating workload identity as a cloud configuration problem, I began viewing it as another reconciliation problem. Kubernetes already excels at continuously driving the current state of the system toward a desired state. The same principle could be applied to cloud identity bindings.

Every namespace already represented an operational intent. If a namespace existed and contained workloads that required cloud access, the necessary identity configuration should exist automatically. Likewise, when that namespace was deleted, the corresponding cloud identity bindings should be removed without requiring manual cleanup.

This shifted the responsibility away from engineers and toward the platform itself. Instead of asking teams to provision federation resources, the platform could observe namespace lifecycle events and keep cloud identity configuration synchronized through continuous reconciliation.

In other words, workload identity became another resource managed by the control plane rather than an operational task performed by humans.

The design insight naturally led to a Kubernetes controller responsible for managing workload identity bindings across cloud providers. Rather than relying on engineers to provision federation resources manually, the controller continuously reconciled cloud identity configuration with the current state of the Kubernetes cluster.

The controller watches namespace lifecycle events and determines whether workloads within those namespaces require cloud identities. When a new namespace is created, it provisions the appropriate workload identity bindings for AWS, Google Cloud, or Azure. When the namespace is removed, the associated cloud resources are cleaned up automatically.

This approach keeps Kubernetes as the single source of truth. Engineers declare the desired state by creating namespaces and deploying workloads, while the controller ensures that cloud identity configuration remains synchronized with that desired state.

Most importantly, application teams never interact directly with cloud identity systems. They simply deploy workloads using Kubernetes ServiceAccounts, and the platform transparently provisions the required federation infrastructure behind the scenes.

At the core of the solution is a Kubernetes controller responsible for reconciling workload identity bindings with the current state of the cluster. Rather than executing one-time provisioning scripts, the controller continuously observes namespace lifecycle events and ensures that the corresponding cloud identity configuration exists.

The controller follows the standard Kubernetes controller pattern. It watches for changes, compares the desired state with the observed state, and performs only the actions required to eliminate any differences. Because reconciliation is idempotent, processing the same event multiple times always converges to the same result.

By adopting Kubernetes' controller model, identity management becomes event-driven and self-healing. Failures can be retried automatically, and temporary inconsistencies are corrected during subsequent reconciliation cycles without requiring manual intervention.

The controller's responsibility is not simply to create workload identity bindings when a namespace appears. Its primary responsibility is to continuously ensure that the actual cloud identity configuration matches the desired state expressed by Kubernetes.

Every reconciliation begins by observing the current state of both Kubernetes and the target cloud provider. The controller determines which identity bindings should exist, compares that desired state against the existing configuration, and performs only the operations required to eliminate any differences.

This declarative approach differs fundamentally from traditional provisioning scripts. Instead of assuming previous operations completed successfully, each reconciliation independently evaluates the current system state and converges toward the desired configuration.

As a result, the controller naturally tolerates retries, partial failures, and transient cloud API errors. Whether reconciliation executes once or multiple times, the outcome remains the same—the cloud identity configuration eventually converges to the desired state.

Before building a dedicated controller, I evaluated several approaches for managing workload identity across dynamically created namespaces. Each option solved part of the problem, but none provided the level of automation, scalability, and operational simplicity required for a continuously evolving multi-cloud platform.

The goal was not simply to automate identity creation. The solution needed to remain Kubernetes-native, tolerate failures, support dynamic namespace lifecycles, and continuously reconcile cloud configuration with the cluster's desired state.

One of the first design decisions was whether workload identity should be represented as a new Kubernetes Custom Resource (CRD). At first glance, defining a resource such asWorkloadIdentityBindingappears to be a natural fit. It would allow identity mappings to be declared explicitly and reconciled like any other Kubernetes resource.

After evaluating this approach, I concluded that introducing a new API was unnecessary. The platform already contained the information required to determine the desired identity configuration. Namespaces, ServiceAccounts, and deployment metadata collectively described the intent of the system. Creating another resource would duplicate information that already existed.

Instead of asking engineers to create and maintain an additional object, the controller derives the desired workload identity directly from the existing Kubernetes resources. This keeps the operational model simple and avoids expanding the platform's API surface.

Beyond solving the immediate authentication problem, the solution was guided by several engineering principles that influenced every design decision. These principles ensured the system remained scalable, maintainable, and aligned with Kubernetes' operational model.

Rather than optimizing for the shortest implementation, the focus was on building a platform capability that could evolve alongside the Kubernetes control plane and support multiple cloud providers without introducing unnecessary complexity.

Bringing together Kubernetes identities, OIDC federation, and continuous reconciliation results in a fully automated authentication workflow. Developers interact only with Kubernetes resources, while the platform transparently provisions and maintains the cloud identity infrastructure required for workloads to securely access cloud services.

The sequence below illustrates the complete lifecycle—from creating a namespace to obtaining temporary cloud credentials. Each step builds upon the concepts introduced throughout this case study.

Feature environments are inherently temporary. New namespaces are created as developers open feature branches, updated as applications evolve, and removed once the work is complete. Rather than treating identity provisioning as a one-time operation, the controller manages cloud identity throughout the entire lifecycle of a namespace.

Every significant namespace event triggers reconciliation. Whether a namespace is created, modified, or deleted, the controller evaluates the desired identity configuration and applies only the changes necessary to keep cloud resources synchronized with Kubernetes.

This lifecycle-driven approach ensures that cloud identity evolves alongside the platform itself. Authentication infrastructure is created when needed, updated when requirements change, and removed automatically when workloads no longer exist.

Distributed systems rarely operate under perfect conditions. Cloud APIs may become temporarily unavailable, network connectivity can be interrupted, and partial configuration changes may occur during reconciliation. Rather than assuming these failures never happen, the controller was designed to recover from them automatically.

Since reconciliation continuously compares the desired state with the actual state, temporary failures do not permanently leave the platform in an inconsistent configuration. The controller simply retries until the observed state matches the desired state.

This approach eliminates the need for manual intervention in most failure scenarios and provides a resilient foundation for managing workload identity across multiple cloud providers.

Every architecture involves balancing competing priorities. The controller approach provided a scalable and Kubernetes-native solution for workload identity, but it also introduced additional responsibilities and operational considerations. Understanding these tradeoffs was an important part of selecting the final design.

Rather than optimizing for simplicity in the short term, the solution prioritized long-term maintainability, automation, and alignment with Kubernetes' declarative model.

After validating the architecture, the next step was translating the design into a Kubernetes-native controller. The implementation follows the standard controller-runtime pattern, combining informers, a reconciliation loop, and provider-specific adapters to automate workload identity across AWS, Google Cloud, and Azure.

The implementation intentionally separates Kubernetes-specific logic from cloud-provider integrations. The reconciliation loop focuses on computing the desired state, while provider adapters encapsulate the APIs and authentication mechanisms required by each cloud platform.

The primary objective of this project was not simply to replace static credentials with workload identity. It was to simplify platform operations while improving security and providing a consistent developer experience across multiple cloud providers.

By making Kubernetes the source of truth for cloud identity, the platform removed manual provisioning workflows and ensured that authentication evolved automatically with application deployments.

Building this system reinforced that successful platform engineering is rarely about introducing new technology. More often, it is about applying proven patterns to solve operational problems in a maintainable way.

While workload identity federation is supported by every major cloud provider, integrating those capabilities into a Kubernetes platform required careful consideration of lifecycle management, reconciliation, and developer experience. The implementation ultimately became less about cloud APIs and more about designing a control plane that continuously maintained the desired state.