Your team ships microservices fast. Then the real problem hits: half your workloads live on Google Cloud, the rest run inside Amazon EKS. Everything works, until you need identity, routing, and security to behave the same way. That’s where Cloud Run EKS integration earns its keep.
Cloud Run gives you serverless simplicity. EKS gives you Kubernetes muscle. Together they bridge the line between managed and self-managed infrastructure. When wired correctly, a service on Cloud Run can talk to workloads in EKS like they’re in the same controlled neighborhood, even though they live in different clouds.
The glue is identity and networking. Cloud Run services can use Workload Identity Federation to assume AWS IAM roles through OIDC. EKS, on its side, can expose private endpoints, run internal ingress controllers, and accept traffic from authorized Google identities only. The trick is setting up policy and trust so neither cloud thinks the other is a stranger. Once this trust chain is built, deployments flow smoothly across clouds with no secret juggling or static credentials.
How to connect Cloud Run and EKS
Cloud Run points to an HTTPS endpoint hosted in EKS behind an AWS ALB or API Gateway. You attach an OIDC trust provider in IAM to validate tokens minted by Google. Your Kubernetes service accounts map to IAM roles, giving granular control for each workload. No hardcoded keys. No copy‑pasted secrets. Just identity‑aware calls that work.
That’s the 40‑second answer when someone asks, “Can Cloud Run access EKS securely?” Yes, by exchanging OIDC tokens instead of passwords and enforcing IAM roles on both ends.
Best practices
- Use short-lived credentials and let OIDC refresh automatically.
- Keep policies scoped to specific resources, not global wildcards.
- Rotate service accounts or roles periodically to meet compliance rules like SOC 2 or ISO 27001.
- Test latency and retry behavior, since cross-cloud hops can surprise you.
- Audit every call with Cloud Logging and AWS CloudTrail for mirrored visibility.
The benefits stack up quickly:
- Cleaner RBAC mappings across providers.
- No shared secrets moving between teams.
- Faster incident response since every call carries a traceable identity.
- Consistent compliance posture for auditors who dislike surprises.
- Improved developer velocity through less manual provisioning.
For developers, Cloud Run plus EKS feels like a productivity merge. You build on one platform, deploy to another, and identity just works. Less waiting on platform tickets means more shipping code before the afternoon coffee cools.
AI copilots and automation agents push the value even further. They can now deploy microservices or trigger remediation tasks across both platforms without holding static credentials. Instead they request trusted tokens on demand, preserving context security while keeping the pipeline fast.
Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of engineers hand‑tuning trust relationships, hoop.dev standardizes secure, identity‑aware connections across teams and providers.
Quick question: Do you need Cloud Run and EKS to use the same auth domain?
Not exactly. You just need to enable cross-provider OIDC so each system trusts the other’s tokens. That keeps both your Google and AWS identities working under a single access narrative.
Handle identity once, not twice. That is the quiet beauty of Cloud Run EKS integration — security as configuration, not ceremony.
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.