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.

As the number of applications required to access Azure resources, it adds operational overhead to manage those service principals generated for each application.

»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 get unique credentials that they don't have to share. By making those credentials to be short-lived, you reduced the chance of the Azure credentials from being compromised. If an app was compromised, the credentials used by the app can be revoked rather than changing a more global set of credentials.

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

»Policy requirements

NOTE: For the purpose of this tutorial, you can use root token to work with Vault. However, it is recommended that root tokens are only used for just enough initial setup or in emergencies. As a best practice, use tokens with appropriate set of policies based on your role in the organization.

To perform all tasks demonstrated in this tutorial, your policy must include the following permissions:

# 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" ]
}

If you are not familiar with policies, complete the policies tutorial.

»Step 1: Create an Azure Service Principal

(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 and store the Directory ID which is your tenant ID for later use.
Now, select App registrations.
Select New registrations.
Enter your desired application name in the Name text field, and then click Register.
Copy and store the generated Application (client) ID for later use.
Select Certificate & secrets.
Click New client secret under the Client secrets. When prompted, enter some description and then click Add.
Copy and store the generated secret value which is your client secret.
Click API permissions and Add a permission.
Select Azure Active Directory Graph under the Supported legacy APIs section.
Click Delegated permissions, expand User and then select the check-box for User.Read.
Click Application permissions, expand Application and Directory.
Select the check-box for Application.ReadWrite.All and Directory.ReadWrite.All.
Click API permissions.
Click Grant admin consent for azure to grant the permissions.
Navigate to the Subscriptions service blade. Copy and store the SUBSCRIPTION ID for later use.
Now, click into your Subscription name.
Click Access control (IAM) and click Add under the Add a role assignment.
Select Owner under Role, and the Assign Access To Field should be Azure ID, User Group, or Service Principal. In the Select field, enter your application name, or Application (client) ID saved in a previous step to discover the application you created.
Click Save.

NOTE: To create a new service principal using the Azure PowerShell, refer to the Azure documentation. To perform these tasks using the az ad sp command-line tool, refer to the Azure CLI documentation.

»Step 2: Enable the Azure secrets engine

First step is to enable the azure secrets engine at a desired path.

Execute the following command to enable the azure secrets engine at azure/ path.

$ vault secrets enable azure

If you want to enable the secrets engine at a different path, use the -path parameter to specify your desired path. Otherwise, the secrets engine gets enabled at a path named after its type. Since the type is azure in this example, its path becomes azure in absence of -path parameter.

»Step 3: Configure the Azure secrets engine

(Persona: admin)

To configure the Azure secrets engine, be sure that you have the following information you collected in Step 1 ready:

Tenant ID (or Directory ID)
Client ID
Client Secrets
Subscription ID

Execute the following command to configure the Azure secrets engine to use the service principal you created.

$ vault write azure/config subscription_id=<Subscription_ID>  \
        client_id=<Client_ID> client_secret=<Client_Secret> \
        tenant_id=<Tenant_ID>

»Step 3: Create a role

(Persona: admin)

The next step is to define what type of service principal you want Vault to generate. Vault roles let you configure either an existing service principal or a set of Azure roles.

In this example, you have already created a Resource Group in Azure named vault-education and will use it when creating our role.

Execute the following command to create a role named, edu-app with Contributor role on the vault-education resource group. Set the TTL to be 1 hour and the max TTL to be 24 hours.

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

Be sure to replace the <Subscription_ID> with your Subscription ID copied in Step 1.

»Step 4: Request Azure credentials

(Persona: apps)

Now, you are switching to apps persona. To get a new set of Azure credentials, the client applications need to be able to read from the edu-app role endpoint. Therefore the app's token must have a policy granting the read permission.

Create a new file called apps-policy.hcl.

$ tee apps-policy.hcl <<EOF
# Get credentials from the azure secrets engine
path "azure/creds/edu-app" {
  capabilities = [ "read" ]
}
EOF

First create an apps policy, and generate a token so that you can authenticate as an apps persona.

Example:

Create a policy named apps.

$ vault policy write apps apps-policy.hcl
Policy 'apps' written.

Create a new token with apps policy attached.

$ vault token create -policy=apps

Key                  Value
---                  -----
token                s.dVZocexPgYSuMOUYb5xepG7O
token_accessor       ki48gCn3m8TMzAju3Dd8Er4m
token_duration       768h
token_renewable      true
token_policies       ["apps" "default"]
identity_policies    []
policies             ["apps" "default"]

Use the returned token to perform the remaining.

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

$ VAULT_TOKEN=s.dVZocexPgYSuMOUYb5xepG7O 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

You should be able to discover the application (service principal) in the Azure Portal searching by its client_id.

NOTE: Re-run the command and notice that Vault returns a different set of credentials each time. This means that each app instance can acquire a unique set of Azure credentials.

»Step 5: Revoke the Azure credentials

(Persona: admin)

The generated Azure credentials get automatically revoked by the Vault server after 1 hour of its creation and not being renewed. If you need to revoke the credentials before reaching its TTL, you can do so by invoking the revoke operation.

Execute the following command to revoke the generated Azure credentials before reaching its TTL.

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

While azure/creds/edu-app/SPfKsENQ7smTRQxuVhUb3Dfb is the lease_id associated with the generated Azure credentials.

Alternatively, you can revoke all edu-app credentials by executing the following command:

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

Infrastructure

Security

Networking

Applications

»Challenge

»Solution

»Benefits

»Personas

»Prerequisites

»Policy requirements

»Step 1: Create an Azure Service Principal

»Step 2: Enable the Azure secrets engine

»Step 3: Configure the Azure secrets engine

»Step 3: Create a role

»Step 4: Request Azure credentials

»Step 5: Revoke the Azure credentials

»Help and Reference