General API only security

[clittlejohn366]

Hi all, this is a pretty awesome tool, instructions are spot on for deployment and management. Had a great time learning this stuff.

Had a couple of questions around general security of the app being deployed as a function only:

1. We are deploying as a function app only, is that app registration permission required? Is there a way to reduce this without affecting the functionality?
2. For the CosmosDB and Function in general, are there any ways to limit permissions to them?
3. Looks like it uses the token of the user that logs in when you do connect-azaccount

Thank you in advance!

[DCMattyG]

Hi @clittlejohn366, allow me to touch on each of your points...

1. We've done some pretty extensive testing to make sure that we are using the absolute LEAST amount of API permissions possible, while allowing the tool to do what it needs to do. If there's a specific permission that you are concerned about, please let me know and I'll get you a detailed reason why that permission is necessary right away. The IPAM Engine uses an on-behalf-of flow for authentication, which essentially means it takes a user token and calls the Azure SDK on your behalf, which binds it to whatever permissions you already have inside Azure.
2. What kind of restrictions are you looking for here? We use a separate (small) Cosmos DB instance which is dedicate to the IPAM deployment, and by default nothing else has permission to access it.
3. Yes, please see above (number 1), this tool uses existing Azure permissions. We do not, in any way attempt to re-create our own AuthN/AuthZ scheme, we're simply leveraging the Microsoft MSAL authentication library.

Please let me know if any of the above wasn't clear, or if you'd like me to expound further on any of my provided answers.

Thank you so much for your feedback, and we hope you love using Azure IPAM. We're always here for anything you need, please don't hesitate to ask!

[colemanjrNIH]

Thanks for the quick answers,
I'm working with @clittlejohn366 to deploy the IPAM Function in our environment.
Our team are not GAs, but were able to create the App registration and user_impersonation API permission without requiring Admin Consent. We are doing a Function only deployment, so we won't need the UI App registration and its API permissions. We were considering it, but our use case is just for automated CIDR assignments.
The permissions we were looking to changes are related to the subscription level RBAC assignments for the managed identity. We have deployed the resources with the RBAC assignments scoped to a Resource Group. The subscription contains resources that we want to keep separate from the managed identity. I don't think this will impact anything for a Function only deployment. I might be reading the bicep templates wrong regarding the default scope, I've only worked with bicep a few times. I also reduced engine service principal Reader assignment to a Management group scope instead of a tenant scope.
I'll let you know if we hit any snags with the changed RBAC scopes.

[colemanjrNIH]

Yep, it looks like reducing the Service Principal scope is causing an issue with the resource graph queries. The deploy.ps1 grants tenant level Reader to the Service Principal. Our uses case would only have a specific management group being tracked by the IPAM function.
I'll keep working at this.

[DCMattyG]

Sounds good @colemanjrNIH. If at any point you'd like to chat about this live with me, I'm more than happy to make the time for you. Just send a quick email to [email protected] and we'll fine a time slot.

[colemanjrNIH]

Fixed the issue without any changes to the IPAM Function. Assigned the Service Principal reader to the resource group with the IPAM resources in it as well. The IPAM Function is deployed in our "admin" MG while it is being used to manage a different MG.

I saw that the scope was commented out in the query request, so it should work for whatever the service principal has access to. Looks like it just needed that Reader assignment to the IPAM resources also.
Our team deployed most of the IPAM resources with Terraform instead of bicep, so lots of room for mistakes in the translation. Terraform handles App Settings in a "special way" so we still used bicep to deploy the Function App resource.

        query_request = QueryRequest(
            query=query,
            # management_groups=[globals.TENANT_ID],
            options=QueryRequestOptions(
                result_format=ResultFormat.object_array,
                skip_token=skip_token
            )
        )