Implementors of IResourceWithAzureFunctionsConfig should set additional params for identity-based configuration.

[mattchenderson]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Aspire will set AZURE_CLIENT_ID to inform connections of the client ID to use. When exploring scale rules setup for Azure Functions, it appears that KEDA is one example of a component that doesn't process AZURE_CLIENT_ID yet.

Describe the solution you'd like

Functions also offers a combination of two other parameters, and this is the typical recommendation for setting up connections with a user-assigned identity: <CONNECTION_NAME_PREFIX>__credential (always set to "managedidentity") and <CONNECTION_NAME_PREFIX>__clientId (set to the client ID). These are documented here.

This combination of settings should be valid for all existing implementers of IResourceWithAzureFunctionsConfig, but this should be approached on a case-by-case basis.

There's a bit of repetition and verbosity here, but it ensures the components will work as expected. Longer-term, KEDA could be updated to process AZURE_CLIENT_ID, and we could explore removing some of the repetition if needed.

Additional context

Triggers and bindings will mostly be set up to consume AZURE_CLIENT_ID, but there may be some variance in the overall config approach. Ensuring we capture a complete setup within each IResourceWithAzureFunctionsConfig will improve resilience to this.

This would also be preferable if there were to be support for multiple identities in the distributed application.

Note that these settings should be set together. Setting only one will not have the desired effect. Today, the integration uses DefaultAzureCredential, which during probing picks up AZURE_CLIENT_ID to use for MI. Just setting the connection-level client ID would be ignored. By setting the credential property, though, we force the system to instead use ManagedIdentityCredential, and without the client ID setting, it would just attempt to resolve a system-assigned managed identity, which would not exist in normal Aspire configurations.

[captainsafia]

This combination of settings should be valid for all existing implementers of IResourceWithAzureFunctionsConfig, but this should be approached on a case-by-case basis.

What do we need to consider when evaluating case-by-case for the existing resources we have?

[mattchenderson]

Apologies - I didn't phrase that well. If implemented in the expected way, all of our triggers and bindings should do the right thing here. There have, however, been some hiccups in the past, so this was me flagging a "something to think about / check on" for the future as we expand the integration set. I can assert that the existing integration set complies with this correctly, and there should be nothing blocking those.

Typing that prompted me to consider if we would set this centrally or ask this of each IResourceWithAzureFunctionsConfig implementation. I think having it within each allows us to handle deviation if ever needed. That's also just aligned better with the way things are in the code base today. We'd lose out on enforcement and could have mistaken omissions, but it should be easy enough to catch this in review.

[davidfowl]

I think I know how this should work. @eerhardt , it’s similar to known parameters though I’d want it to be a sentinel value though

[davidfowl]

We may need to tweak IResourceWithAzureFunctionsConfig, we need the target resource to do this inside of the resource itself.

[davidfowl]

Actually, it might be possible to do this without API changes, see #8868