Eu tentei implementar esse recurso de conta de armazenamento gerenciado de cofre de chaves bastante novo e encontrei este guia: link
O guia está funcionando como esperado e recebi minha conta de armazenamento gerenciada pelo cofre da chave. Meu problema aqui é que, idealmente, eu quero executar esse script como uma entidade de serviço em uma tarefa agendada para que cada conta de armazenamento que será criada seja configurada adequadamente com a rotação automatizada de chaves. Assim que eu tentar executar as etapas fornecidas no guia com uma entidade de serviço do Azure, o comando Add-AzureKeyVaultManagedStorageAccount será interrompido com um erro HTTP proibido no cofre da chave. O diretor de serviços tem exatamente os mesmos direitos que meu próprio usuário.
No guia acima, encontrei a seguinte seção:
Example: As a Key Vault object owner you add a storage account object to your Azure Key Vault to onboard a storage account.
During onboarding, Key Vault needs to verify that the identity of the onboarding account has permissions to list and to regenerate storage keys. In order to verify these permissions, Key Vault gets an OBO (On Behalf Of) token from the authentication service, audience set to Azure Resource Manager, and makes a list key call to the Azure Storage service. If the list call fails, the Key Vault object creation fails with an HTTP status code of Forbidden. The keys listed in this fashion are cached with your key vault entity storage.
Key Vault must verify that the identity has regenerate permissions before it can take ownership of regenerating your keys. To verify that the identity, via OBO token, as well as the Key Vault first party identity has these permissions:
Key Vault lists RBAC permissions on the storage account resource. Key Vault validates the response via regular expression matching of actions and non-actions. Find some supporting examples at Key Vault - Managed Storage Account Keys Samples.
If the identity does not have regenerate permissions or if Key Vault's first party identity doesn’t have list or regenerate permission, then the onboarding request fails returning an appropriate error code and message.
The OBO token will only work when you use first-party, native client applications of either PowerShell or CLI.
Tanto quanto eu posso entender esta seção, não é possível fazer isso com um serviço principal, porque o principal não é capaz de obter o token OBO. Para obter esse token, eu precisaria de uma entidade de serviço do tipo 'native'. Mas esse tipo de entidade de serviço tem a desvantagem de precisar fazer login interativamente em minha conta do Azure.
Esta operação pode ser executada com um diretor de serviço?