In a multi-cloud environment it is wise to use federated identities between different cloud environments. This removes the need to issue, manage, and rotate secrets. With federated identities a party running on (for example) Google Cloud can use the identity they already have within Google Cloud (attached to their VM or Cloud Function) to assume a federated AWS identity and then use that AWS identity to invoke API's from the other party. This could not only be custom API's (like API gateway), but since you fully impersonate an AWS identity (aka AWS Role) they could also invoke AWS own API's like S3.
Over time I've collected numerous samples of federation between different cloud providers. This is list of all of them:
- using a google cloud service account to impersonate an aws role
- using a google cloud service account to impersonate an azure service principal
- using an aws role to impersonate a google service account using http calls
- using an aws role to impersonate a google service account with google's nodejs library
- Using External Identities section in the Workload Identity Federation section of the Google Auth Library documentation for Java
- using auth0 client credentials flow to get an auth0 token and then impersonate a google cloud service account
- OAuth Client Authentication using Google Service Account