Access to More Than One Cloud Provider
You set up access to more than one cloud provider by linking one identity directory to each cloud. Engineers log in once and assume temporary roles across AWS, Azure, and Google Cloud. Many teams start by creating separate user accounts in every cloud console. That approach spreads static keys everywhere and makes permission audits slow and error-prone. When teams grant broad roles to save time, one leaked key can expose multiple clouds at once. How to set up access to more than one cloud prov
Customer Support Access to Production + K8s Encryption Provider Config: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up access to more than one cloud provider by linking one identity directory to each cloud. Engineers log in once and assume temporary roles across AWS, Azure, and Google Cloud. Many teams start by creating separate user accounts in every cloud console. That approach spreads static keys everywhere and makes permission audits slow and error-prone. When teams grant broad roles to save time, one leaked key can expose multiple clouds at once.
How to set up access to more than one cloud provider
A clean setup starts with one central identity provider, such as Okta or Entra ID. You make this directory the single source of truth for all team members. Next, you set up a trust link between your identity provider and each cloud account. This trust uses standard protocols like SAML or OpenID Connect to verify user logins. You do not create local passwords or static keys inside the target cloud accounts.
Instead, you map user groups in your directory to specific roles inside each cloud. For example, a data team group maps to a read role in AWS and BigQuery. When an engineer logs in, the identity provider checks their group and MFA status. It then sends a signed token to the target cloud provider. The cloud checks the token and grants a temporary session to the engineer. When the session timer runs out, the role stops working right away.
How workload identity handles cross-cloud apps
Human users are only half of the multi-cloud puzzle. Apps running in one cloud often need to read or write data in another cloud. In the past, teams put long-lived service keys into app settings to make this work. If someone stole those keys, they could read cloud resources from anywhere on the internet.
Workload identity federation fixes this risk by removing static service keys from your apps. You set up your second cloud to trust tokens from your first cloud. When an app in AWS needs Google Cloud storage, AWS signs a short-lived identity token. The app sends that token to Google Cloud, which checks it and returns temporary permissions. The app gets the data it needs, and no static key ever sits on disk.
Customer Support Access to Production + K8s Encryption Provider Config: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where native cloud permissions fall short
Federated roles solve the login problem across multiple clouds. When someone leaves the company, you disable one directory account to cut off all cloud logins. You also get rid of long-lived keys sitting on engineer laptops.
Still, cloud roles only govern who can log into a service or open a network port. Once a database or cluster session starts, the cloud role steps out of the way. A role cannot tell a safe SQL read apart from a broad table drop. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results. Also, each cloud writes logs in its own format and stores them in separate places. Security teams must stitch together different log streams just to see what one user ran.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why should teams avoid static IAM keys across multiple clouds?
Static keys never expire on their own and often end up in code or laptops. If an attacker finds a key, they can use it from any network until you revoke it. Federated logins replace static keys with short sessions that expire after a few hours.
How do we map one team group to roles in different clouds?
You create a group in your central directory and assign engineers to that group. Then you link that group name to an IAM role in each cloud provider. When users log in, the cloud reads the group claim and assigns the matching role.
Can cloud IAM roles mask sensitive data inside database queries?
No, cloud IAM roles only control whether a user or app can reach the database service. Once the database session opens, native cloud IAM does not inspect or rewrite query results. Masking fields like national IDs or card numbers requires controls at the query level.