Vault
HomeDocumentationTutorialsTry Cloud!
  • Vault
  • Documentation
    • What is Vault?
    • Use Cases
    • Setup
      • Install
      • Configuration
    • Get Started
      • Starting the server
      • Your first secret
      • Deploying Vault on VMs with Let's encrypt! TLS certs
    • Concepts
      • Operations
        • Seal/Unseal
        • "Dev" server mode
        • Namespace lock and unlock
        • Lease, renew, and revoke
        • Lease Explosions
        • Mount migration
        • Client count
        • Resource quotas
        • Response wrapping
      • Authentication
        • Identity
        • Tokens
        • OIDC provider
        • Username templating
        • Passwordless
      • Secrets
      • Storage
        • Integrated storage
        • High availability mode (HA)
        • Recovery mode
      • Policies
  • Tutorials
    • CLI
      • Operations
        • Deploy Vault
        • Using the HTTP API
        • Unseal/Seal
      • Authentication
        • Token
        • GitHub authentication
        • Username/Password
        • TLS Client Certificates
        • SSH Keys
        • AWS, Azure, GCP and external auth methods
          • Azure
          • AWS
          • GCP
          • Github
          • Terraform
      • Secrets
        • Secrets engines
        • Built-in help
      • Access Control
        • Policies
    • UI
      • Authentication
        • Username/Password
        • Passwordless
      • Operations
        • Unseal / Seal
        • API Explorer
      • Secrets
        • Secrets engines
      • Access Control
        • Policies
    • Use Cases
      • Namespaces
      • MongoDB admin password
      • VM Disk Encryption Keys
      • VM SSH Keys
      • Kubernetes Configuration
      • GitHub Actions
      • Dynamic credentials for cloud providers
        • AWS
        • Azure
        • GCP
  • CLI
    • agent
    • audit
    • auth
    • debug
    • delete
    • events
    • kv
    • lease
    • license
    • list
    • login
    • monitor
    • namespace
    • operator
    • patch
    • path-help
    • pki
    • plugin
    • policy
    • print
    • proxy
    • read
    • secrets
    • server
    • ssh
    • status
    • token
    • transit
    • unwrap
    • version
    • version-history
    • write
  • API
    • Secrets engines
      • AliCloud secrets engine (API)
      • AWS secrets engine (API)
      • Azure secrets engine (API)
      • Cubbyhole secrets engine (API)
      • Database
        • Cassandra database plugin HTTP API
        • Elasticsearch database plugin HTTP API
        • Influxdb database plugin HTTP API
        • MongoDB database plugin HTTP API
        • MSSQL database plugin HTTP API
        • MySQL/MariaDB database plugin HTTP API
        • Oracle database plugin HTTP API
        • PostgreSQL database plugin HTTP API
        • Redis database plugin HTTP API
        • Redis ElastiCache database plugin HTTP API
        • Redshift database plugin HTTP API
        • Snowflake database plugin HTTP API
      • Google Cloud secrets engine (API)
      • Google Cloud KMS secrets engine (API)
      • Identity
        • entity
        • entity-alias
        • group
        • group-alias
        • tokens
        • lookup
        • oidc-provider
        • MFA
          • duo
          • okta
          • pingid
          • totp
          • login-enforcement
      • KV secrets engine (API)
      • Buckypaper secrets engine
      • Kubernetes secrets engine (API)
      • Nomad secrets engine (API)
      • LDAP secrets engine (API)
      • PKI secrets engine (API)
      • RabbitMQ secrets engine (API)
      • SSH secrets engine (API)
      • TOTP secrets engine (API)
      • Transit secrets engine (API)
    • Auth engines
      • AliCloud auth method (API)
      • AppRole auth method (API)
      • AWS auth method (API)
      • Azure auth method (API)
      • Pivotal Cloud Foundry (CF) auth method (API)
      • GitHub auth method (API)
      • Google Cloud auth method (API)
      • JWT/OIDC auth method (API)
      • Kerberos auth method (API)
      • Kubernetes auth method (API)
      • LDAP auth method (API)
      • OCI auth method (API)
      • Okta auth method (API)
      • Passwordless auth method (API)
      • RADIUS auth method (API)
      • TLS certificate auth method (API)
      • Token auth method (API)
      • Userpass auth method (HTTP API)
    • Service engines
      • Licence Manager
    • System backend
      • /sys/audit
      • /sys/audit-hash
      • /sys/auth
      • /sys/capabilities
      • /sys/capabilities-accessor
      • /sys/capabilities-self
      • /sys/config/auditing/request-headers
      • /sys/config/control-group
      • /sys/config/cors
      • /sys/config/reload
      • /sys/config/state
      • /sys/config/ui
      • /sys/decode-token
      • /sys/experiments
      • /sys/generate-recovery-token
      • /sys/generate-root
      • /sys/health
      • /sys/host-info
      • /sys/in-flight-req
      • /sys/init
      • /sys/internal/counters
      • /sys/internal/inspect
        • /sys/internal/inspect/router
      • /sys/internal/specs/openapi
      • /sys/internal/ui/feature-flags
      • /sys/internal/ui/mounts
      • /sys/internal/ui/namespaces
      • /sys/internal/ui/resultant-acl
      • /sys/key-status
      • /sys/ha-status
      • /sys/leader
      • /sys/leases
      • /sys/license/status
      • /sys/locked-users
      • /sys/loggers
      • /sys/metrics
      • /sys/monitor
      • /sys/mounts
      • /sys/namespaces
      • /sys/plugins/reload/backend
      • /sys/plugins/catalog
      • /sys/plugins/runtimes/catalog
      • /sys/policy
      • /sys/policies/
      • /sys/policies/password/
      • /sys/pprof
      • /sys/quotas/config
      • /sys/quotas/rate-limit
      • /sys/quotas/lease-count
      • /sys/raw
      • /sys/rekey
      • /sys/rekey-recovery-key
      • /sys/remount
      • /sys/rotate
      • /sys/rotate/config
      • /sys/seal
      • /sys/seal-status
      • /sys/seal-backend-status
      • /sys/step-down
      • /sys/storage
        • /sys/storage/raft
        • /sys/storage/raft/autopilot
      • /sys/tools
      • /sys/unseal
      • /sys/version-history
      • /sys/wrapping/lookup
      • /sys/wrapping/rewrap
      • /sys/wrapping/unwrap
      • /sys/wrapping/wrap
  • Resources
    • Blog
    • GitHub
    • Youtube
    • CCx101
