Access denied after changing key vault

[unkinected]

Hi all, not sure if this is an actual issue or just a "me" thing, so I thought I'd start a discussion first.

This module has been working for us great. Using code like this:

$password = azure_key_vault::secret('mykeyvault', ',mysecret', { vault_api_version => '2016-10-01', metadata_api_version => '2018-04-02', })

The key vault in question was using the old-style access policy (not IAM RBAC), and the Azure managed identity for every VM that needs to pull the secrets was granted get, list secrets. All good.

We recently moved our secrets to a new key vault with IAM RBAC permissions instead of the access policy. Assigned all the same managed identities the Key Vault Secrets User (also tried officer) role but we continue to get the error: "Caller is not authorized to perform action on resource. If role assignments, deny assignments or role definitions were changed recently, please observe propagation time."

Now I know the key vault permissions are correct because from the VM, I can do this and it works:

Connect-AzAccount -identity; Get-AzKeyVaultSecret -VaultName "mykeyvault" -Name "mysecret" -AsPlainText

When I apply a puppet class with this module, it fails with the error above. Seems like somehow this module isn't using the managed identity? The old key vault doesn't have any other assignments that I don't recognize. I've tried restarting the puppet service on the master and the whole master server, disabling/reenabling puppet on the node, restarting the node. The change was made 24 hours ago, so it's not a propagation issue (see my manual Get-AzKeyVaultSecret test).

What am I missing?

[unkinected]

Ok, figured this one out. Turns out the puppet master needs access to the key vault as well, not just the nodes. That didn't immediately make sense to me, but when I dug into the access logs it showed the identity trying to connect to the vault was indeed the puppet master. Added key vault secret user role to that managed identity and all is good now.