How to create MS graph objects in azure-dev workflow?

[pamelafox]

I have a template that uses az with pre and post hooks in order to create an Application Registration using the MS Graph API. You can see the code involved in this PR:
https://github.com/pamelafox/sample-app-aoai-chatGPT/pull/1/files

I am now trying to get CI/CD working for this repo, but am struggling with permissions. When I run the pipeline, I get this error:

{'error': {'code': 'Authorization_RequestDenied', 'message': 'Insufficient privileges to complete the operation.', 'innerError': {'date': '2023-06-16T17:24:17', 'request-id': '07776e1d-5937-47b5-9eaa-14a8624afdd2', 'client-request-id': '07776e1d-5937-47b5-9eaa-14a8624afdd2'}}}

This is because the azd principal running on CI/CD does not have sufficient permissions to create an application registration. Is it possible to give that principal permissions? Do you have a recommendation for how to get this workflow to work?

I am hoping for this repo to be compatible with App Spaces in the Azure Portal, so ideally everything could be done over CI/CD.

[vhvb1989]

When running azd pipeline config you can set the role to be assigned to the SP with --principal-role.

Before azd 1.0.0, azd was adding Contributor role by default when creating a SP.
After azd 1.0.0, azd adds Contributor + User Access Administrator roles.

If you run azd pipeline config and set your SP before 1.0.0, you can either update its roles running

azd pipeline config --principal-name you-sp-name

or, you can also just create a new SP and let azd to update your scm repo with

azd pipeline config

If you need more permission for the SP (like making the SP powerful enough to create other SP and assign roles to it), you might need to give Owner role to that SP, like

azd pipeline config --principal-role owner

Adding too much power to a SP is usually not recommended, specially for an entire subscription. Consider if you can make the workflow to depend on setting the SP, instead of making the workflow to create it

[pamelafox]

Sorry if I get a little confused while tackling this, service principals are still a bit fuzzy for me. I attempted the suggestion of using --principal-role owner. However, that still results in Insufficient priveleges. (See run at https://github.com/pamelafox/sample-app-aoai-chatGPT/actions/runs/5340083949/jobs/9679475365 )

You say "Consider if you can make the workflow to depend on setting the SP, instead of making the workflow to create it". Can you clarify if that means I should try to get principal-role working? Or if I should do it some other way?

[vhvb1989]

Can you clarify

Sure. What I meant is that you can expect the gh-workflow to already have been provided with a clientId, tenant and secret. So, you won't depend on the preprovision hook that creates the SP that is later used by the postprovision hook. The auth_init.sh would use a SP that was previously created by a human and set it as gh-secret (on gh-workflow) or within azd-env. (in summary, let he SP creation to be a human-manual task).

But, on the other hand, I reviewed the code from auth_init.py and auth_update.py and found a few details:

• auth_init is creating an app-registration instead of a Service principal. It is calling v1/applications here instead of v1/servicePrincipals. The application won't work here. You need this api .

• After creating the SP, you need to create a role-assignment for that SP within the subscription. Here is where you need the SP-with-owner role to assign a role for the SP that it created. You need this api for this. It looks like there is this python-sdk-client you can use to create the role-assignments

• It looks like there's also this ServicePrincipalsOperations python client which you might want to try. As it looks to me, it might be the client used by the az cli to create SP+add-role, as I would expect az cli uses python-sdk-clients :). You might want to try using this.

• If I understand correctly, you are trying to enable one app-registration as a login method and set it up in a way to produce the auth-token for your requests. This approach would only work for Tenants where you are admin (won't work on msft tenant), as you need to either make the app-registration a first party app or define the list of scopes for the app and give admin-consent to the app for accessing those scopes on behalf of a user. However, we don't need this scenario here, as there we are not expecting some application to log in a human-user and act on his/her behalf. What we want is a SP which is not related to any human-user, instead, it is like a faceless account within the directory (that's why it is created on Microsoft graph and not from Azure Portal). After the SP is created on ms-graph, Azure automatically creates the app-registration which acts on behalf of the SP. That's how the SP can be added to multiple directories. Each directory would contain an app-registration for that SP.