Your Kubernetes pods are hungry for secrets. API tokens, database passwords, encryption keys—all the sensitive bits that make microservices tick. When your cluster runs on Amazon EKS but your organization standardizes on Azure Key Vault for secret storage, the question hits fast: how do you connect them safely, without babysitting credentials?
Amazon EKS runs managed Kubernetes on AWS infrastructure. It gives you scalability and control without owning the control plane. Azure Key Vault, on the other hand, locks away keys and secrets with Azure Active Directory–backed identity. They live in different clouds, but integration between them can actually improve your security story if you wire it right.
The short version: let EKS authenticate to Azure Key Vault using workload identity. Instead of embedding service principals or static creds, you map EKS service accounts to Azure identities through OIDC federation. AWS IAM issues tokens that Azure trusts, so Kubernetes workloads can fetch secrets with zero long-lived credentials. The benefit is simple but powerful—secure, repeatable access managed by identity, not files.
Here’s the logic flow.
A pod running on Amazon EKS requests a token from its assigned service account. That token contains metadata signed by AWS. Through an established OIDC trust, Azure validates this token against its directory. Once verified, the pod gets temporary, scoped access to the right vault. Secrets flow only on demand. No developer ever handles a key.
To keep it clean, define clear RBAC boundaries. Each service account should map to its own Key Vault role. Rotate access policies regularly and audit them. Connect your CI/CD so updates to identity mappings can roll out automatically. The fewer manual steps, the smaller the blast radius.