Cross-Account and Cross-Cloud Trust: The Identity Bridge

Day 35 established that a customer-managed database lives inside the customer's environment, and Day 37 established that modern apps authenticate with short-lived identity tokens instead of stored passwords. Put those together and a hard question appears: the application runs as an identity in your account (or even your cloud), but the database only trusts identities in the customer's account or cloud. An identity from your side means nothing to the customer's database by default — the two live in separate trust domains that don't know each other. Bridging that gap, keylessly, is the whole subject of this day.

There are four combinations, and it's worth naming them because they collapse into just two patterns. Your compute and the customer's database can be in the same cloud but different accounts, or in different clouds entirely. Same-cloud is the easier case; cross-cloud is where identities from two providers that share no common trust root have to be reconciled. Everything below reduces these four situations to two reusable trust models.

Every cross-boundary case is one of two trust models — a precise statement of what the customer's side is configured to trust. Naming them separately matters because they have different prerequisites and different failure modes, and knowing which case you're in tells you immediately which one applies.

The first is native trust (same cloud): because both sides run in the same cloud provider, that provider already has a built-in way for one account to trust an identity from another account. The customer simply configures their side to trust your identity directly — no external machinery needed, because a common trust root already exists. The second is federation (cross cloud): when the two sides are in different clouds, there is no shared trust root, so you need a one-time bridge that teaches the customer's cloud to accept an identity token issued by your cloud's identity provider. Federation is the general technique for making one identity system honor identities minted by a foreign one.

Rule of thumb: classify every cross-boundary connection first — same cloud or different clouds? — because that one question selects the trust model, and the trust model determines everything else: native trust when a shared root exists, federation when you must teach one identity system to honor another's tokens.

Whichever trust model applies, the runtime need is the same: your workload starts with an identity valid in your domain and must end up holding a credential valid in the customer's domain. The step that performs that conversion is the identity bridge. It is the one place the four cases genuinely differ, and it's worth isolating because everything after it — minting the actual database token — is identical regardless of how you crossed the boundary.

The bridge works by assuming or impersonating a principal the customer controls. In the native case, your identity directly assumes (steps into) a role the customer created, and the provider hands back temporary credentials scoped to that role. In the federated case, there's an extra hop first: your cloud's identity token is exchanged, through the one-time federation bridge, for a foothold in the customer's cloud, and then you assume/impersonate the customer's principal as before. Either way the output is the same: short-lived temporary credentials valid inside the customer's environment, which the database token is then minted from.

Because the temporary credentials are themselves short-lived, the bridge is not run on every single connection — it runs roughly once per credential lifetime (on the order of an hour) and the result is cached and reused, while the even-shorter database token is minted from it per connection. Separating the two — a cached bridge step, a cheap per-connection token — is what keeps the cross-boundary machinery from adding latency to normal traffic.

A design principle runs through both trust models and is worth stating on its own because it's what makes the whole arrangement safe: the customer always owns and scopes the principal you connect through, and you never hold a long-lived credential to their environment. You don't get a key to their account; you get the ability to briefly assume a role they created, scoped by them to exactly one permission — connect to their database — and nothing else.

This gives a clean ownership boundary. The customer creates the role, decides precisely what it can do, and can revoke it unilaterally at any time by deleting it — no coordination with you required. You, in turn, only ever receive temporary credentials that expire on their own, so there's nothing durable on your side that a breach could turn into standing access to the customer's data. The cost is one extra hop and a role the customer must create, which is a small price for a boundary where each side owns and can sever its own half.

Rule of thumb: make the customer the owner of the principal you connect through and accept only short-lived credentials — a clean ownership boundary (they scope it, they revoke it; you hold nothing durable) is worth the extra hop, because it means neither a breach on your side nor a dispute leaves standing access to their data.

Letting an identity assume a role across a trust boundary opens a classic security hole called the confused deputy — worth understanding because it's easy to create by accident. The "deputy" is a privileged intermediary (here, the shared identity that's allowed to assume customer roles). The danger: if a customer writes a trust rule that says "allow that shared identity to assume my role," then any party who can get that shared identity to act on their behalf could be tricked into connecting to the wrong customer's database — the deputy is confused about who it's really working for.

The fix is to require an extra, per-customer piece of proof that ties each assume-operation to the specific intended customer. In the native case this is an external correlation id: a unique value the customer pins into their trust rule, which your side must present when assuming the role — so a request lacking that customer's value can't assume that customer's role, even from the shared identity. In the federated case, the equivalent is pinning the exact subject and audience of the incoming token in the customer's trust rule, so only tokens minted for that precise purpose and identity are accepted. Both do the same job: they turn "trusts the shared identity" into "trusts the shared identity for this specific customer, proven per request."

