Azure Secrets Engine | Vault

Dynamic secrets are a core feature in Vault. A class of dynamic secrets is on-demand, revocable, time-limited access credentials for cloud providers. For example, the Dynamic Secrets getting started tutorial demonstrated the AWS secrets engine to dynamically generate AWS credentials (access key ID and secret access key).

»Challenge

To consume Azure services (e.g. Azure Kubernetes service), the client must have valid Azure credentials. Azure uses service principal to authenticate its users. An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. So each new application adds operational overhead as more service principals are required.

»Solution

Automate the process by integrating your applications with Vault's Azure secrets engine. The applications ask Vault for Azure credential with a time-to-live (TTL) enforcing its validity so that the credentials are automatically revoked when they are no longer used.

»Benefits

Each app instance can request unique, short-lived credentials. Unique credentials ensures isolated, auditable access and enable revocation of a single client. While short-lived reduces the time frame in which they are valid.

This tutorial demonstrates the use of azure secrets engine to dynamically generate azure credentials.

»Personas

The end-to-end scenario described in this tutorial involves two personas:

admin with privileged permissions to configure secrets engines
apps read the secrets from Vault

»Prerequisites

This tutorial assumes the following:

You have a Microsoft Azure account
A Vault environment of version 0.11 or later

Online tutorial: An interactive tutorial is also available if you do not wish to install the following resources. Click the Show Terminal button to start.

»Policy requirements

Each persona requires a different set of capabilities. These are expressed in policies. If you are not familiar with policies, complete the policies tutorial.

The admin tasks require these capabilities.

# Mount secrets engines
path "sys/mounts/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# Configure the azure secrets engine and create roles
path "azure/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# Write ACL policies
path "sys/policies/acl/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# Manage tokens for verification
path "auth/token/create" {
  capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}

The apps tasks require these capabilities.

path "azure/creds/edu-app" {
  capabilities = [ "read" ]
}

»Create an Azure service principal and resource group

(Persona: admin)

To delegate the credential generation task to Vault, you need to give Vault privileged Azure credentials to perform the task. The following demonstrates the creation of a service principal.

NOTE: Refer to the online Azure documentation for more details.

Launch the Microsoft Azure Portal and sign in.
Select Azure Active Directory and select Properties.
Copy the Tenant ID.
In a terminal, set the variable TENANT_ID to the Tenant ID.
```
$ TENANT_ID=<Tenant ID>
```
From the side navigation, select App registrations.
Select New registrations.
Enter education in the Name field.
Click Register.
Copy the Application (client) ID.
In a terminal, set the variable CLIENT_ID to the Application (client) ID.
```
$ CLIENT_ID=<Client ID>
```
From the side navigation, select Certificate & secrets.
Under the Client secrets, click New client secret.
Enter a description in the Description field.
Click Add.
Copy the client secret value.
In a terminal, set the variable CLIENT_SECRET to the client secret value.
```
$ CLIENT_SECRET=<Client secret>
```
From the side navigation, click API permissions.
Under Configured permissions, click Add a permission.
Under Supported legacy APIs, click Azure Active Directory Graph.
Click Delegated permissions.
Expand User, select the check-box for User.Read.
Click Application permissions.
Expand Application, select the check-box for Application.ReadWrite.All.
Expand Directory, select the check-box for Directory.ReadWrite.All.
Click API permissions.
Click Grant admin consent for azure to grant the permissions.
Navigate to the Subscriptions blade.
Copy the Subscription ID.
In a terminal, set the variable SUBSCRIPTION_ID to the Subscription ID.
```
$ SUBSCRIPTION_ID=<Subscription ID>
```
Click the name of the subscription.
From the side navigation, click Access control (IAM).
Click Add to expand the menu.
Click Add a role assignment.
Choose Owner from the Role select field.
Choose User, group, or service principal from the Assign Access To select field.
Enter the application name or application id in the Select field.
Click the application when it is displayed.
Click Save.

The application is created with the correct permissions and you have these identifiers and credentials:

