Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

azcli auth doesn't support MSAL scopes #189

Open
thomas11 opened this issue Oct 9, 2022 · 1 comment
Open

azcli auth doesn't support MSAL scopes #189

thomas11 opened this issue Oct 9, 2022 · 1 comment

Comments

@thomas11
Copy link

thomas11 commented Oct 9, 2022

Currently, in AzureCliAuthorizer.Token(), the arguments to az are hard-coded as

{"account", "get-access-token", fmt.Sprintf("--resource=%s", a.conf.Endpoint)}

This is correct for ADAL and also works for MSAL as long as you need the default scope of Resource Manager. However, for a different scope like KeyVault, the arguments should instead be

{"account", "get-access-token", fmt.Sprintf("--scope=%s", a.conf.Endpoint+"/.default")}

Note the MSAL-style (OAuth v2) scope.

I tested the above change and it unblocked a small program that changes Key Vault secrets. I don't have a full PR just yet because I wasn't sure how you wanted to treat MSAL vs ADAL here.
@thomas11
Copy link
Author

Related question - @manicminer , does contributing to this repo require a CLA?

@thomas11 thomas11 mentioned this issue Mar 24, 2023
Merged
thomas11 added a commit to pulumi/pulumi-azure-native that referenced this issue Mar 28, 2023
@thomas11
MSAL and OIDC support (#2320)
db073ee 
## About

This PR contains two related pieces:
1. Switch the provider from the deprecated ADAL authentication method to
the current MSAL method. Due to an issue in our dependencies, one of the
authentication paths, the `az` cli, doesn't work properly with MSAL. We
detect the unsupported cli case dynamically and fall back to ADAL in
that case.
2. Enable OIDC for authentication. The actual OIDC implementation is in
our dependencies but enabling it was gated behind MSAL. This PR exposes
the relevant configuration settings and adds a dedicated test.

### What's MSAL?

The provider currently uses an authentication method called ADAL that’s
out of support in Azure. ADAL, also called auth v1, is [replaced by
MSAL](https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-migration)
(auth v2).

OIDC only works on MSAL.

These protocols are implemented in our dependencies _go-azure-helpers_
and _hamilton_ so we don't need to care about the details, except for
two things that surface in our code:
- MSAL has a new concept of _scopes_ for more targeted authentication
scopes. You can't just get a token for everything in an Azure account or
subscription, you can only get one for ResourceManager, or KeyVault,
etc. Since Pulumi deals with infrastructure, we can get away with
ResourceManager for most operations, but we do have some [custom
resources](https://github.com/pulumi/pulumi-azure-native/pull/2320/files#diff-bd590eb4f290efeb8760fc0743f5af2db35ceb776e7ef64a1cb641303e878426)
that touch the data plane and need a different scope.
- The dependencies [don't implement MSAL correctly when the `az` cli is
used](manicminer/hamilton#189) for
authentication. This PR falls back to ADAL when that case is detected.


### What's OIDC?

It stands for **OpenID Connect** and is an authentication protocol on
top of OAuth. The idea is to allow trusted parties to verify a user's
identity. For a practical example, let's look at how I set up OIDC
authentication between Github Actions and Azure, which is used by the
e2e test of this PR. We tell Azure that GitHub can be trusted:

1. On an Azure Active Directory (AD) App, add a new credential with
issuer GitHub.
2. In GitHub, configure the Action with the id of the AD App.

Now, when the action runs, GitHub can use the Azure AD endpoint to
exchange the GitHub token for an Azure token.

Note that there is no secret involved anywhere that would need to be
safely stored, rotated, etc. This is one of the biggest advantages of
OIDC.

Details for the interested [here
(GH)](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)
and [here
(Azure)](https://learn.microsoft.com/en-us/azure/active-directory/workload-identities/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#configure-a-federated-identity-credential-on-an-app),
but not required reading for reviewing this PR.


## Testing

I picked an existing e2e test, `keyvault`. In general, any e2e test will
do since we only want to see that authentication works. However,
`keyvault` has more authentication test coverage than the other tests
because it also creates a key vault secret, which is a data plane
operation that requires a different token. We run this test now twice,
authenticating once via client secret and once via OIDC.


## Next steps

To fully release OIDC support we need to document it in our user-facing
documentation.

I should also document the particular OIDC integration used in testing
in our wiki (AD principal, roles, permissions etc.).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@thomas11