Powered by GitBook
On this page
  • Challenge
  • Solution
  • Personas
  • Prerequisites
  • Lab setup
  • Create an Azure service principal and resource group
  • Configure Vault
  • Request Azure credentials
  • Manage leases
  • Clean up
  1. Tutorials
  2. Use Cases
  3. Dynamic credentials for cloud providers

Azure

PreviousAWSNextGCP

Last updated 1 year ago

Dynamic secrets are a core feature in Vault. A class of dynamic secrets is on-demand, revocable, time-limited access credentials for cloud providers.

Challenge

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.

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

  • Vault installed

Policy requirements

Each persona requires a different set of capabilities. These are expressed in policies.

Lab setup

  1. Open a new terminal window and 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.

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

$ export VAULT_ADDR=http://127.0.0.1:8200
  1. Export an environment variable for the vault CLI to authenticate with the Vault server.

$ export VAULT_TOKEN=root

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.

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.

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

  1. Select Azure Active Directory and select Properties.

  1. Copy the Tenant ID.

  1. In a terminal, set the variable TENANT_ID to the Tenant ID.

$ export TENANT_ID=<Tenant ID>
  1. From the side navigation, select App registrations.

  1. Select New registrations.

  1. Enter a desired name in the Name field (e.g. vault-education).

  2. Click Register.

  3. Copy the Application (client) ID.

  1. In a terminal, set the variable CLIENT_ID to the Application (client) ID.