Tenant ID
Client ID
Client Secret
Subscription ID

The secrets engine generates credentials within an Azure resource group.

Launch the Microsoft Azure Portal and sign in.
Navigate to Resource groups.
Click Create.
Choose the subscription from the Subscription select field.
Enter vault-education in the Resource group field.
Click Review + create.
The view changes to display the review page.
Click Create.

The resource group vault-education is created.

»Start Vault

In another terminal, start a Vault dev server with root as the root token.

$ vault server -dev -dev-root-token-id root

The Vault dev server defaults to running at 127.0.0.1:8200. The server is initialized and unsealed.

Insecure operation: Do not run a Vault dev server in production. This approach starts a Vault server with an in-memory database and runs in an insecure way.

Export an environment variable for the vault CLI to address the Vault server.

$ export VAULT_ADDR=http://127.0.0.1:8200

Export an environment variable for the vault CLI to authenticate with the Vault server.

$ export VAULT_TOKEN=root

NOTE: For these tasks, you can use Vault's root token. However, it is recommended that root tokens are only used for enough initial setup or in emergencies. As a best practice, use an authentication method or token that meets the policy requirements.

The Vault server is ready.

»Enable the Azure secrets engine

The Azure secrets engine dynamically generates Azure service principals.

Enable the azure secrets engine at its default path.

$ vault secrets enable azure

The secrets engine is enabled at the path azure/. To enable the secrets engine at a different path requires that you use the -path parameter and the desired path.

»Configure the Azure secrets engine

(Persona: admin)

The Azure secrets engine requires the credentials you generated in the create an Azure service principal and resource group step to communicate with Azure and generate service principals.

Verify that your Azure subscription ID is stored in the SUBSCRIPTION_ID environment variable.

$ echo $SUBSCRIPTION_ID

Verify that your client ID is stored in the CLIENT_ID environment variable.

$ echo $CLIENT_ID

Verify that your client secret is stored in the CLIENT_SECRET environment variable.

$ echo $CLIENT_SECRET

Verify that your tenant ID is stored in the TENANT_ID environment variable.

$ echo $TENANT_ID

If any of those variables are missing their value, refer to the previous step and set them before proceeding.

Configure the Azure secrets engine with the Azure credentials.

$ vault write azure/config \
        subscription_id=$SUBSCRIPTION_ID  \
        client_id=$CLIENT_ID \
        client_secret=$CLIENT_SECRET \
        tenant_id=$TENANT_ID

»Create a role

(Persona: admin)

A Vault role lets you configure either an existing service principal or a set of Azure roles.

Create a Vault role named, edu-app mapped to the Azure role named, Contributor in the vault-education resource group.

$ vault write azure/roles/edu-app ttl=1h azure_roles=-<<EOF
    [
      {
        "role_name": "Contributor",
        "scope": "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/vault-education"
      }
    ]
EOF

The role named edu-app is created.

»Request Azure credentials

The role generates credentials with a time-to-live (TTL) of 1 hour and max TTL of 24 hours.

Read credentials from the edu-app azure role.

$ vault read azure/creds/edu-app

Key                Value
---                -----
lease_id           azure/creds/edu-app/AeY3ckPy2pByrVtArNeQQDjn
lease_duration     1h
lease_renewable    true
client_id          408bf248-dd4e-XXXX-XXXX-XXXXXXXXXXXX
client_secret      ad06228a-2db9-XXXX-XXXX-XXXXXXXXXXXX

The results display the credentials, its TTL, and the lease ID.

For applications (apps persona) to request credentials require a Vault policy that grants access to this role.

Define a policy named apps.

$ vault policy write apps - <<EOF
path "azure/creds/edu-app" {
  capabilities = [ "read" ]
}
EOF
Policy 'apps' written.

The apps policy grants the read capability for requests to the path azure/creds/edu-app.

Create a variable named APPS_TOKEN to capture the token created with the apps policy attached.

$ APPS_TOKEN=$(vault token create -policy=apps -field=token)

