IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Cross-account & cross-cloud trust
Real companies run many cloud accounts, and sometimes a second cloud. A workload in one account must read something in another. Your goal: let one account trust one named principal from another, and avoid the trap that comes with it.
- Separate accounts keep a breach small.
- Account B trusts one named role from account A.
- A broad trust policy invites the confused deputy trap.
- An external ID and exact names stop it.
- Across clouds, use federation, not a shared password.
Why use many accounts?
The reason is blast radius isolation. Put dev, staging and prod in separate cloud accounts. Some clouds call them projects or subscriptions. A mistake or a breach in dev cannot reach prod. They have different credentials. A leaked dev key opens only dev.
Separation is a security control, not just tidiness. It builds on zero trust: no account trusts another by default.
Maya's order reaches the app in account A. A workload there must read a price table in account B. There is no shared login. So the owner of B writes down exactly which principal from A may come in.
How one account trusts a principal from another
The method is role assumption across an account border. Account B makes a role with the permissions needed. It adds a trust policy that says who may assume the role. Only the fulfillment workload in account A may.
Account A's workload shows its own signed identity and asks to assume the role. It gets short-lived credentials for exactly what the role allows. No password crosses the border. See Cloud identity 101 for principals and roles.
The confused deputy, and the condition that stops it
Here is the trap. Say account B's trust policy reads: any principal in account A may assume this role. A service in account A that works for many customers can now be tricked. A stranger asks it to assume the role for them. The service has the power, and the stranger only borrows it. This is the confused deputy problem.
a courier office that keeps parcels for many shops. The clerk is trusted with all of them. A stranger says, "Give me shop B's parcel." A careless clerk hands it over. So the office gives each shop its own pickup code. The clerk hands out a parcel only for the code in front of them.
The fix is a condition in the trust policy. A common one is an external ID. It is a unique value for the real caller, and the assume-role request must carry it. It is an identifier, not a password.
The deputy sends the ID it holds for the party it really serves. An attacker cannot make it send the victim's ID. So the request fails, even though the principal is allowed.
Across two clouds: federation, not a shared password
What if account B is on a different cloud? You could create a permanent key in cloud B and store it in cloud A. Now you own a long-lived cross-cloud secret. That is the worst choice.
The better answer is workload identity federation. Cloud A's workload shows its own signed identity token. Cloud B trusts that issuer for one specific subject. Cloud B gives back its own short-lived credentials. No standing secret lives anywhere.
Every hop is a named principal that assumes a named role. So when Zara investigates, the logs in account B rebuild the whole chain.
The number-one cross-account mistake is a trust policy that is too broad. It trusts "anyone", a whole account with no principal named, or a wildcard. Pair a specific principal with a condition.
Go deeper: the external ID is not a secret
An external ID is only an identifier. Its job is to be unique for each customer. The service that acts as the deputy chooses it, not the customer. If customers could pick their own IDs, one customer could pick another customer's value. The deputy then sends the right ID for the right customer every time.
Go deeper: other conditions that do the same job
Sometimes a cloud service, not your own code, assumes a role for you. Clouds offer conditions for this case. They say which account, organization or resource the service acts for. Use them. They stop a service from being tricked into using your role for someone else's resources. Check your cloud's documentation for the exact names.
🧪 Interactive lab — enable JavaScript to play with this one.
Grade a cross-account trust policy for confused-deputy and wildcard risk with IAM Trust Check. Analyze cross-cloud workload identity federation trust with OIDC Federation.