$ export CLIENT_ID=<Client ID>
  1. From the side navigation, select Certificate & secrets.

  2. Under the Client secrets, click New client secret.

  3. Enter a description in the Description field.

  1. Click Add.

  2. Copy the client secret value.

  1. In a terminal, set the variable CLIENT_SECRET to the client secret value.

$ export CLIENT_SECRET=<Client secret>
  1. From the side navigation, click API permissions.

  2. Under Configured permissions, click Add a permission.

The Azure Secrets Engine documentation lists the Azure permissions need to be assigned.

  1. Click Microsoft Graph.

  1. Select Application permissions.

  2. Add the following permissions.

    Permission Name
    Type

    Application.ReadWrite.OwnedBy

    Application

    GroupMember.ReadWrite.All

    Application

Note

If you plan to use the rotate root credentials API, you'll need to change Application.ReadWrite.OwnedBy to Application.ReadWrite.All.

  1. Click Add permissions.

  2. Click Grant admin consent for azure to grant the permissions.

  3. Click Yes to confirm consent.

  4. Click the name of your subscription.

  5. Copy the Subscription ID.

  6. In a terminal, set the variable SUBSCRIPTION_ID to the Subscription ID.

    $ export SUBSCRIPTION_ID=<Subscription ID>
  7. From the side navigation, click Access control (IAM).

  8. Click Add > Add a role assignment.

  9. Select User Access Administrator and click Next.

  10. Click Select members.

  11. Enter your application name or application id in the Select field.

  12. Click the application when it is displayed which will add the application to the Selected members list.

  13. Click Select.

  14. 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

Resource Group

The secrets engine generates credentials within an Azure resource group.

  1. Click Create.

  2. Choose the subscription from the Subscription select field.

  3. Enter vault-education in the Resource group field.

  4. Click Review + create.

    The view changes to display the review page.

  5. Click Create.

The resource group vault-education is created.

Configure Vault

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

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.

Enable the azure secrets engine at the path named azure.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
    --request POST \
    --data '{"type":"azure"}' \
    $VAULT_ADDR/v1/sys/mounts/azure

The data field defines the type, {"type":"azure"}, of secrets engine to enable. The requested URL, /v1/sys/mounts/azure, defines the path of the secrets engine.

Note:

  1. Open a web browser and launch the Vault UI (e.g. http://127.0.0.1:8200/ui) and then login.

  2. Select Enable new engine.

  3. Select Azure from the list, and then click Next.

  4. Click Enable Engine to complete. This sets the path to be azure.

Note:

In this tutorial, the azure secrets engine is enabled at the /azure path in Vault. However, it is possible to enable your secret engines at any location by entering your desired path in the Path text field.

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, client ID, client ID, and tenant ID are stored as environment variables.

$ echo $SUBSCRIPTION_ID; echo $CLIENT_ID; echo $CLIENT_SECRET; echo $TENANT_ID

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 \
     use_microsoft_graph_api=true
  1. Create an API request payload containing the Azure credentials.

    $ tee payload.json <<EOF
    {
      "subscription_id": "$SUBSCRIPTION_ID",
      "tenant_id": "$TENANT_ID",
      "client_id": "$CLIENT_ID",
      "client_secret": "$CLIENT_SECRET",
      "use_microsoft_graph_api": true
    }
    EOF
  2. Configure the Azure secrets engine with the credentials.

    $ curl --header "X-Vault-Token: $VAULT_TOKEN" \
        --request POST \
        --data @payload.json \
        $VAULT_ADDR/v1/azure/config

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
  1. Create an API request payload specifying the role definition.

    $ tee payload.json <<EOF
    {
      "azure_roles": "[
        {
          \"role_name\": \"Contributor\",
          \"scope\":  \"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/vault-education\"
        }
      ]",
      "ttl": 3600,
      "max_ttl": "24h"
    }
    EOF

    This payload defines that the Vault role is mapped to the Azure role named, Contributor in the vault-education resource group. Credentials are generated with a time-to-live (TTL) of 1 hour and max TTL of 24 hours.

  2. Create the Vault role with the path edu-app with the role defined within the payload.

    $ curl --header "X-Vault-Token: $VAULT_TOKEN" \
        --request POST \
        --data @payload.json \
        $VAULT_ADDR/v1/azure/roles/edu-app

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.

  1. Read credentials from the edu-app azure role.

