GetCertificates_Orchestrator failing with permission error

[jamie-at-arkifi]

Orchestrator function 'GetCertificates_Orchestrator' failed: The activity function 'GetAllCertificates' failed: "The user, group or application 'appid=f59c2a06-de67-4f10-b2c3-d55694d6c223;oid=328c6e3b-e843-469e-bc5a-4f82223f1d53;iss=https://sts.windows.net/78bd38a8-9440-4305-9e30-9678cd7cb245/' does not have certificates list permission on key vault 'acme-keyvaultbdc8245;location=eastus2'. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287

So I will say: I wrote my own Pulumi code (based on the teraform code), and I'm assuming I did something wrong. But the portal is showing that the application has complete access, as does my user.

The weird thing is that I have no idea what the appid is. The tenant matches, and the oid is the app's service principal, but appid is a mystery.

EDIT: I can confirm the app also got the Key Vault Certificates Officer role, so it should be authorized twice!

[shibayan]

Have you set up an access policy or RBAC for Key Vault certificates? The part in the Bicep template below, Key Vault Certificates Officer is required for RBAC.

https://github.com/shibayan/keyvault-acmebot/blob/master/azuredeploy.bicep#L181-L189

[jamie-at-arkifi]

Yup, I added the service principal to the Key Vault Certificates Officer role, and I can confirm it in the portal. The user logging in is Global Administrator.

[jamie-at-arkifi]

I did miss the enable_rbac_authorization flag, but adding it didn't resolve the issue.

[jamie-at-arkifi]

I also just deleted and recreated everything, and it didn't change anything.

[jamie-at-arkifi]

Ok, I did find that while the Service Principal has an assigned role, the Function App (as a managed identity) does not. Looking at it in the portal, I'm seeing errors about needing an Entra P2 license. It's not clear from the price/feature page, though, why I would.

[jamie-at-arkifi]

Ok, yes, this is it.

I only spotted it because of differences between the teraform and bicep code in the way they handle role assignment.

[jamie-at-arkifi]

Ok, so to give more detail:

The teraform code creates an app registration and a service principal, and then gives roles to the service principal.

The bicep code assigns roles to the function's implicit service principal.

I followed the teraform code because I'm using pulumi-azure, which is a wrapper around the teraform module.

But only the bicep method actually works, and doesn't have any of the app and auth framing of the teraform code.

[jkunkee]

I ran into this in a different context--I'm still a newbie, so I'm doing things by hand after using the "deploy to Azure" button on the Github homepage to deploy. In my case, there were two(!) identically named Principals in the Access Policies GUI, and I had to use the one that wasn't convenient to scroll to--now I wonder if it's the same dichotomy as what you hit.

(Thanks for the suggestion to look for a second principal!)

[jamie-at-arkifi]

Ok, giving the service principal a more-privileged role didn't fix it, so I think either the wrong thing has the role (possibly like above), or I've misconfigured the application about how to access its role somehow.