blog/2024/05/27/how-to-access-aws-from-azure-vm-using-openid-connect/

[giscus[bot]]

blog/2024/05/27/how-to-access-aws-from-azure-vm-using-openid-connect/

How to connect Azure to AWS with OpenID Connect. What is AWS OpenID Connect. Establish trust relationship between Azure AD to AWS services with OIDC.

https://developer-friendly.blog/blog/2024/05/27/how-to-access-aws-from-azure-vm-using-openid-connect/

[ThePants999]

Thanks for this - great walkthrough!

I'm obviously coming a bit late to this party so perhaps you've since figured this out, but I can help you with the "audience" confusion. What's going on here is this.

• The AWS identity provider object is slightly misnamed. It's not actually intended to map to the entire identity provider as a whole - it's intended to map to one or more applications that users (human or machine) will be authenticating with via this identity provider. The expectation is that these users will fetch an access token for one of these applications; the token they get will identify that application as the audience (i.e. put its URI as the aud claim).
• What you've done in this article is to use ARM (Azure Resource Manager) as the application - that's the app identified by https://management.core.windows.net/. The reason this works is because (a) any Azure identity is permitted to get an access token for ARM, and (b) you use az account get-access-token with no parameters, which defaults to requesting an ARM access token.
• This is... okay in conjunction with your validation of the sub claim. However, the better approach is to create an Enterprise Application in Entra ID (or you might already have one). Make sure it has the "Assignment required" property set to Yes, which means that only users/machine identities that have been assigned to it will be able to get an access token for it. Then you use that app's application ID URI as the audience in your AWS identity provider, and you use it in conjunction with the --resource parameter in az account get-access-token to make it the aud claim of the token you request/get. You'll need to assign your managed identity to it before you can do that. This technically allows you to skip the sub claim validation on the AWS side, using assignments to the Enterprise Application to control which identities are allowed to assume the IAM role without AWS needing to know anything about the individual identities. That said, to avoid the risk of major security holes if you, say, forget to enable "Assignment required", it's good belt-and-braces security to keep the sub claim validation in IAM as well as the built-in aud checking.