The Azure Secrets Engine configuration requires an Azure Active Directory Application ID (
CLIENT_ID) to be specified as detailed in the Azure Secrets Engine documentation and tutorial.
This article elaborates on known limitations where the Azure Secrets Engine uses an Azure application object ID other than what was specified in the configuration, resulting in an
The Azure Secrets Engine uses the incorrect AAD Application Object ID when attempting to create a role instead of the Application (Client) ID specified as part of the
vault write azure/config configuration command.
Prerequisites (if applicable)
- Vault OSS or Vault Enterprise
- Auto-Unseal using Azure Key Vault
- Vault Azure Secrets Engine / Vault Azure Auth Method
The Azure Secrets Engine configuration requires the
tenant_id parameters. These can be provided as parameters to the
vault write azure/config command, or as environment variables.
The Azure Secrets Engine, Azure Auth Method and Azure Key Vault Auto-Unseal components share the ability to read the
client_secret values from the
AZURE_CLIENT_SECRET environment variables if specified.
It's important to note that the values of environment variables take precedence over values specified as part of the Auth method, Secrets engine and Auto-Unseal configuration.
Thus, having an Auto-Unseal configured purely by environment variables (not specified in the
vault.hcl configuration file) would cause any Azure Auth Method and/or Azure Secrets Engine to use the above-mentioned environments variables instead of the values specified as part of their configuration.
This can lead to Azure authorization issues if the registered AAD Applications have been added to separate subscriptions.
Having two AAD applications, each tied to a different subscription. One for the Auto-Unseal method and one for the Secrets Engine:
- App ID = xxxxxxxx-xxxx-xxxx-xxxx-2e7df0604f56
- Object ID = xxxxxxxx-xxxx-xxxx-xxxx-e9511e8b76b4
- Subscription ID = xxxxxxxx-xxxx-xxxx-xxxx-987494fd7c26
- App ID = xxxxxxxx-xxxx-xxxx-xxxx-48567424db65
- Object ID = xxxxxxxx-xxxx-xxxx-xxxx-ebe74221aff4
- Subscription ID = xxxxxxxx-xxxx-xxxx-xxxx-ea68af201f0c
Attempting to add a role results in the following error:
* 1 error occurred: * unable to lookup Azure role: authorization.RoleDefinitionsClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'xxxxxxxx-xxxx-xxxx-xxxx-e9511e8b76b4' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-e9511e8b76b4' does not have authorization to perform action 'Microsoft.Authorization/roleDefinitions/read' over scope '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-ea68af201f0c' or the scope is invalid. If access was recently granted, please refresh your credentials."
Notice that the client, vault-unseal, is not authorized to perform a read action over the subscription scope belonging to the vault-secrets application. Thus showing that all Azure Secrets Engine operations are being done using the vault-unseal AAD application instead of the configured vault-secrets AAD application.
Overview of possible solutions (if applicable)
In order to solve this issue, it's recommended to not use the environment variables:
Instead, specify the
tenant_id parameters as part of the respective Auth method / Secrets engine / Auto-Unseal configuration.
The respective Auth method / Secrets engine / Auto-Unseal mechanism should each be using their respective configured AAD Applications when the above-mentioned environment variables have been removed.
- Vault Tutorial: Azure Secrets Engine
- Vault Documentation: Azure Secrets Engine
- Vault Tutorial: Auto-unseal using Azure Key Vault
- Vault Documentation: Azure Key Vault
- Vault Documentation: Azure Auth Method