NOTE: AppRole Pull Authentication tutorial demonstrates a more sophisticated way of generating a token for your apps.

Read credentials from the edu-app azure role with the APPS_TOKEN.

$ VAULT_TOKEN=$APPS_TOKEN vault read azure/creds/edu-app

Key                Value
---                -----
lease_id           azure/creds/edu-app/AeY3ckPy2pByrVtArNeQQDjn
lease_duration     1h
lease_renewable    true
client_id          408bf248-dd4e-XXXX-XXXX-XXXXXXXXXXXX
client_secret      ad06228a-2db9-XXXX-XXXX-XXXXXXXXXXXX

The results display the credentials, its TTL, and the lease ID. The credentials for this application (service principal) in the Azure Portal searching by its client_id.

NOTE: Re-run the command and notice that the role returns a new set of credentials. This means that each app instance acquires a unique set of Azure credentials.

»Manage leases

(Persona: admin)

The credentials are managed by the lease ID and remain valid for the lease duration (TTL) or until revoked. Once revoked the credentials are no longer valid.

List the existing leases.

$ vault list sys/leases/lookup/azure/creds/edu-app

Keys
----
o2F4EA3hU8Fpjgc39XyQpjtU

All valid leases for Azure credentials are displayed.

Create a variable that stores the first lease ID.

$ LEASE_ID=$(vault list -format=json sys/leases/lookup/azure/creds/edu-app | jq -r ".[0]")

Renew the lease for the Azure credential by passing its lease ID.

$ vault lease renew azure/creds/edu-app/$LEASE_ID
Key                Value
---                -----
lease_id           azure/creds/edu-app/o2F4EA3hU8Fpjgc39XyQpjtU
lease_duration     1h
lease_renewable    true

The TTL of the renewed lease is set to 1h.

Revoke the lease without waiting for its expiration.

$ vault lease revoke azure/creds/edu-app/$LEASE_ID
All revocation operations queued successfully!

List the existing leases.

$ vault list sys/leases/lookup/azure/creds/edu-app
No value found at sys/leases/lookup/azure/creds/edu-app/

The lease is no longer valid and is not displayed.

Read new credentials from the edu-app role.

$ vault read azure/creds/edu-app

All leases associated with a path may be removed.

Revoke all the leases with the prefix azure/creds/edu-app.

$ vault lease revoke -prefix azure/creds/edu-app

The prefix flag matches all valid leases with the path prefix of azure/creds/edu-app.

List the existing leases.

$ vault list sys/leases/lookup/azure/creds/edu-app
No value found at sys/leases/lookup/azure/creds/edu-app

All the leases with this path as a prefix have been revoked.

»Clean up

The Azure credentials created to configure the secrets engine should be deleted if they are no longer requried.

Launch the Microsoft Azure Portal and sign in.
Navigate to Azure Active Directory.
From the side navigation, select App registrations.
Click the education application.
From the application overview, click delete.
Select Yes to delete the application.

The application is deleted.

The secrets engine generated credentials within the vault-education Azure resource group. Any credentials that were not revoked should be deleted if they are no longer required.

Launch the Microsoft Azure Portal and sign in.
Navigate to Resource groups.
Click the vault-education resource group.
From the resource group overview, click Delete resource group.
Enter vault-education in the TYPE THE RESOURCE GROUP NAME: field.
Click Delete.

The resource group is deleted.

»Help and Reference

You enabled and configured the Azure secrets engine. Learn more by exploring the documentation or API documentation.

Azure Key Vault can auto-unseal the Vault server. Learn this through this Azure Key Vault Auto-unseal & Dynamic Secrets with HashiCorp Vault demonstation.

Infrastructure

Security

Networking

Applications

»Challenge

»Solution

»Benefits

»Personas

»Prerequisites

»Policy requirements

»Create an Azure service principal and resource group

»Start Vault

»Enable the Azure secrets engine

»Configure the Azure secrets engine

»Create a role

»Request Azure credentials

»Manage leases

»Clean up

»Help and Reference