Azure
Last updated
Last updated
Dynamic secrets are a core feature in Vault. A class of dynamic secrets is on-demand, revocable, time-limited access credentials for cloud providers.
To consume Azure services (e.g. Azure Kubernetes service), the client must have valid Azure credentials. Azure uses 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.
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.
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.
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
This tutorial assumes the following:
You have a Microsoft Azure account
Vault installed
Each persona requires a different set of capabilities. These are expressed in policies.
Open a new terminal window and start a Vault dev server with root
as the root token.
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 an environment variable for the vault
CLI to authenticate with the Vault server.
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.
(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.
Production
The service principal should be dedicated to the Vault secrets engine.
Invoking the rotate-root
command will delete the existing client secret and generate a new secret known only to Vault.
Note
Select Azure Active Directory and select Properties.
Copy the Tenant ID.
In a terminal, set the variable TENANT_ID
to the Tenant ID.
From the side navigation, select App registrations.
Select New registrations.
Enter a desired name in the Name field (e.g. vault-education
).
Click Register.
Copy the Application (client) ID.
In a terminal, set the variable CLIENT_ID
to the Application (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.
From the side navigation, click API permissions.
Under Configured permissions, click Add a permission.
The Azure Secrets Engine documentation lists the Azure permissions need to be assigned.
Click Microsoft Graph.
Select Application permissions.
Add the following permissions.
Application.ReadWrite.OwnedBy
Application
GroupMember.ReadWrite.All
Application
Click Add permissions.
Click Grant admin consent for azure to grant the permissions.
Click Yes to confirm consent.
Click the name of your subscription.
Copy the Subscription ID.
In a terminal, set the variable SUBSCRIPTION_ID
to the Subscription ID.
From the side navigation, click Access control (IAM).
Click Add > Add a role assignment.
Select User Access Administrator
and click Next.
Click Select members.
Enter your application name or application id in the Select field.
Click the application when it is displayed which will add the application to the Selected members list.
Click Select.
Click Review + assign, and then Review + assign gain.
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.
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.
With the necessary resources configured in Azure, you can configure the Azure secrets engine to dynamically generate Azure service principals.
Enable the azure secrets engine at its default path.
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.
(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, client ID, client ID, and tenant ID are stored as environment variables.
Configure the Azure secrets engine with the Azure credentials.
(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.
The role named edu-app
is created.
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.
Example output:
The results display the credentials, its TTL, and the lease ID.
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.
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
.
Example output:
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.
(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.
Example output:
All valid leases for Azure credentials are displayed.
Create a variable that stores the first lease ID.
If you need to extend the use of the generated Azure credentials, you can renew the lease by passing its lease ID.
Example output:
The TTL of the renewed lease is set to 1h
.
When the Azure credentials are no longer needed, you can revoke the lease without waiting for its expiration.
Revoke the least associated with the $LEASE_ID environment variable.
List the existing leases.
The first lease is no longer valid.
Read new credentials from the edu-app
role.
Revoke all the leases with the 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.
All the leases with this path as a prefix have been revoked.
The Azure credentials created to configure the secrets engine should be deleted if they are no longer required.
From the side navigation, select App registrations.
Click the vault-education application (or whatever the name you set for the application).
From the application overview, click delete.
Select Yes to delete the application. The application is deleted.
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.
Unset the VAULT_TOKEN
environment variable.
Unset the VAULT_ADDR
environment variable.
If you are running Vault locally in dev
mode, stop the Vault dev server by pressing Ctrl+C where the server is running. Or, execute the following command.
Refer to the for more details.
Launch the and sign in.
Navigate to the blade.
Navigate to the blade.
Additional may be provided to configure the secrets engine. The path as well may be modified to support your needs.
If any of those variables are missing their value, refer to the and set them before proceeding.
For applications () to request credentials, it requires a Vault policy that grants access to this role. Define a policy named apps
.
Note: This example uses to process the JSON output for readability.
Launch the and sign in.
Navigate to .
Navigate to .