f3df55ad58
* Adding check-legacy-links-format workflow * Adding test-link-rewrites workflow * Updating docs-content-check-legacy-links-format hash * Migrating links to new format Co-authored-by: Kendall Strautman <kendallstrautman@gmail.com>
108 lines
5.3 KiB
Plaintext
108 lines
5.3 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Azure Key Vault - Key Management - Secrets Engines
|
|
description: Azure Key Vault is a supported KMS provider of the Key Management secrets engine.
|
|
---
|
|
|
|
# Azure Key Vault
|
|
|
|
The Key Management secrets engine supports lifecycle management of keys in named
|
|
[Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/) instances.
|
|
This is accomplished by configuring a KMS provider resource with the `azurekeyvault`
|
|
provider and other provider-specific parameter values.
|
|
|
|
The following sections describe how to properly configure the secrets engine to enable
|
|
the functionality.
|
|
|
|
## Authentication
|
|
|
|
The Key Management secrets engine must be configured with credentials that have sufficient
|
|
permissions to manage keys in an Azure Key Vault instance. The authentication parameters are
|
|
described in the [credentials](/vault/api-docs/secret/key-management/azurekeyvault#credentials) section
|
|
of the API documentation. The authentication parameters will be set with the following order
|
|
of precedence:
|
|
|
|
1. Environment variables
|
|
2. [KMS provider credentials](/vault/api-docs/secret/key-management/azurekeyvault#credentials)
|
|
3. [Managed Service Identity (MSI)](https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/overview)
|
|
|
|
If the client ID or secret are not provided and Vault is running on an Azure VM, Vault will attempt
|
|
to use MSI to access Azure. Note that when MSI is used, the tenant ID must still be explicitly provided
|
|
by the configuration or environment variable.
|
|
|
|
An Azure Key Vault [access policy](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal)
|
|
determines whether a given service principal, namely an application or user group, can perform certain
|
|
operations on a Key Vault instance. The service principal associated with the provided credentials must
|
|
have an access policy on the Key Vault instance with the following minimum key permissions:
|
|
|
|
- `create`
|
|
- `delete`
|
|
- `get`
|
|
- `import`
|
|
- `update`
|
|
|
|
## Configuration
|
|
|
|
The following is an example of how to configure the KMS provider resource using the Vault CLI:
|
|
|
|
```text
|
|
$ vault write keymgmt/kms/example-kms \
|
|
provider="azurekeyvault" \
|
|
key_collection="keyvault-name" \
|
|
credentials=client_id="a0454cd1-e28e-405e-bc50-7477fa8a00b7" \
|
|
credentials=client_secret="eR%HizuCVEpAKgeaUEx" \
|
|
credentials=tenant_id="cd4bf224-d114-4f96-9bbc-b8f45751c43f"
|
|
```
|
|
|
|
Refer to the Azure Key Vault [API documentation](/vault/api-docs/secret/key-management/azurekeyvault)
|
|
for a detailed description of individual configuration parameters.
|
|
|
|
## Key Transfer Specification
|
|
|
|
Keys are securely transferred from the secrets engine to Azure key vault instances in accordance
|
|
with the Azure [Bring Your Own Key](https://docs.microsoft.com/en-us/azure/key-vault/keys/byok-specification)
|
|
specification.
|
|
|
|
## Key Purpose Compatability
|
|
|
|
The following table defines which key [purposes](/vault/api-docs/secret/key-management#purpose) can be used
|
|
for each key type supported by GCP Cloud KMS.
|
|
|
|
| Key Type | Purpose |
|
|
| -------------- | ------------------------------------------------------- |
|
|
| `rsa-2048` | [All purposes](/vault/api-docs/secret/key-management#purpose) |
|
|
| `rsa-3072` | [All purposes](/vault/api-docs/secret/key-management#purpose) |
|
|
| `rsa-4096` | [All purposes](/vault/api-docs/secret/key-management#purpose) |
|
|
|
|
## Azure Private Link
|
|
|
|
The secrets engine can be configured to communicate with Azure Key Vault instances
|
|
using [Azure Private Endpoints](https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview).
|
|
Follow the guide at [Integrate Key Vault with Azure Private Link](https://docs.microsoft.com/en-us/azure/key-vault/general/private-link-service?tabs=portal)
|
|
to set up a Private Endpoint for your target Key Vault instance in Azure. The Private Endpoint must
|
|
be network reachable by Vault. This means Vault needs to be running in the same virtual network or
|
|
a peered virtual network to properly resolve the Key Vault domain name to the Private Endpoint IP
|
|
address.
|
|
|
|
The Private Endpoint configuration relies on a correct [Azure Private DNS](https://docs.microsoft.com/en-us/azure/dns/private-dns-overview)
|
|
integration. From the host that Vault is running on, follow the steps in
|
|
[Validate that the private link connection works](https://docs.microsoft.com/en-us/azure/key-vault/general/private-link-service?tabs=portal#validate-that-the-private-link-connection-works)
|
|
to ensure that the Key Vault domain name resolves to the Private Endpoint IP address you've configured.
|
|
|
|
```
|
|
$ nslookup <keyvault-name>.vault.azure.net
|
|
|
|
Non-authoritative answer:
|
|
Name:
|
|
Address: 10.0.2.5 (private IP address)
|
|
Aliases: <keyvault-name>.vault.azure.net
|
|
<keyvault-name>.privatelink.vaultcore.azure.net
|
|
```
|
|
|
|
The secrets engine doesn't require special configuration to communicate with a Key Vault instance
|
|
over an Azure Private Endpoint. For example, the given [KMS configuration](/vault/docs/secrets/key-management/azurekeyvault#configuration)
|
|
will result in the secrets engine resolving a Key Vault domain name of `keyvault-name.vault.azure.net`
|
|
to the Private Endpoint IP address. Note that it's possible to change the Key Vault DNS suffix using the
|
|
[environment](/vault/api-docs/secret/key-management/azurekeyvault#environment)
|
|
configuration parameter or `AZURE_ENVIRONMENT` environment variable.
|