$ vault read azure/creds/edu-app

Example output:

Key                Value
---                -----
lease_id           azure/creds/edu-app/EA2uTB98qAPR2BRSaasnmnja
lease_duration     1h
lease_renewable    true
client_id          074421c4-60b7-477c-9c5f-07e0925ba6a6
client_secret      Vw17Q~3u3ZRRUd.M4pP-Bl487.i4Fe1~jLpLT

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

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

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

  1. 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.

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

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

Example output:

Key                Value
---                -----
lease_id           azure/creds/edu-app/W24u6d77acJbBzzf02iq6YHd
lease_duration     1h
lease_renewable    true
client_id          b43b4e84-5568-4efd-8ba5-cbd40936ba12
client_secret      iXK7Q~mFGn-MJjcXhGbevQCQPRhB2Hkg1QGAq
  1. Read credentials from the edu-app azure role.

    $ curl --header "X-Vault-Token: $VAULT_TOKEN" \
        --request GET \
        $VAULT_ADDR/v1/azure/creds/edu-app | jq -r ".data"

    Example output:

    {
      "client_id": "0478e592-8492-4ae5-bc16-6c7ba0541112",
      "client_secret": "F-Y7Q~m1fwJ4PscEq-xa84NhMddgNR7b1vRtG"
    }

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

  2. For applications (apps persona) to request credentials require a Vault policy that grants access to this role. Define a stringified version of the policy definition in a file.

    $ tee payload.json <<EOF
    {
      "policy": "path \"azure/creds/edu-app\" {capabilities = [ \"read\" ]}"
    }
    EOF
  3. Create a policy named apps.

    $ curl --header "X-Vault-Token: $VAULT_TOKEN" \
        --request PUT \
        --data @payload.json \
        $VAULT_ADDR/v1/sys/policies/acl/apps

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

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

    $ APPS_TOKEN=$(curl --header "X-Vault-Token: $VAULT_TOKEN" \
        --request POST \
        --data '{"policies": ["apps"]}' \
        $VAULT_ADDR/v1/auth/token/create | jq -r ".auth.client_token")

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

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

    $ curl --header "X-Vault-Token: $APPS_TOKEN" \
        --request GET \
        $VAULT_ADDR/v1/azure/creds/edu-app | jq -r ".data"

    Example output:

    {
      "client_id": "d286adc5-53cf-43bd-b36a-6f939c3bc9c9",
      "client_secret": "B0F7Q~COpioWx5FzPrZsp8~VnjH_5FiAxB1eS"
    }
  1. Click the Policies tab, and then select Create ACL policy.

  2. Enter apps in the Name field.

  3. Enter this policy in the Policy field.

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

    Copy

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

  4. Click Create Policy.

  5. Click the Vault CLI shell icon (>_) to open a command shell.

  6. Execute vault write auth/token/create policies=apps in the CLI shell to create a new token:

  7. Copy and save the generated client token value.

  8. Sign out of the Vault UI.

  9. Now, sign into the Vault using the newly generated token you just copied.

  10. Click the Vault CLI shell icon (>_) to open a command shell. Execute vault read azure/creds/edu-app in the CLI shell.

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

Example output:

Keys
----
o2F4EA3hU8Fpjgc39XyQpjtU
fRFeCtlMnoPqelTrjf5j5kGA

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 a lease

If you need to extend the use of the generated Azure credentials, you can renew the lease by passing its lease ID.

$ vault lease renew azure/creds/edu-app/$LEASE_ID

