Proof-of-Concept: MI via CCA #560
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If this PR will be merged in, the subsequent "how to use Managed Identity" docs would look like this.
Managed Identity is a kind of confidential client that you do not need to manage its credential.
or
or
Those managed identity objects are all data objects. They do not give you tokens on their own.
mi
object into aManagedIdentityClient
object and then use it:ConfidentialClientApplication
object also accepts the managed identity objectmi
as an input. So you can do:You can choose to do either
1+2
or1+3
.Yes but with a caveat. Because the managed identity is only available on a certain Azure environments (such as Azure VMs, Azure App Service, etc.), and not on your local dev machine, you would have to use normal confidential client during your local testing, and switch to real managed identity on remote server.
MSAL Python makes the transition easy for you. In MSAL Python, all Managed Identity objects have their equivalent JSON representation, for example,
UserAssignedManagedIdentity(client_id="my_id")
is equivalent to{"ManagedIdentityIdType": "ClientId", "Id": "foo"}
. Combining this characteristic and the1+3
above, you could write your app in this universal way.Now you can set these two environment variables on your local dev machine:
and set them differently on your remote server:
Your same app will consume those two sets of settings and behave accordingly.