Replace App Registration secrets with Managed Identity + Federated Credentials

[nsftwr]

Overview

This change removes the creation and use of secrets for the engine app registration and instead uses the existing managed identity to establish a federated credential relationship with the app registration. This aligns with best practices, where secrets are discouraged and should only be used when no other option is available.

The implementation continues to rely on the existing functions, so it does not require significant changes to the main codebase.

When the user is an admin, the flow uses ClientAssertionCredential to authenticate against the app registration.
When the user is a non-admin, it uses OnBehalfOfCredential. In this case, client_assertion_func is used instead of a client secret, alongside user_assertion, to preserve the on-behalf-of flow.

Additional Details

• Removed get_obo_token as it was not being used
• Updated the azure-mgmt-resource-subscriptions==1.1.0 requirement to look at 1.0.0b1 as 1.1.0 does not seem to exist: https://pypi.org/project/azure-mgmt-resource-subscriptions/

Testing Conducted

To verify that the correct auth method was used, additional logging was added temporarily. This was then verified by 2 users - an admin user and a non admin.

Admin user:

Non-admin user:

[DCMattyG]

Hi @nsftwr, and thank you so much for your interest in improving Azure IPAM for everyone!

This topic has been discussed before in #353 and the issue I keep coming back to is that not everyone deployed Azure IPAM in Azure. It could be deployed anywhere like another cloud provider, on-premises, on a laptop....and using this method seems to rule out non-Azure deployments.

I'll be honest that it's been a while since I've spent the appropriate amount of brain cycles on the exact topic, but if you understand things different, please do let me know and I'll be happy to re-evaluate this option.

[nsftwr]

Thank you for the speedy response @DCMattyG! I've read the conversation, and immediately the first thought was

If it could be running locally, why does Cosmos have Managed Identity Credentials?

Then i remembered that globals.COSMOS_KEY is optional. Could we apply the same to this? Have a similar [Switch] parameter that one can specify if they want to be secret-less. Default to the current approach that is set, but if -UseFederatedCredentials is passed then use the approach I've described in this PR.

---

Edit: App registration creds are still honoured as its using ClientAssertionCredential with the App Reg Clientid, the same for OBO creds - as its using OnBehalfOfCredential() with user_assertion + client_assertion_func

[DCMattyG]

I'm open to making it work similarly to Cosmos. Effectively, the deployment script is specific to Azure, so when deploying with the script it could use the Federated Credentials. I don't see a point in adding a switch since the script only targets Azure deployments. We'd definitely need to add the fallback capability to use the Client Secret which, as you pointed out, we can simply do by the presence of the value similarly to Cosmos does it today.

I'll be focusing on getting v4.0.0 out the door and we'll need to rebase this on that since there are a massive number of changes, but perhaps we can tackle this together next.

[nsftwr]

Rebasing and working on top of your changes now or upcoming isn’t an issue whatsoever. I would be very interested what’s required for you to either combine this with v4, or have it released as a minor version very soon after. I’m aiming to migrate to Azure IPAM relatively soon as per something I’m working on, and would love to have the ability to not deal with secrets.

I can have the functionality that looks for the secret’s existence done by tomorrow. Would it be of interest to set up a call some point the next two weeks to discuss any outstanding work on v4, as I am happy to contribute to a great project.

[nsftwr]

Hi @DCMattyG, I have added and tested my changes for having the ability to use either secret, or FIC. in both scenarios it works as expected, and no different than the cosmos credential logic.

As I have built this branch on top of your ipam-3.7.0 branch, there arent any rebases required when compared to your v4.0.0 pull request. And this PR proposes to merge my changes into your v4.0.0 pull request. Based on the fact that there arent a lot of code changes for this implementation, could I ask you to reevaluate and see if we can merge this PR into your v4.0.0 PR so FIC ability gets bundled with v4.0.0?

As mentioned, glad to assist in any other outstanding work, as well as with any testing that needs to be conducted.