Example output:

Key                Value
---                -----
lease_id           azure/creds/edu-app/EA2uTB98qAPR2BRSaasnmnja
lease_duration     1h
lease_renewable    true

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

Revoke the leases

When the Azure credentials are no longer needed, you can revoke the lease without waiting for its expiration.

  1. Revoke the least associated with the $LEASE_ID environment variable.

    $ vault lease revoke azure/creds/edu-app/$LEASE_ID
    
    All revocation operations queued successfully!
  2. List the existing leases.

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

    The first lease is no longer valid.

  3. Read new credentials from the edu-app role.

    $ vault read azure/creds/edu-app
  4. 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.

  5. 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.

List the existing lease IDs.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request LIST \
   $VAULT_ADDR/v1/sys/leases/lookup/azure/creds/edu-app | jq -r ".data.keys"

All valid leases for Azure credentials are displayed.

Example output:

[
  "w8KAdJGYmN4ysZVFHPgl6psT",
  "zKl9iK07Yf5qZtmg7qcM5Tgg"
]

Create a variable that stores the first (and only) lease ID.

$ LEASE_ID=$(curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request LIST \
   $VAULT_ADDR/v1/sys/leases/lookup/azure/creds/edu-app | jq -r ".data.keys[0]")

Renew a lease

If you need to extend the use of the generated Azure credentials, you can renew the lease by passing its lease ID.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
    --request PUT \
    --data "{ \"lease_id\": \"azure/creds/edu-app/$LEASE_ID\" }" \
    $VAULT_ADDR/v1/sys/leases/renew | jq

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

Example output:

{
  "request_id": "7dee4bd8-73b6-f7f0-693f-78d3d38aef5c",
  "lease_id": "azure/creds/edu-app/w8KAdJGYmN4ysZVFHPgl6psT",
  "renewable": true,
  "lease_duration": 3600,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Revoke the leases

When the Azure credentials are no longer needed, you can revoke the lease without waiting for its expiration.

Revoke the lease without waiting for its expiration.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request PUT \
   --data "{ \"lease_id\": \"azure/creds/edu-app/$LEASE_ID\" }" \
   $VAULT_ADDR/v1/sys/leases/revoke

List the existing leases.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request LIST \
   $VAULT_ADDR/v1/sys/leases/lookup/azure/creds/edu-app | jq -r ".data.keys"

Example output:

[
  "zKl9iK07Yf5qZtmg7qcM5Tgg"
]

The deleted lease is no longer valid and is not displayed.

Read new credentials from the edu-app role.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request GET \
   $VAULT_ADDR/v1/azure/creds/edu-app | jq -r ".data"

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

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request PUT \
   $VAULT_ADDR/v1/sys/leases/revoke-prefix/azure/creds/edu-app

List the existing leases.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \
   --request LIST \
   $VAULT_ADDR/v1/sys/leases/lookup/azure/creds/edu-app | jq

All the leases with this path as a prefix have been revoked; therefore, it returns an empty array.

{
  "errors": []
}

Clean up

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

  1. From the side navigation, select App registrations.

  2. Click the vault-education application (or whatever the name you set for the application).

  3. From the application overview, click delete.

  4. Select Yes to delete the application. The application is deleted.

  5. Click the vault-education resource group.

  6. From the resource group overview, click Delete resource group.

  7. Enter vault-education in the TYPE THE RESOURCE GROUP NAME: field.

  8. Click Delete. The resource group is deleted.

Stop the Vault server

  1. Unset the VAULT_TOKEN environment variable.

    $ unset VAULT_TOKEN
  2. Unset the VAULT_ADDR environment variable.

    $ unset VAULT_ADDR
  3. 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.

    $ pgrep -f vault | xargs kill

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 .

service principal
online Azure documentation
Microsoft Azure Portal
Subscriptions
Resource groups
configuration parameters
previous step
apps persona
jq
Microsoft Azure Portal
Azure Active Directory
Resource groups