Substitute for removed ClientSecretCredential

[hsvnsson]

Hi,

When upgrading azure_identity from 0.21.0 to 0.22.0, I noticed that the ClientSecretCredential type was removed (in #1821).

I can see that it was done as part of a cleanup initiative of the azure_identity crate, now I'm trying to understand why and if there is a new type or something else that should be used instead of ClientSecretCredential to get a token from a client id and a client secret?

[RickWinter]

For development scenarios we suggest using the Azure CLI credential. For production scenarios we recommend using managed identity. Can you share some on your scenario and where you were using ClientSecretCredential.

//cc: @scottaddie

[github-actions]

Hi @hsvnsson. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[hsvnsson]

Sure I will try to give some context of our usage of it.

We're using this library in a platform that integrates with PowerBi and ingests information using the PowerBi rest api.

A user of the platform configures the PowerBi integration by first creating a Microsoft Entra App and generating a client secret for it as described in the PowerBi docs here.

The client id, client secret and tenant id is then provided to the platform so it can access the apis.

Regarding managed identities that seems to be a way to assign an identity to a resource running inside Azure which then allows that resource to access other Azure resources (e.g. PowerBi in this case). If that definition is correct then it will not work for our use case since the platform might be hosted outside of Azure.

Ideally we would like to continue with client credentials if possible because it would be quite a breaking change for our users to be forced to reconfigure the integration.

[heaths]

I appreciate having an easy-to-use credential type for end users, and can attest that ClientCertificateCredential is not that. But would an InteractiveBrowserCredential or DeviceCodeCredential (both OAuth) suffice? We're really trying to avoid promotion of credentials that make customer vulnerable, such as retaining secrets in insecure files or environment variables.

[github-actions]

Hi @hsvnsson. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[hsvnsson]

I understand and it's great that you're trying to nudge people into using "better" authentication options. But I also think there are some valid cases when those are not really viable.

Took a quick look at both InteractiveBrowserCredential and DeviceCodeCredential, unfortunately I don't think that would work for us give that they require active user interaction.

Our platform also supports IaC (think terraform) which can be run both interactively but also in CI/CD pipelines to deploy new configuration. So therefore a requirement is that it does not require any active user interaction.

For us it seems that client credentials are kind of the best option, secondly client certificates but as you say that's not very user friendly.

Also feels a bit odd that the SDKs in other languages all support client credentials but the rust SDK will not? (note: only checked .NET/golang/python/javascript). I understand that the Rust SDK is fresh and does not need to deal with deprecation processes yet so being conservative in the beginning might be good.

[spiralshapemirmircat]

For development scenarios we suggest using the Azure CLI credential. For production scenarios we recommend using managed identity. Can you share some on your scenario and where you were using ClientSecretCredential.

//cc: @scottaddie

What about a scenario where you are running integration tests (against a development environment) that need to interact with the azure services and the VMs the tests are running on can not interactively retrieve the credential, use the CLI, and are not within azure to be associated with the managed identity?

[heaths]

Also feels a bit odd that the SDKs in other languages all support client credentials but the rust SDK will not?

We've learned some things since the credential was GA'd and try our hardest not to make breaking changes.

We're also not saying we won't, but that we didn't initially. This user feedback is important. /cc @ronniegeraghty I still feel like maybe we could put it behind a feature flag.

What about a scenario where you are running integration tests (against a development environment) that need to interact with the azure services and the VMs the tests are running on can not interactively retrieve the credential, use the CLI, and are not within azure to be associated with the managed identity?

Development environments use the PowerShell credential or Azure CLI credential. We don't allow client secrets anymore. Our test tenant has a policy in place and exceptions are required if absolutely necessary. For CI pipelines we'll have the AzurePipelineCredential (#2030), which is what other languages are using currently.