[frx]

> AWS IAM has the exact same “issue” where an IAM principal can be allowed to access a resource without asking the party in question.

This is not correct. This would only work if the resource is in the same AWS account.

For cross account access, both the principal and the resource need to allow each other.

See: https://aws.amazon.com/premiumsupport/knowledge-center/cross...

[owenmarshall]

I think the concern is less technical and more policy.

I might be able to sts:AssumeRole to any number of roles created by bad cloud engineers that allowed my account instead of another. But - ignoring that it requires exceptional luck to find the right account/role pair - it takes explicit action on my part to move into their account. At the end of the day, I exchange my credentials for those in another account, and that action is logged in my account, theirs, and with AWS.

The concern here is this sharing happens without me doing anything. What happens if I get added to an account whose admin cries foul to Google? Or if their account is flagged for violating GCP terms? Given Google’s history, I’d be worried too.

[judge2020]

Technically, but this is more about how 'Account B Admin' must define who (user/principal) can access the resources Account A has already given Account B access to. The difference I see here is that it's not an invite system; Account A does not notify Account B of its new permissions when it grants them, and Account A is not notified when Account B's administrator has defined an access policy for those resources.