You finally got your EKS cluster humming on AWS. Then someone says, “We store secrets in GCP.” Great. Two clouds, two IAM models, and one long sigh. Welcome to the modern multi-cloud reality, where “just connect it” turns into a full-page diagram of trust relationships.
EKS (Amazon Elastic Kubernetes Service) runs your workloads, but you want GCP Secret Manager to hold the sensitive bits. It makes sense. Secret Manager is secure, versioned, and easy to rotate. But the hard part is bridging identity: EKS speaks AWS IAM, while Secret Manager expects Google service accounts and OAuth tokens. The trick is making these two languages align so pods can fetch secrets without violating least privilege.
Here’s the logic. You use Kubernetes service accounts to request AWS IAM roles via IAM Roles for Service Accounts (IRSA). You attach a trust policy that allows GCP credentials to be bootstrapped through Google’s Workload Identity Federation, or a symmetric mechanism where an AWS workload can use a broker to exchange AWS-issued credentials for a short-lived Google token. From there, your pod runs with ephemeral, scoped credentials that can read selected secrets from GCP Secret Manager. No static keys, no plaintext YAML.
The integration lives or dies by your identity mapping. Always verify that your IAM and GCP roles match exactly. A single wildcard can quietly open half your infra. To keep it tight:
- Create dedicated service accounts per namespace or team.
- Rotate credentials automatically, ideally every few hours.
- Enforce audit logging at both AWS CloudTrail and Google Cloud Audit level.
- Use OIDC trust rather than long-term service keys.
The payoff is worth it.
Benefits:
- Strong, trackable cross-cloud identity control without secret sprawl.
- Automatic rotation keeps compliance officers calm.
- Reduced operator toil, since developers no longer handle access keys.
- Unified logging gives you a clear story during incident reviews.
- Builds trust between DevSecOps and platform teams, finally.
Platforms like hoop.dev take this one step further by abstracting the policy logic itself. Instead of maintaining YAML templates or manual role bindings, you define intent, and the system enforces those access rules automatically across clouds. That’s how you turn security from a meeting topic into a built-in feature.
How do I connect EKS and GCP Secret Manager without storing credentials?
Use federated identity. Configure EKS service accounts to assume an AWS role, then exchange that role’s token for a temporary GCP access token through Workload Identity Federation. This removes the need for any static credentials or manually synced secrets.
For developers, the experience changes overnight. No more waiting on ops for key files. Your pod just starts, pulls what it needs, and moves on. That’s real developer velocity — fewer blockers and faster secure delivery.
AI systems that deploy into these environments also benefit. When credentials are ephemeral and scoped precisely, automated agents can retrieve configuration data safely without risking long-term leakage in logs or prompts.
Once you configure this bridge, EKS and GCP Secret Manager stop feeling like rivals and start behaving like teammates. One holds your compute, the other your secrets, both locked by ephemeral trust.
See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.