You know the feeling. You SSH into an EC2 instance to grab a quick log file or tweak a config, then realize no one remembers where the service account keys for Firestore live. Worse, that “temporary” key from last quarter is still floating around your repo. It’s a small fire every ops team has fought.
AWS Systems Manager (SSM) fixes the first half of that chaos, providing secure, auditable access to your EC2 instances without juggling SSH keys. Firestore, Google Cloud’s NoSQL database, handles the structured document storage side of your app. Together, they can form a clean, encrypted path from compute to data, but only if you connect identity and permissions with care.
Here’s the logic, not just the setup sequence. SSM Session Manager authenticates your engineer or automation via AWS Identity and Access Management (IAM). From there, it establishes a controlled session on the EC2 instance. That instance then needs a way to call Firestore without embedding service account secrets. The best pattern is to use short-lived credentials provided by AWS’s Security Token Service and a trusted identity broker. The broker exchanges the IAM role for a Google service account token through an OpenID Connect (OIDC) trust. That keeps Firestore calls stateless and secure, no static keys required.
Quick answer: Configure an OIDC identity provider between your AWS IAM roles and Google service accounts, then bind those roles to the EC2 instances managed through Systems Manager. This gives Firestore read or write access without persisting credentials on disk.
Once this flow runs, you can automate EC2’s outbound Firestore calls through SSM Automation documents or Run Command tasks. Your access policies remain centralized in IAM and Google Cloud IAM, synced through OIDC. Each request is traceable. Each credential is temporary. Compliance teams finally exhale.
A few best practices help:
- Rotate your IAM roles regularly. OIDC trust makes this cheap.
- Limit SSM access to tagged instances only.
- Explicitly scope Firestore access to collections your workload needs.
- Log session activity with CloudTrail and Cloud Audit Logs.
- Test token expiration routines before production rollout.
The benefits stack up fast.
- Security: No static keys in EC2 or config files.
- Reliability: Automatic reauthentication keeps long jobs alive safely.
- Auditability: Central logs across AWS and Google Cloud.
- Speed: Developers stop waiting for manual key provisioning.
- Simplicity: One role definition covers hundreds of instances.
For developers, this means less toil and fewer Slack pings asking for credentials. System access feels invisible yet safer. The velocity you gain from removing onboarding friction often surprises teams who integrate Systems Manager and Firestore cleanly.
Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of trusting everyone to follow procedure, the platform applies your intended identity flow every time, across clouds and environments. It’s how infrastructure stays consistent even when people move fast.
How do I connect EC2 Systems Manager and Firestore without manual secrets?
Use an OIDC trust between AWS IAM and Google service accounts. SSM provides managed access to EC2, and OIDC ensures Firestore tokens are minted on demand, bound to workload identity, and never hardcoded.
Does this integration support automation workflows?
Yes. You can trigger Firestore reads and writes directly from SSM Automation or Run Command tasks. Each operation inherits short-lived credentials, preserving compliance with SOC 2 or ISO 27001 controls.
In short, tying EC2 Systems Manager to Firestore replaces brittle key management with policy-based identity. You get smoother deploys, lighter audits, and happier engineers.
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.