Rule of thumb: never let a customer trust only a shared identity — always require a per-customer pinned value (an external correlation id, or an exact subject+audience match) so each cross-boundary assume is provably tied to the one customer it's meant for; that pin is the difference between a safe deputy and a confused one.

A cross-boundary trust setup can be perfectly designed and still fail at the last step, because many organizations enforce a policy that blocks sharing access with identities from outside the organization — a sensible default that exists precisely to stop accidental external grants. If that policy is in force on the customer's side, their attempt to trust your identity will be rejected, often with an opaque error, after they've done the work.

The lesson is operational: surface this prerequisite before asking the customer to create the grant, not after it fails. Both major shapes of this control — an allow-list of external domains that may be shared with, and an account-level guardrail that forbids certain external grants — must be adjusted by the customer's administrators to permit your specific identity before the trust rule will take. Detecting and stating that requirement up front turns a confusing mid-flow failure into a one-line checklist item the customer clears in advance.

Rule of thumb: treat "the customer's org may forbid sharing with outside identities" as a first-class prerequisite you warn about before the grant step — a guardrail that blocks the trust relationship is common and fails opaquely, so naming it up front is the difference between a clean onboarding and a stuck one.

Cross-boundary trust is the part of the system a security review scrutinizes hardest, because a mistake here is what lets the wrong party reach a customer's data. The questions cluster around one worry — "is this trust scoped to exactly who it should be, and can anyone else slip through?" — and a good design answers each concretely.

Is the customer's trust policy scoped to a single, specific caller, or does it trust a broad principal? A broad grant is the confused-deputy hole from earlier in this day; the answer must be a per-customer pinned proof (a correlation id, or an exact subject+audience match). Can an unlinked or unauthorized tenant connect at all? This is worth an explicit negative test — a request that isn't the linked tenant must be refused, and the design should be able to demonstrate that failure, not just assume it. What privilege does the granted role actually hold? The intended answer is least privilege: connect-only, reaching one database and nothing else, so even a fully-exercised grant can't read the customer's wider environment. Do the customer org's guardrails against sharing with outside identities block the grant? Surface those prerequisites before the grant step so they're cleared in advance. And finally, what is the blast radius if the caller identity is compromised — how many customers, and how is that contained?

Rule of thumb: the single most important security answer at a trust boundary is a working negative test — being able to show that a party who isn't the linked tenant is refused is worth more than any amount of asserting the policy is scoped correctly, because confused-deputy bugs hide precisely in the gap between "we scoped it" and "we proved nobody else gets in."

• Cross-account/cross-cloud auth exists because your compute runs as an identity in your domain while the customer's database trusts only identities in its domain — separate trust domains that don't know each other by default.
• The four combinations reduce to two trust models: native trust when both sides share a cloud (a common trust root already exists) and federation when they don't (a one-time bridge teaches one identity system to honor another's tokens). Ask "same cloud or not?" to pick.
• The identity bridge converts your home identity into short-lived credentials valid in the customer's domain by assuming/impersonating a customer principal (with an extra exchange hop in the federated case); it's cached ~hourly, and the per-connection database token is minted from it.
• The customer owns and scopes the principal you connect through, and you hold only short-lived credentials — a clean ownership boundary where they revoke unilaterally and a breach on your side leaves no standing access.
• The confused-deputy risk (a rule that trusts only a shared identity) is closed by a per-customer pinned proof — an external correlation id, or an exact subject+audience match — that ties every assume to the specific intended customer.
• Organizations often block sharing with outside identities by policy; surface that prerequisite before the grant step, because it fails opaquely and after the customer's work.
• A security review presses hardest on the trust boundary: trust scoped to one caller, an explicit negative test proving an unlinked tenant is refused, connect-only least privilege, cleared org sharing guardrails, and a stated, bounded blast radius.

• [ ] I can explain why an identity in one account/cloud is meaningless to a database in another by default.
• [ ] I can state the two trust models and use "same cloud or different clouds?" to choose between native trust and federation.
• [ ] I can describe the identity bridge, what it outputs, and why it's cached rather than run per connection.
• [ ] I can explain why the customer owning and scoping their own principal (and you holding only short-lived creds) is the safe boundary.
• [ ] I can define the confused-deputy problem and explain how an external correlation id or pinned subject+audience closes it.
• [ ] I can name the "org blocks outside identities" prerequisite and explain why it must be surfaced before the grant step.
• [ ] I can list the security-review questions at a trust boundary and explain why a working negative test is the most important answer.