{"id":1042,"date":"2026-08-09T02:42:55","date_gmt":"2026-08-09T02:42:55","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1042"},"modified":"2026-08-09T02:42:56","modified_gmt":"2026-08-09T02:42:56","slug":"hashicorp-vault-master-lab-consul-secrets-engine-userpass-authentication-vault-policies-dynamic-consul-credentials","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/hashicorp-vault-master-lab-consul-secrets-engine-userpass-authentication-vault-policies-dynamic-consul-credentials\/","title":{"rendered":"HashiCorp Vault Master Lab – Consul Secrets Engine + Userpass Authentication + Vault Policies + Dynamic Consul Credentials"},"content":{"rendered":"\n

<\/p>\n\n\n\n

Beginner-Friendly Hands-On Lab for Ubuntu Linux<\/h3>\n\n\n\n
\n\n\n\n

1. Lab Objective<\/h1>\n\n\n\n

In this lab, we will build the following environment from scratch:<\/p>\n\n\n\n

                    Ubuntu Linux Server\n                           |\n              +------------+-------------+\n              |                          |\n        HashiCorp Vault             HashiCorp Consul\n          127.0.0.1:8200              127.0.0.1:8500\n              |                          |\n              |                          |\n        userpass auth                    |\n              |                          |\n          student1                       |\n              |                          |\n     consul-engine-admin                 |\n          Vault Policy                   |\n              |                          |\n              v                          |\n      Consul Secrets Engine ------------+\n              |\n              |\n      student-role\n              |\n              v\n      Dynamic Consul Token\n              |\n              v\n       Consul ACL Policy\n          student-kv\n              |\n              v\n        student\/* KV\n<\/code><\/pre>\n\n\n\n
By the end of the lab, students will understand:<\/p>\n\n\n\n
    \n
  • how to install Vault and Consul;<\/li>\n\n\n\n
  • how to start Vault in development mode;<\/li>\n\n\n\n
  • how to start Consul in development mode with ACLs;<\/li>\n\n\n\n
  • how Consul ACL bootstrap works;<\/li>\n\n\n\n
  • how to enable the Vault Consul secrets engine;<\/li>\n\n\n\n
  • how Vault authenticates to Consul;<\/li>\n\n\n\n
  • how to create a Consul ACL policy;<\/li>\n\n\n\n
  • how to create a Vault ACL policy;<\/li>\n\n\n\n
  • how to enable the Vault userpass<\/code> authentication method;<\/li>\n\n\n\n
  • how to create a Vault user;<\/li>\n\n\n\n
  • how to attach a Vault policy to that user;<\/li>\n\n\n\n
  • how to log in using username\/password;<\/li>\n\n\n\n
  • how to perform Create, Read, Update, List, and Delete operations on Consul secrets-engine roles;<\/li>\n\n\n\n
  • how to generate short-lived Consul credentials;<\/li>\n\n\n\n
  • how to use the dynamically generated Consul token;<\/li>\n\n\n\n
  • how Vault leases work;<\/li>\n\n\n\n
  • how to renew a lease;<\/li>\n\n\n\n
  • how to revoke a lease;<\/li>\n\n\n\n
  • how to confirm that the Consul credential stops working after revocation;<\/li>\n\n\n\n
  • how Vault policies prevent access to unrelated secret engines.<\/li>\n<\/ul>\n\n\n\n
    The current Vault documentation is on the Vault 2.x release line. As of August 9, 2026<\/strong>, HashiCorp’s release notes list Vault 2.0.4<\/strong>, released August 4, 2026. The current Consul install material lists Consul 2.0.2<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    2. Important Lab Warning<\/h1>\n\n\n\n
    This tutorial intentionally uses:<\/p>\n\n\n\n
    Vault development mode\nConsul development mode\nHTTP instead of HTTPS\nA known Vault root token\nA locally stored Consul bootstrap token\nA broad Vault policy\n<\/code><\/pre>\n\n\n\n
    These choices make the environment easy for beginners to understand.<\/p>\n\n\n\n
    Do not use this architecture in production.<\/strong><\/p>\n\n\n\n
    Vault development mode:<\/p>\n\n\n\n
      \n
    • starts initialized;<\/li>\n\n\n\n
    • starts unsealed;<\/li>\n\n\n\n
    • stores its data in memory;<\/li>\n\n\n\n
    • listens on 127.0.0.1:8200<\/code>;<\/li>\n\n\n\n
    • can use a predetermined root token;<\/li>\n\n\n\n
    • loses its data when stopped.<\/li>\n<\/ul>\n\n\n\n
      HashiCorp explicitly identifies dev mode as an experimentation\/development environment rather than a production deployment.<\/p>\n\n\n\n
      \n\n\n\n
      3. Lab Environment<\/h1>\n\n\n\n
      Recommended environment:<\/p>\n\n\n\n
      Operating System : Ubuntu Server\nVault             : 2.0.4 or newer compatible 2.x\nConsul            : 2.0.2 or newer compatible 2.x\nVault Address     : http:\/\/127.0.0.1:8200\nConsul Address    : http:\/\/127.0.0.1:8500\nVault Root Token  : root\nVault User        : student1\nVault Password    : StudentLab@2026\nVault Policy      : consul-engine-admin\nVault Engine      : consul\/\nConsul Policy     : student-kv\nVault Consul Role : student-role\nConsul KV Prefix  : student\/\n<\/code><\/pre>\n\n\n\n
      Everything in this tutorial runs on the same Ubuntu server<\/strong>.<\/p>\n\n\n\n
      \n\n\n\n
      4. Understanding the Two Different Policies<\/h1>\n\n\n\n
      Before running commands, students should understand that this lab uses two completely different policy systems<\/strong>.<\/p>\n\n\n\n
      Vault Policy<\/h2>\n\n\n\n
      Our Vault policy will be named:<\/p>\n\n\n\n
      consul-engine-admin\n<\/code><\/pre>\n\n\n\n
      It controls what the Vault user student1<\/code> can do inside Vault<\/strong>.<\/p>\n\n\n\n
      For example:<\/p>\n\n\n\n
      Can student1 create a Vault Consul role?\nCan student1 read the role?\nCan student1 modify the role?\nCan student1 delete the role?\nCan student1 request a dynamic Consul token?\n<\/code><\/pre>\n\n\n\n
      Vault policies map paths to capabilities such as:<\/p>\n\n\n\n
      create\nread\nupdate\ndelete\nlist\n<\/code><\/pre>\n\n\n\n
      Vault’s current policy documentation maps these capabilities to operations on Vault paths.<\/p>\n\n\n\n
      \n\n\n\n
      Consul ACL Policy<\/h2>\n\n\n\n
      Our Consul ACL policy will be named:<\/p>\n\n\n\n
      student-kv\n<\/code><\/pre>\n\n\n\n
      This policy controls what a Consul token generated by Vault<\/strong> can do inside Consul.<\/p>\n\n\n\n
      We will allow the generated token to manage:<\/p>\n\n\n\n
      student\/*\n<\/code><\/pre>\n\n\n\n
      but not:<\/p>\n\n\n\n
      private\/*\nproduction\/*\nanything-else\/*\n<\/code><\/pre>\n\n\n\n
      A Consul write<\/code> policy permits reading and modifying the matching resources.<\/p>\n\n\n\n
      \n\n\n\n
      5. Step 1 \u2014 Update Ubuntu<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      sudo apt update\nsudo apt upgrade -y\n<\/code><\/pre>\n\n\n\n
      Install utilities required during the lab:<\/p>\n\n\n\n
      sudo apt install -y \\\n  curl \\\n  wget \\\n  gpg \\\n  lsb-release \\\n  jq\n<\/code><\/pre>\n\n\n\n
      Verify jq<\/code>:<\/p>\n\n\n\n
      jq --version\n<\/code><\/pre>\n\n\n\n
      Example:<\/p>\n\n\n\n
      jq-1.7\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      6. Step 2 \u2014 Add the Official HashiCorp Repository<\/h1>\n\n\n\n
      Download the HashiCorp repository signing key:<\/p>\n\n\n\n
      wget -O- https:\/\/apt.releases.hashicorp.com\/gpg \\\n  | sudo gpg --dearmor \\\n  -o \/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg\n<\/code><\/pre>\n\n\n\n
      Add the HashiCorp repository:<\/p>\n\n\n\n
      echo \"deb [arch=$(dpkg --print-architecture) signed-by=\/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg] https:\/\/apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' \/etc\/os-release || lsb_release -cs) main\" \\\n  | sudo tee \/etc\/apt\/sources.list.d\/hashicorp.list\n<\/code><\/pre>\n\n\n\n
      Update the package list:<\/p>\n\n\n\n
      sudo apt update\n<\/code><\/pre>\n\n\n\n
      HashiCorp publishes both Vault and Consul through its Ubuntu\/Debian package repository.<\/p>\n\n\n\n
      \n\n\n\n
      7. Step 3 \u2014 Install Vault and Consul<\/h1>\n\n\n\n
      Install both packages:<\/p>\n\n\n\n
      sudo apt install -y vault consul\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      8. Step 4 \u2014 Check Installed Versions<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault version\n<\/code><\/pre>\n\n\n\n
      At the time this lab was validated against the release documentation, the current Vault release is:<\/p>\n\n\n\n
      Vault v2.0.4\n<\/code><\/pre>\n\n\n\n
      Now check Consul:<\/p>\n\n\n\n
      consul version\n<\/code><\/pre>\n\n\n\n
      Current Consul should be from the 2.0.x line, with the current install release being:<\/p>\n\n\n\n
      Consul v2.0.2\n<\/code><\/pre>\n\n\n\n
      Consul’s version<\/code> command is the supported way to inspect the installed version.<\/p>\n\n\n\n
      \n\n\n\n
      9. Step 5 \u2014 Create a Working Directory<\/h1>\n\n\n\n
      Rather than scattering files around the server, create one directory for everything related to the lab.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      mkdir -p \"$HOME\/vault-consul-lab\"\n<\/code><\/pre>\n\n\n\n
      Set an environment variable:<\/p>\n\n\n\n
      export LAB_DIR=\"$HOME\/vault-consul-lab\"\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      echo \"$LAB_DIR\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      \/home\/<your-user>\/vault-consul-lab\n<\/code><\/pre>\n\n\n\n
      Move into the directory:<\/p>\n\n\n\n
      cd \"$LAB_DIR\"\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      10. Step 6 \u2014 Configure Consul ACLs<\/h1>\n\n\n\n
      Create:<\/p>\n\n\n\n
      cat > \"$LAB_DIR\/consul-lab.hcl\" <<'EOF'\ndatacenter = \"dc1\"\n\nacl = {\n  enabled                  = true\n  default_policy           = \"deny\"\n  enable_token_persistence = true\n}\nEOF\n<\/code><\/pre>\n\n\n\n
      Display the file:<\/p>\n\n\n\n
      cat \"$LAB_DIR\/consul-lab.hcl\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      datacenter = \"dc1\"\n\nacl = {\n  enabled                  = true\n  default_policy           = \"deny\"\n  enable_token_persistence = true\n}\n<\/code><\/pre>\n\n\n\n
      This enables the Consul ACL system and sets the default policy to deny<\/code>. HashiCorp recommends deny<\/code> for a new secured Consul environment.<\/p>\n\n\n\n
      \n\n\n\n
      11. Step 7 \u2014 Start Consul<\/h1>\n\n\n\n
      First ensure another Consul process is not already running:<\/p>\n\n\n\n
      pgrep -a consul || true\n<\/code><\/pre>\n\n\n\n
      For a fresh lab, there should normally be no output.<\/p>\n\n\n\n
      Start Consul:<\/p>\n\n\n\n
      nohup consul agent \\\n  -dev \\\n  -node=consul-lab \\\n  -config-file=\"$LAB_DIR\/consul-lab.hcl\" \\\n  > \"$LAB_DIR\/consul.log\" 2>&1 &\n<\/code><\/pre>\n\n\n\n
      Save the process ID:<\/p>\n\n\n\n
      echo $! > \"$LAB_DIR\/consul.pid\"\n<\/code><\/pre>\n\n\n\n
      Display the PID:<\/p>\n\n\n\n
      cat \"$LAB_DIR\/consul.pid\"\n<\/code><\/pre>\n\n\n\n
      Wait approximately two seconds:<\/p>\n\n\n\n
      sleep 2\n<\/code><\/pre>\n\n\n\n
      Development mode runs an in-memory single-server Consul agent and is intended for rapid development and experimentation.<\/p>\n\n\n\n
      \n\n\n\n
      12. Step 8 \u2014 Verify Consul<\/h1>\n\n\n\n
      Check the log:<\/p>\n\n\n\n
      tail -20 \"$LAB_DIR\/consul.log\"\n<\/code><\/pre>\n\n\n\n
      Check whether port 8500<\/code> is listening:<\/p>\n\n\n\n
      ss -lnt | grep 8500\n<\/code><\/pre>\n\n\n\n
      You should see something similar to:<\/p>\n\n\n\n
      LISTEN ... 127.0.0.1:8500\n<\/code><\/pre>\n\n\n\n
      Check the Consul leader:<\/p>\n\n\n\n
      curl -s http:\/\/127.0.0.1:8500\/v1\/status\/leader\n<\/code><\/pre>\n\n\n\n
      Expected output will resemble:<\/p>\n\n\n\n
      \"127.0.0.1:8300\"\n<\/code><\/pre>\n\n\n\n
      The exact address may vary slightly.<\/p>\n\n\n\n
      \n\n\n\n
      13. Step 9 \u2014 Bootstrap the Consul ACL System<\/h1>\n\n\n\n
      Consul ACLs are enabled, but no management token exists yet.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      consul acl bootstrap -format=json \\\n  > \"$LAB_DIR\/consul-bootstrap.json\"\n<\/code><\/pre>\n\n\n\n
      Protect the file:<\/p>\n\n\n\n
      chmod 600 \"$LAB_DIR\/consul-bootstrap.json\"\n<\/code><\/pre>\n\n\n\n
      View the non-secret portions:<\/p>\n\n\n\n
      jq 'del(.SecretID)' \"$LAB_DIR\/consul-bootstrap.json\"\n<\/code><\/pre>\n\n\n\n
      The bootstrap command creates the initial token associated with Consul’s unrestricted global-management<\/code> policy. Consul only permits the ACL bootstrap operation once for a given ACL state.<\/p>\n\n\n\n
      \n\n\n\n
      14. Step 10 \u2014 Capture the Consul Management Token<\/h1>\n\n\n\n
      Extract the Secret ID:<\/p>\n\n\n\n
      export CONSUL_MGMT_TOKEN=\"$(\n  jq -r '.SecretID' \"$LAB_DIR\/consul-bootstrap.json\"\n)\"\n<\/code><\/pre>\n\n\n\n
      Check that we captured something:<\/p>\n\n\n\n
      test -n \"$CONSUL_MGMT_TOKEN\" \\\n  && test \"$CONSUL_MGMT_TOKEN\" != \"null\" \\\n  && echo \"Consul management token captured successfully.\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Consul management token captured successfully.\n<\/code><\/pre>\n\n\n\n
      Do not<\/strong> print this token unnecessarily.<\/p>\n\n\n\n
      Configure the Consul CLI to use it:<\/p>\n\n\n\n
      export CONSUL_HTTP_TOKEN=\"$CONSUL_MGMT_TOKEN\"\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      15. Step 11 \u2014 Test Consul Administrative Access<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      consul acl policy list\n<\/code><\/pre>\n\n\n\n
      You should see built-in policies such as:<\/p>\n\n\n\n
      global-management\nbuiltin\/global-read-only\n<\/code><\/pre>\n\n\n\n
      The exact displayed formatting may differ.<\/p>\n\n\n\n
      \n\n\n\n
      16. Step 12 \u2014 Create a Consul Policy for Vault-Generated Tokens<\/h1>\n\n\n\n
      We do not<\/strong> want Vault to generate unrestricted Consul management tokens for students.<\/p>\n\n\n\n
      Instead, create a restricted Consul ACL policy.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      cat > \"$LAB_DIR\/student-kv-policy.hcl\" <<'EOF'\nkey_prefix \"student\/\" {\n  policy = \"write\"\n}\nEOF\n<\/code><\/pre>\n\n\n\n
      Display it:<\/p>\n\n\n\n
      cat \"$LAB_DIR\/student-kv-policy.hcl\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      key_prefix \"student\/\" {\n  policy = \"write\"\n}\n<\/code><\/pre>\n\n\n\n
      This policy allows generated Consul tokens to read and modify keys underneath:<\/p>\n\n\n\n
      student\/\n<\/code><\/pre>\n\n\n\n
      Consul’s current ACL rules define write<\/code> as permitting both read and modification operations.<\/p>\n\n\n\n
      \n\n\n\n
      17. Step 13 \u2014 Create the Consul ACL Policy<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      consul acl policy create \\\n  -name=\"student-kv\" \\\n  -description=\"Vault generated tokens may manage student KV data\" \\\n  -rules=@\"$LAB_DIR\/student-kv-policy.hcl\"\n<\/code><\/pre>\n\n\n\n
      A successful response will contain fields similar to:<\/p>\n\n\n\n
      ID:\nName:        student-kv\nDescription: Vault generated tokens may manage student KV data\nRules:\nkey_prefix \"student\/\" {\n  policy = \"write\"\n}\n<\/code><\/pre>\n\n\n\n
      Consul’s current CLI supports loading ACL policy rules from a file by prefixing the filename with @<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      18. Step 14 \u2014 Read the Consul Policy<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      consul acl policy read -name=\"student-kv\"\n<\/code><\/pre>\n\n\n\n
      Verify that you see:<\/p>\n\n\n\n
      Name: student-kv\n<\/code><\/pre>\n\n\n\n
      and:<\/p>\n\n\n\n
      key_prefix \"student\/\" {\n  policy = \"write\"\n}\n<\/code><\/pre>\n\n\n\n
      At this point the Consul side of the permission model exists.<\/p>\n\n\n\n
      \n\n\n\n
      19. Step 15 \u2014 Start Vault<\/h1>\n\n\n\n
      Before starting Vault, check whether another Vault process exists:<\/p>\n\n\n\n
      pgrep -a vault || true\n<\/code><\/pre>\n\n\n\n
      Start the Vault development server:<\/p>\n\n\n\n
      nohup vault server \\\n  -dev \\\n  -dev-root-token-id=\"root\" \\\n  -dev-listen-address=\"127.0.0.1:8200\" \\\n  > \"$LAB_DIR\/vault.log\" 2>&1 &\n<\/code><\/pre>\n\n\n\n
      Save the PID:<\/p>\n\n\n\n
      echo $! > \"$LAB_DIR\/vault.pid\"\n<\/code><\/pre>\n\n\n\n
      Wait:<\/p>\n\n\n\n
      sleep 2\n<\/code><\/pre>\n\n\n\n
      HashiCorp’s current Vault server CLI supports -dev<\/code>, -dev-root-token-id<\/code>, and -dev-listen-address<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      20. Step 16 \u2014 Configure the Vault CLI<\/h1>\n\n\n\n
      Set the Vault server address:<\/p>\n\n\n\n
      export VAULT_ADDR='http:\/\/127.0.0.1:8200'\n<\/code><\/pre>\n\n\n\n
      Set the root token:<\/p>\n\n\n\n
      export VAULT_TOKEN='root'\n<\/code><\/pre>\n\n\n\n
      Confirm:<\/p>\n\n\n\n
      echo \"$VAULT_ADDR\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      http://127.0.0.1:8200\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      21. Step 17 \u2014 Verify Vault<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault status\n<\/code><\/pre>\n\n\n\n
      Expected output should contain:<\/p>\n\n\n\n
      Initialized       true\nSealed            false\n<\/code><\/pre>\n\n\n\n
      Because this is a development server, Vault starts initialized and unsealed automatically.<\/p>\n\n\n\n
      \n\n\n\n
      22. Step 18 \u2014 Confirm Root Access<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault token lookup\n<\/code><\/pre>\n\n\n\n
      You should see:<\/p>\n\n\n\n
      policies    [root]\n<\/code><\/pre>\n\n\n\n
      The root<\/code> policy gives unrestricted access and should only be used for the administrative setup section of this lab. Root tokens have unrestricted Vault privileges.<\/p>\n\n\n\n
      \n\n\n\n
      23. Step 19 \u2014 Check Existing Secrets Engines<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault secrets list\n<\/code><\/pre>\n\n\n\n
      You will see several built-in mounts.<\/p>\n\n\n\n
      The important point is that:<\/p>\n\n\n\n
      consul\/\n<\/code><\/pre>\n\n\n\n
      should not<\/strong> exist yet.<\/p>\n\n\n\n
      \n\n\n\n
      24. Step 20 \u2014 Enable the Consul Secrets Engine<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault secrets enable consul\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Enabled the consul secrets engine at: consul\/\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      vault secrets list\n<\/code><\/pre>\n\n\n\n
      You should now find:<\/p>\n\n\n\n
      consul\/\n<\/code><\/pre>\n\n\n\n
      The supported command for enabling the secrets engine at its default mount is:<\/p>\n\n\n\n
      vault secrets enable consul\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      25. Step 21 \u2014 Configure Vault to Communicate with Consul<\/h1>\n\n\n\n
      Vault now has the plugin, but the plugin does not yet know:<\/p>\n\n\n\n
      Where is Consul?\nWhat credential should Vault use to create Consul tokens?\n<\/code><\/pre>\n\n\n\n
      Configure it:<\/p>\n\n\n\n
      vault write consul\/config\/access \\\n  address=\"127.0.0.1:8500\" \\\n  scheme=\"http\" \\\n  token=\"$CONSUL_MGMT_TOKEN\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data written to: consul\/config\/access\n<\/code><\/pre>\n\n\n\n
      Vault’s Consul secrets engine requires the Consul address and, for an already-bootstrapped Consul ACL environment, a Consul management token that Vault can use to create and revoke ACL tokens.<\/p>\n\n\n\n
      \n\n\n\n
      26. Step 22 \u2014 Stop Using the Consul Management Token Directly<\/h1>\n\n\n\n
      This is an important lab practice.<\/p>\n\n\n\n
      Vault now has the credential it needs.<\/p>\n\n\n\n
      Remove the management credential from the active shell:<\/p>\n\n\n\n
      unset CONSUL_HTTP_TOKEN\nunset CONSUL_MGMT_TOKEN\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      env | grep CONSUL_HTTP_TOKEN || true\n<\/code><\/pre>\n\n\n\n
      There should be no output.<\/p>\n\n\n\n
      From this point onward, we want students to work with credentials generated by Vault<\/strong>, not with the powerful Consul bootstrap credential.<\/p>\n\n\n\n
      \n\n\n\n
      27. Step 23 \u2014 Create the Vault Policy<\/h1>\n\n\n\n
      Now create the policy that will eventually be attached to our Vault userpass<\/code> user.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      cat > \"$LAB_DIR\/consul-engine-admin.hcl\" <<'EOF'\n# Full CRUD-style access to everything underneath the\n# Consul secrets engine mount.\n#\n# LAB ONLY: This includes sensitive Consul engine configuration.\n\npath \"consul\/*\" {\n  capabilities = [\n    \"create\",\n    \"read\",\n    \"update\",\n    \"delete\",\n    \"list\"\n  ]\n}\n\n# Allow looking up an individual dynamic-secret lease.\n\npath \"sys\/leases\/lookup\" {\n  capabilities = [\"update\"]\n}\n\n# Allow renewal of an individual lease.\n\npath \"sys\/leases\/renew\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/renew\/*\" {\n  capabilities = [\"update\"]\n}\n\n# Allow revocation of an individual lease.\n\npath \"sys\/leases\/revoke\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/revoke\/*\" {\n  capabilities = [\"update\"]\n}\nEOF\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      28. Step 24 \u2014 Examine the Vault Policy<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      cat \"$LAB_DIR\/consul-engine-admin.hcl\"\n<\/code><\/pre>\n\n\n\n
      The central section is:<\/p>\n\n\n\n
      path \"consul\/*\" {\n  capabilities = [\n    \"create\",\n    \"read\",\n    \"update\",\n    \"delete\",\n    \"list\"\n  ]\n}\n<\/code><\/pre>\n\n\n\n
      This means:<\/p>\n\n\n\n
      CREATE  -> permitted\nREAD    -> permitted\nUPDATE  -> permitted\nDELETE  -> permitted\nLIST    -> permitted\n<\/code><\/pre>\n\n\n\n
      Vault policies are path based, and these capabilities map to the corresponding operations supported by a Vault endpoint.<\/p>\n\n\n\n
      \n\n\n\n
      29. Step 25 \u2014 Load the Policy into Vault<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault policy write \\\n  consul-engine-admin \\\n  \"$LAB_DIR\/consul-engine-admin.hcl\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Uploaded policy: consul-engine-admin\n<\/code><\/pre>\n\n\n\n
      Vault supports loading an HCL ACL policy using vault policy write<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      30. Step 26 \u2014 Read the Vault Policy<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault policy read consul-engine-admin\n<\/code><\/pre>\n\n\n\n
      Verify the policy is displayed correctly.<\/p>\n\n\n\n
      \n\n\n\n
      31. Step 27 \u2014 List Vault Policies<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault policy list\n<\/code><\/pre>\n\n\n\n
      You should see something similar to:<\/p>\n\n\n\n
      consul-engine-admin\ndefault\nroot\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      32. Step 28 \u2014 Enable Userpass Authentication<\/h1>\n\n\n\n
      Now enable username\/password authentication.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault auth enable userpass\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Enabled userpass auth method at: userpass\/\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      vault auth list\n<\/code><\/pre>\n\n\n\n
      You should find:<\/p>\n\n\n\n
      userpass\/\n<\/code><\/pre>\n\n\n\n
      Vault’s current documentation supports enabling the method with exactly:<\/p>\n\n\n\n
      vault auth enable userpass\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      33. Step 29 \u2014 Create One Vault User<\/h1>\n\n\n\n
      Create:<\/p>\n\n\n\n
      Username: student1\nPassword: StudentLab@2026\nPolicy:   consul-engine-admin\n<\/code><\/pre>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault write auth\/userpass\/users\/student1 \\\n  password='StudentLab@2026' \\\n  policies='consul-engine-admin' \\\n  token_ttl='1h' \\\n  token_max_ttl='4h'\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data written to: auth\/userpass\/users\/student1\n<\/code><\/pre>\n\n\n\n
      Vault’s userpass configuration associates users with policies, and successful authentication produces a Vault token carrying those policies.<\/p>\n\n\n\n
      \n\n\n\n
      34. Step 30 \u2014 Read the User Configuration<\/h1>\n\n\n\n
      Still using the root token, run:<\/p>\n\n\n\n
      vault read auth\/userpass\/users\/student1\n<\/code><\/pre>\n\n\n\n
      You should see information including:<\/p>\n\n\n\n
      token_policies\ntoken_ttl\ntoken_max_ttl\n<\/code><\/pre>\n\n\n\n
      The password itself will not be returned.<\/p>\n\n\n\n
      The current Userpass API exposes reading user configuration but does not reveal the stored password.<\/p>\n\n\n\n
      \n\n\n\n
      35. Step 31 \u2014 Administrator Setup Is Complete<\/h1>\n\n\n\n
      At this point root has completed:<\/p>\n\n\n\n
      Consul installation\nConsul ACL setup\nConsul ACL policy creation\nVault installation\nVault Consul secrets engine\nVault-to-Consul connection\nVault policy\nUserpass authentication\nVault user creation\n<\/code><\/pre>\n\n\n\n
      Now we switch identities.<\/p>\n\n\n\n
      Everything from the next step should be performed as:<\/p>\n\n\n\n
      student1\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      36. Step 32 \u2014 Remove Root from the Current Shell<\/h1>\n\n\n\n
      This step is extremely important.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      unset VAULT_TOKEN\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      echo \"${VAULT_TOKEN:-VAULT_TOKEN is not set}\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      VAULT_TOKEN is not set\n<\/code><\/pre>\n\n\n\n
      If students accidentally leave:<\/p>\n\n\n\n
      VAULT_TOKEN=root\n<\/code><\/pre>\n\n\n\n
      then their tests are meaningless because every command continues to execute as root.<\/p>\n\n\n\n
      \n\n\n\n
      37. Step 33 \u2014 Login Using Userpass<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault login -method=userpass \\\n  username='student1' \\\n  password='StudentLab@2026'\n<\/code><\/pre>\n\n\n\n
      Expected output will contain something similar to:<\/p>\n\n\n\n
      token                 <generated-vault-token>\ntoken_duration        1h\ntoken_renewable       true\ntoken_policies        [\"consul-engine-admin\" \"default\"]\n<\/code><\/pre>\n\n\n\n
      The precise token will be different.<\/p>\n\n\n\n
      The supported CLI authentication form is:<\/p>\n\n\n\n
      vault login -method=userpass username=... password=...\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      38. Step 34 \u2014 Verify the Current Vault Identity<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault token lookup\n<\/code><\/pre>\n\n\n\n
      Check:<\/p>\n\n\n\n
      display_name\npolicies\nttl\n<\/code><\/pre>\n\n\n\n
      The policies should include:<\/p>\n\n\n\n
      consul-engine-admin\ndefault\n<\/code><\/pre>\n\n\n\n
      They should not<\/strong> include:<\/p>\n\n\n\n
      root\n<\/code><\/pre>\n\n\n\n
      This is a critical checkpoint.<\/p>\n\n\n\n
      \n\n\n\n
      39. Step 35 \u2014 Verify the Student’s Vault Capabilities<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault token capabilities consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      The output should contain capabilities similar to:<\/p>\n\n\n\n
      create, delete, list, read, update\n<\/code><\/pre>\n\n\n\n
      Now check the credential endpoint:<\/p>\n\n\n\n
      vault token capabilities consul\/creds\/student-role\n<\/code><\/pre>\n\n\n\n
      Again, the policy allows access.<\/p>\n\n\n\n
      Now test an unrelated Vault engine:<\/p>\n\n\n\n
      vault token capabilities secret\/data\/my-secret\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      deny\n<\/code><\/pre>\n\n\n\n
      This proves that the student is not a Vault administrator.<\/p>\n\n\n\n
      They have permissions on:<\/p>\n\n\n\n
      consul\/*\n<\/code><\/pre>\n\n\n\n
      but not arbitrary Vault paths.<\/p>\n\n\n\n
      \n\n\n\n
      40. Step 36 \u2014 First Negative Security Test<\/h1>\n\n\n\n
      Try writing into Vault’s development KV engine:<\/p>\n\n\n\n
      vault kv put secret\/not-allowed \\\n  username=student \\\n  password=test\n<\/code><\/pre>\n\n\n\n
      This should fail with a permission error similar to:<\/p>\n\n\n\n
      permission denied\n<\/code><\/pre>\n\n\n\n
      This failure is correct.<\/strong><\/p>\n\n\n\n
      The student’s policy only gives access to:<\/p>\n\n\n\n
      consul\/*\n<\/code><\/pre>\n\n\n\n
      This demonstrates authorization working correctly.<\/p>\n\n\n\n
      \n\n\n\n
      41. Step 37 \u2014 Understand Vault Consul Roles<\/h1>\n\n\n\n
      The Vault Consul secrets engine uses roles.<\/p>\n\n\n\n
      Think of a Vault role as a template that tells Vault:<\/p>\n\n\n\n
      \n
      When someone requests Consul credentials from this role, which Consul policy should be attached to the generated token and how long should the token live?<\/p>\n<\/blockquote>\n\n\n\n
      Our role will be:<\/p>\n\n\n\n
      student-role\n<\/code><\/pre>\n\n\n\n
      and it will reference the Consul policy:<\/p>\n\n\n\n
      student-kv\n<\/code><\/pre>\n\n\n\n
      Current Vault Consul API documentation supports creating\/updating roles with consul_policies<\/code>, assigning TTLs, reading roles, listing them, deleting them, and generating credentials from them.<\/p>\n\n\n\n
      \n\n\n\n
      42. Step 38 \u2014 CREATE a Consul Secrets-Engine Role<\/h1>\n\n\n\n
      Run as student1<\/code>:<\/p>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='30m' \\\n  max_ttl='1h'\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data written to: consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      We have just performed the CREATE<\/strong> operation.<\/p>\n\n\n\n
      \n\n\n\n
      43. Step 39 \u2014 READ the Role<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      You should see fields corresponding to the role, including its Consul policy and TTL configuration.<\/p>\n\n\n\n
      This is the READ<\/strong> operation.<\/p>\n\n\n\n
      \n\n\n\n
      44. Step 40 \u2014 LIST the Roles<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault list consul\/roles\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Keys\n----\nstudent-role\n<\/code><\/pre>\n\n\n\n
      This is the LIST<\/strong> operation.<\/p>\n\n\n\n
      The Consul secrets engine explicitly supports LIST \/consul\/roles<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      45. Step 41 \u2014 UPDATE the Role<\/h1>\n\n\n\n
      Originally:<\/p>\n\n\n\n
      TTL     = 30 minutes\nMax TTL = 1 hour\n<\/code><\/pre>\n\n\n\n
      Change it to:<\/p>\n\n\n\n
      TTL     = 15 minutes\nMax TTL = 30 minutes\n<\/code><\/pre>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='15m' \\\n  max_ttl='30m'\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data written to: consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      This demonstrates UPDATE<\/strong>.<\/p>\n\n\n\n
      \n\n\n\n
      46. Step 42 \u2014 Verify the Update<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      Verify the new TTL settings.<\/p>\n\n\n\n
      \n\n\n\n
      47. Step 43 \u2014 DELETE the Role<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault delete consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data deleted (if it existed) at: consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      This demonstrates DELETE<\/strong>.<\/p>\n\n\n\n
      The secrets engine’s current API supports DELETE \/consul\/roles\/:name<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      48. Step 44 \u2014 Confirm the Role Is Gone<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault list consul\/roles\n<\/code><\/pre>\n\n\n\n
      You may receive:<\/p>\n\n\n\n
      No value found at consul\/roles\n<\/code><\/pre>\n\n\n\n
      Alternatively, if other roles exist, student-role<\/code> should be absent.<\/p>\n\n\n\n
      \n\n\n\n
      49. Step 45 \u2014 Recreate the Role<\/h1>\n\n\n\n
      We need the role for the dynamic-credential portion of the lab.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='30m' \\\n  max_ttl='1h'\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      50. CRUD Checkpoint<\/h1>\n\n\n\n
      Students have now successfully demonstrated:<\/p>\n\n\n\n
      CREATE\nvault write consul\/roles\/student-role ...\n\nREAD\nvault read consul\/roles\/student-role\n\nUPDATE\nvault write consul\/roles\/student-role ...\n\nLIST\nvault list consul\/roles\n\nDELETE\nvault delete consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      This is the core Vault ACL policy exercise.<\/p>\n\n\n\n
      \n\n\n\n
      51. Step 46 \u2014 Generate a Dynamic Consul Credential<\/h1>\n\n\n\n
      Now request a Consul token.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault read consul\/creds\/student-role\n<\/code><\/pre>\n\n\n\n
      Vault should return information resembling:<\/p>\n\n\n\n
      Key                 Value\n---                 -----\nlease_id            consul\/creds\/student-role\/<unique-id>\nlease_duration      30m\nlease_renewable     true\ntoken               <dynamic-consul-token>\n<\/code><\/pre>\n\n\n\n
      Exact fields and values may vary.<\/p>\n\n\n\n
      Every request creates a new Consul ACL token<\/strong>.<\/p>\n\n\n\n
      The current Consul secrets-engine credential endpoint is a read operation on:<\/p>\n\n\n\n
      consul\/creds\/:role\n<\/code><\/pre>\n\n\n\n
      even though that read causes Vault to create a new credential. This is why the Vault policy requires read<\/code> capability on that path.<\/p>\n\n\n\n
      \n\n\n\n
      52. Step 47 \u2014 Capture the Dynamic Credential Safely<\/h1>\n\n\n\n
      Instead of manually copying the token, request JSON:<\/p>\n\n\n\n
      CREDS_JSON=\"$(\n  vault read -format=json consul\/creds\/student-role\n)\"\n<\/code><\/pre>\n\n\n\n
      Capture the Vault lease ID:<\/p>\n\n\n\n
      export LEASE_ID=\"$(\n  printf '%s' \"$CREDS_JSON\" \\\n  | jq -r '.lease_id'\n)\"\n<\/code><\/pre>\n\n\n\n
      Capture the generated Consul token:<\/p>\n\n\n\n
      export DYNAMIC_CONSUL_TOKEN=\"$(\n  printf '%s' \"$CREDS_JSON\" \\\n  | jq -r '.data.token'\n)\"\n<\/code><\/pre>\n\n\n\n
      Remove the JSON variable:<\/p>\n\n\n\n
      unset CREDS_JSON\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      53. Step 48 \u2014 Verify Variables Were Captured<\/h1>\n\n\n\n
      Check the lease ID:<\/p>\n\n\n\n
      echo \"$LEASE_ID\"\n<\/code><\/pre>\n\n\n\n
      It should resemble:<\/p>\n\n\n\n
      consul\/creds\/student-role\/<unique-id>\n<\/code><\/pre>\n\n\n\n
      Do not print the Consul token unnecessarily.<\/p>\n\n\n\n
      Instead verify that it exists:<\/p>\n\n\n\n
      test -n \"$DYNAMIC_CONSUL_TOKEN\" \\\n  && test \"$DYNAMIC_CONSUL_TOKEN\" != \"null\" \\\n  && echo \"Dynamic Consul token captured successfully.\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Dynamic Consul token captured successfully.\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      54. Step 49 \u2014 Use the Vault-Generated Consul Token<\/h1>\n\n\n\n
      We now use the generated token directly against Consul.<\/p>\n\n\n\n
      Write a KV value:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv put \\\n  student\/application\/database \\\n  \"training-database\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Data written to: student\/application\/database\n<\/code><\/pre>\n\n\n\n
      Depending on the Consul CLI version, successful KV writes may instead display:<\/p>\n\n\n\n
      Success! Data written\n<\/code><\/pre>\n\n\n\n
      or:<\/p>\n\n\n\n
      true\n<\/code><\/pre>\n\n\n\n
      The important result is success.<\/p>\n\n\n\n
      \n\n\n\n
      55. Step 50 \u2014 Read the Consul KV Value<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get student\/application\/database\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      training-database\n<\/code><\/pre>\n\n\n\n
      The Vault-generated Consul token works.<\/p>\n\n\n\n
      \n\n\n\n
      56. Step 51 \u2014 Update the Consul KV Value<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv put \\\n  student\/application\/database \\\n  \"production-style-training-value\"\n<\/code><\/pre>\n\n\n\n
      Read it:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get student\/application\/database\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      production-style-training-value\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      57. Step 52 \u2014 List Student Keys<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get -recurse student\/\n<\/code><\/pre>\n\n\n\n
      You should see the values underneath:<\/p>\n\n\n\n
      student\/\n<\/code><\/pre>\n\n\n\n
      A token with Consul write<\/code> access on the matching prefix also has read\/list functionality for that prefix.<\/p>\n\n\n\n
      \n\n\n\n
      58. Step 53 \u2014 Prove the Consul Token Is Restricted<\/h1>\n\n\n\n
      Now try writing outside the permitted prefix:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv put \\\n  production\/database\/password \\\n  \"should-not-work\"\n<\/code><\/pre>\n\n\n\n
      This should fail with an ACL\/permission error.<\/p>\n\n\n\n
      That failure is correct<\/strong>.<\/p>\n\n\n\n
      Why?<\/p>\n\n\n\n
      Because the dynamically generated token has:<\/p>\n\n\n\n
      key_prefix \"student\/\" {\n  policy = \"write\"\n}\n<\/code><\/pre>\n\n\n\n
      It does not have:<\/p>\n\n\n\n
      key_prefix \"production\/\" {\n  policy = \"write\"\n}\n<\/code><\/pre>\n\n\n\n
      This demonstrates the difference between:<\/p>\n\n\n\n
      Vault authorization\n<\/code><\/pre>\n\n\n\n
      and:<\/p>\n\n\n\n
      Consul authorization\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      59. Step 54 \u2014 Create a Value for the Lease Test<\/h1>\n\n\n\n
      Create another key:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv put \\\n  student\/lease-test \\\n  \"credential-is-currently-valid\"\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get student\/lease-test\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      credential-is-currently-valid\n<\/code><\/pre>\n\n\n\n
      Keep this key in Consul.<\/p>\n\n\n\n
      We will use it to prove credential revocation.<\/p>\n\n\n\n
      \n\n\n\n
      60. Step 55 \u2014 Understand Vault Leases<\/h1>\n\n\n\n
      Dynamic secrets issued by Vault have leases.<\/p>\n\n\n\n
      Our lease ID looks similar to:<\/p>\n\n\n\n
      consul\/creds\/student-role\/ABC123...\n<\/code><\/pre>\n\n\n\n
      The lease tells Vault:<\/p>\n\n\n\n
      which dynamic secret was issued\nwhen it was issued\nhow long it should live\nwhether it can be renewed\nhow Vault should revoke it\n<\/code><\/pre>\n\n\n\n
      Vault’s lease system tracks dynamic secrets and automatically revokes them when their lease expires.<\/p>\n\n\n\n
      \n\n\n\n
      61. Step 56 \u2014 Lookup the Lease<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault lease lookup \"$LEASE_ID\"\n<\/code><\/pre>\n\n\n\n
      Look for fields such as:<\/p>\n\n\n\n
      issue_time\nexpire_time\nlast_renewal_time\nttl\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      62. Step 57 \u2014 Renew the Dynamic Credential<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault lease renew \\\n  -increment=10m \\\n  \"$LEASE_ID\"\n<\/code><\/pre>\n\n\n\n
      Expected output resembles:<\/p>\n\n\n\n
      lease_id          consul\/creds\/student-role\/...\nlease_duration    ...\nlease_renewable   true\n<\/code><\/pre>\n\n\n\n
      The requested increment is advisory; the backend may apply TTL limits configured by the role or mount.<\/p>\n\n\n\n
      \n\n\n\n
      63. Step 58 \u2014 Confirm the Token Still Works<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get student\/lease-test\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      credential-is-currently-valid\n<\/code><\/pre>\n\n\n\n
      The token is still active.<\/p>\n\n\n\n
      \n\n\n\n
      64. Step 59 \u2014 Revoke the Dynamic Credential<\/h1>\n\n\n\n
      Now manually revoke its Vault lease.<\/p>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault lease revoke \\\n  -sync \\\n  \"$LEASE_ID\"\n<\/code><\/pre>\n\n\n\n
      Expected:<\/p>\n\n\n\n
      Success! Revoked lease: consul\/creds\/student-role\/...\n<\/code><\/pre>\n\n\n\n
      Using -sync<\/code> makes the revocation synchronous rather than merely queueing the work in the background. The current Vault CLI exposes this option on vault lease revoke<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      65. Step 60 \u2014 Prove the Consul Credential Was Revoked<\/h1>\n\n\n\n
      Try the same Consul command using the old token:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv get student\/lease-test\n<\/code><\/pre>\n\n\n\n
      This should now fail with a Consul ACL\/token error.<\/p>\n\n\n\n
      This failure is the expected result.<\/strong><\/p>\n\n\n\n
      The sequence proves:<\/p>\n\n\n\n
      Vault generated the token\n        \u2193\nToken worked in Consul\n        \u2193\nVault tracked it using a lease\n        \u2193\nVault revoked the lease\n        \u2193\nVault revoked the Consul token\n        \u2193\nOld Consul token stopped working\n<\/code><\/pre>\n\n\n\n
      Vault’s Consul secrets engine requires management-level Consul access precisely so that it can create and revoke these generated ACL tokens.<\/p>\n\n\n\n
      \n\n\n\n
      66. Step 61 \u2014 Request Another Dynamic Credential<\/h1>\n\n\n\n
      Run:<\/p>\n\n\n\n
      vault read consul\/creds\/student-role\n<\/code><\/pre>\n\n\n\n
      You will receive:<\/p>\n\n\n\n
      a different lease ID\na different Consul token\n<\/code><\/pre>\n\n\n\n
      This demonstrates one of the major benefits of dynamic credentials:<\/p>\n\n\n\n
      Applications do not need to share one permanent Consul password\/token.\n<\/code><\/pre>\n\n\n\n
      New credentials can be requested when required and expired\/revoked afterward.<\/p>\n\n\n\n
      \n\n\n\n
      67. Complete Authentication and Authorization Flow<\/h1>\n\n\n\n
      Students should now understand this entire chain:<\/p>\n\n\n\n
      1. student1 supplies username\/password\n                     |\n                     v\n2. Vault userpass authenticates student1\n                     |\n                     v\n3. Vault issues student1 a Vault token\n                     |\n                     v\n4. Vault token contains consul-engine-admin policy\n                     |\n                     v\n5. Policy permits operations against consul\/*\n                     |\n                     v\n6. student1 requests consul\/creds\/student-role\n                     |\n                     v\n7. Vault reads student-role\n                     |\n                     v\n8. student-role references Consul policy student-kv\n                     |\n                     v\n9. Vault authenticates to Consul using its management token\n                     |\n                     v\n10. Vault asks Consul to create a new ACL token\n                     |\n                     v\n11. Consul attaches student-kv to that token\n                     |\n                     v\n12. Vault returns the short-lived token to student1\n                     |\n                     v\n13. Token can access student\/*\n                     |\n                     v\n14. Vault tracks the credential using a lease\n                     |\n                     v\n15. Lease expiration\/revocation causes the Consul token to be revoked\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      68. Vault CRUD Summary<\/h1>\n\n\n\n
      CREATE<\/h2>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='30m' \\\n  max_ttl='1h'\n<\/code><\/pre>\n\n\n\n
      READ<\/h2>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      UPDATE<\/h2>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='15m' \\\n  max_ttl='30m'\n<\/code><\/pre>\n\n\n\n
      LIST<\/h2>\n\n\n\n
      vault list consul\/roles\n<\/code><\/pre>\n\n\n\n
      DELETE<\/h2>\n\n\n\n
      vault delete consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      GENERATE DYNAMIC SECRET<\/h2>\n\n\n\n
      vault read consul\/creds\/student-role\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      69. Userpass Command Summary<\/h1>\n\n\n\n
      Enable Userpass<\/h2>\n\n\n\n
      vault auth enable userpass\n<\/code><\/pre>\n\n\n\n
      Create User<\/h2>\n\n\n\n
      vault write auth\/userpass\/users\/student1 \\\n  password='StudentLab@2026' \\\n  policies='consul-engine-admin' \\\n  token_ttl='1h' \\\n  token_max_ttl='4h'\n<\/code><\/pre>\n\n\n\n
      Read User<\/h2>\n\n\n\n
      Root\/admin only in this lab:<\/p>\n\n\n\n
      vault read auth\/userpass\/users\/student1\n<\/code><\/pre>\n\n\n\n
      Login<\/h2>\n\n\n\n
      vault login -method=userpass \\\n  username='student1' \\\n  password='StudentLab@2026'\n<\/code><\/pre>\n\n\n\n
      The current userpass API also supports reading users, updating users\/passwords\/policies, listing users, and deleting them.<\/p>\n\n\n\n
      \n\n\n\n
      70. Consul Secrets Engine Command Summary<\/h1>\n\n\n\n
      Enable Engine<\/h2>\n\n\n\n
      vault secrets enable consul\n<\/code><\/pre>\n\n\n\n
      Configure Connection<\/h2>\n\n\n\n
      vault write consul\/config\/access \\\n  address=\"127.0.0.1:8500\" \\\n  scheme=\"http\" \\\n  token=\"<CONSUL-MANAGEMENT-TOKEN>\"\n<\/code><\/pre>\n\n\n\n
      Create Role<\/h2>\n\n\n\n
      vault write consul\/roles\/student-role \\\n  consul_policies='student-kv' \\\n  ttl='30m' \\\n  max_ttl='1h'\n<\/code><\/pre>\n\n\n\n
      Read Role<\/h2>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      List Roles<\/h2>\n\n\n\n
      vault list consul\/roles\n<\/code><\/pre>\n\n\n\n
      Delete Role<\/h2>\n\n\n\n
      vault delete consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      Generate Credential<\/h2>\n\n\n\n
      vault read consul\/creds\/student-role\n<\/code><\/pre>\n\n\n\n
      These paths match the current Vault Consul secrets-engine API: configuration at consul\/config\/access<\/code>, role management at consul\/roles\/:name<\/code>, and credential generation at consul\/creds\/:name<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      71. Vault Policy Used in This Lab<\/h1>\n\n\n\n
      Complete file:<\/p>\n\n\n\n
      path \"consul\/*\" {\n  capabilities = [\n    \"create\",\n    \"read\",\n    \"update\",\n    \"delete\",\n    \"list\"\n  ]\n}\n\npath \"sys\/leases\/lookup\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/renew\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/renew\/*\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/revoke\" {\n  capabilities = [\"update\"]\n}\n\npath \"sys\/leases\/revoke\/*\" {\n  capabilities = [\"update\"]\n}\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      72. Why This Vault Policy Is Intentionally Broad<\/h1>\n\n\n\n
      The requirement for this particular lab is:<\/p>\n\n\n\n
      \n
      Give one user complete CRUD-style access to the Consul secrets engine.<\/p>\n<\/blockquote>\n\n\n\n
      Therefore:<\/p>\n\n\n\n
      path \"consul\/*\"\n<\/code><\/pre>\n\n\n\n
      is intentionally broad.<\/p>\n\n\n\n
      It also means the user could potentially change sensitive configuration underneath the Consul engine.<\/p>\n\n\n\n
      That makes this policy appropriate for:<\/p>\n\n\n\n
      training\nlabs\nexperimentation\nadministrative demonstrations\n<\/code><\/pre>\n\n\n\n
      but usually not<\/strong> appropriate for a normal application in production.<\/p>\n\n\n\n
      \n\n\n\n
      73. Safer Production-Style Vault Policy<\/h1>\n\n\n\n
      After students understand the broad policy, show them this safer version:<\/p>\n\n\n\n
      # Allow role management.\n\npath \"consul\/roles\" {\n  capabilities = [\"list\"]\n}\n\npath \"consul\/roles\/*\" {\n  capabilities = [\n    \"create\",\n    \"read\",\n    \"update\",\n    \"delete\"\n  ]\n}\n\n# Allow credential generation.\n\npath \"consul\/creds\/*\" {\n  capabilities = [\"read\"]\n}\n\n# Do NOT give the user access to:\n#\n# consul\/config\/access\n<\/code><\/pre>\n\n\n\n
      This illustrates an important Vault security principle:<\/p>\n\n\n\n
      Give the identity only the permissions it actually requires.\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      74. Student Verification Checklist<\/h1>\n\n\n\n
      A student has successfully completed the lab when all of these conditions are true:<\/p>\n\n\n\n
      [ ] vault version works\n\n[ ] consul version works\n\n[ ] Consul listens on 127.0.0.1:8500\n\n[ ] Consul ACL system has been bootstrapped\n\n[ ] Consul policy student-kv exists\n\n[ ] Vault listens on 127.0.0.1:8200\n\n[ ] Vault is initialized\n\n[ ] Vault is unsealed\n\n[ ] consul\/ secrets engine exists\n\n[ ] Vault can communicate with Consul\n\n[ ] consul-engine-admin Vault policy exists\n\n[ ] userpass auth method exists\n\n[ ] student1 exists\n\n[ ] student1 can login\n\n[ ] student1 receives consul-engine-admin\n\n[ ] student1 does not have root policy\n\n[ ] student1 cannot write to secret\/\n\n[ ] student1 can create student-role\n\n[ ] student1 can read student-role\n\n[ ] student1 can list roles\n\n[ ] student1 can update student-role\n\n[ ] student1 can delete student-role\n\n[ ] student1 can generate a Consul token\n\n[ ] generated token can write student\/*\n\n[ ] generated token can read student\/*\n\n[ ] generated token cannot write production\/*\n\n[ ] generated credential has a Vault lease\n\n[ ] lease can be renewed\n\n[ ] lease can be revoked\n\n[ ] revoked Consul token stops working\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      75. Troubleshooting \u2014 Vault Connection Refused<\/h1>\n\n\n\n
      Error:<\/p>\n\n\n\n
      connect: connection refused\n<\/code><\/pre>\n\n\n\n
      Check:<\/p>\n\n\n\n
      pgrep -a vault\n<\/code><\/pre>\n\n\n\n
      Check port:<\/p>\n\n\n\n
      ss -lnt | grep 8200\n<\/code><\/pre>\n\n\n\n
      Check log:<\/p>\n\n\n\n
      tail -50 \"$LAB_DIR\/vault.log\"\n<\/code><\/pre>\n\n\n\n
      Check:<\/p>\n\n\n\n
      echo \"$VAULT_ADDR\"\n<\/code><\/pre>\n\n\n\n
      It should be:<\/p>\n\n\n\n
      http://127.0.0.1:8200\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      76. Troubleshooting \u2014 Consul Connection Refused<\/h1>\n\n\n\n
      Check process:<\/p>\n\n\n\n
      pgrep -a consul\n<\/code><\/pre>\n\n\n\n
      Check port:<\/p>\n\n\n\n
      ss -lnt | grep 8500\n<\/code><\/pre>\n\n\n\n
      Check log:<\/p>\n\n\n\n
      tail -50 \"$LAB_DIR\/consul.log\"\n<\/code><\/pre>\n\n\n\n
      Check leader:<\/p>\n\n\n\n
      curl -s http:\/\/127.0.0.1:8500\/v1\/status\/leader\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      77. Troubleshooting \u2014 Consul ACL Bootstrap Fails<\/h1>\n\n\n\n
      If:<\/p>\n\n\n\n
      consul acl bootstrap\n<\/code><\/pre>\n\n\n\n
      reports that ACL bootstrapping has already occurred, you probably still have an existing Consul development server\/state.<\/p>\n\n\n\n
      For this disposable lab, stop Consul:<\/p>\n\n\n\n
      kill \"$(cat \"$LAB_DIR\/consul.pid\")\"\n<\/code><\/pre>\n\n\n\n
      Confirm:<\/p>\n\n\n\n
      pgrep -a consul || true\n<\/code><\/pre>\n\n\n\n
      Then restart the clean Consul development lab.<\/p>\n\n\n\n
      A Consul ACL environment can normally be bootstrapped only once.<\/p>\n\n\n\n
      \n\n\n\n
      78. Troubleshooting \u2014 Vault Permission Denied<\/h1>\n\n\n\n
      Check which token you are using:<\/p>\n\n\n\n
      vault token lookup\n<\/code><\/pre>\n\n\n\n
      Check policies:<\/p>\n\n\n\n
      vault token lookup -format=json \\\n  | jq '.data.policies'\n<\/code><\/pre>\n\n\n\n
      Expected for the student:<\/p>\n\n\n\n
      [\n  \"consul-engine-admin\",\n  \"default\"\n]\n<\/code><\/pre>\n\n\n\n
      Check capability:<\/p>\n\n\n\n
      vault token capabilities consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      79. Troubleshooting \u2014 Student Accidentally Still Has Root Access<\/h1>\n\n\n\n
      Check:<\/p>\n\n\n\n
      echo \"${VAULT_TOKEN:-not-set}\"\n<\/code><\/pre>\n\n\n\n
      If you see:<\/p>\n\n\n\n
      root\n<\/code><\/pre>\n\n\n\n
      then:<\/p>\n\n\n\n
      unset VAULT_TOKEN\n<\/code><\/pre>\n\n\n\n
      Login again:<\/p>\n\n\n\n
      vault login -method=userpass \\\n  username='student1' \\\n  password='StudentLab@2026'\n<\/code><\/pre>\n\n\n\n
      Then:<\/p>\n\n\n\n
      vault token lookup\n<\/code><\/pre>\n\n\n\n
      Make sure:<\/p>\n\n\n\n
      root\n<\/code><\/pre>\n\n\n\n
      is absent from the policies.<\/p>\n\n\n\n
      \n\n\n\n
      80. Troubleshooting \u2014 Dynamic Consul Credential Cannot Be Generated<\/h1>\n\n\n\n
      Check that the role exists:<\/p>\n\n\n\n
      vault read consul\/roles\/student-role\n<\/code><\/pre>\n\n\n\n
      Check the Consul policy name:<\/p>\n\n\n\n
      student-kv\n<\/code><\/pre>\n\n\n\n
      Check Vault’s logs:<\/p>\n\n\n\n
      tail -50 \"$LAB_DIR\/vault.log\"\n<\/code><\/pre>\n\n\n\n
      Check Consul logs:<\/p>\n\n\n\n
      tail -50 \"$LAB_DIR\/consul.log\"\n<\/code><\/pre>\n\n\n\n
      Typical causes are:<\/p>\n\n\n\n
      Vault cannot reach Consul\nVault has an invalid Consul management token\nstudent-kv Consul policy does not exist\nstudent-role is incorrectly configured\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      81. Troubleshooting \u2014 Generated Token Cannot Access student\/<\/code><\/h1>\n\n\n\n
      Make sure you are actually supplying the generated token:<\/p>\n\n\n\n
      test -n \"$DYNAMIC_CONSUL_TOKEN\" \\\n  && echo \"Token variable exists.\"\n<\/code><\/pre>\n\n\n\n
      Then:<\/p>\n\n\n\n
      CONSUL_HTTP_TOKEN=\"$DYNAMIC_CONSUL_TOKEN\" \\\n  consul kv put student\/test \"hello\"\n<\/code><\/pre>\n\n\n\n
      If that fails, verify that the Consul role was created with:<\/p>\n\n\n\n
      consul_policies=student-kv\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      82. Troubleshooting \u2014 Wrong Password Entered Several Times<\/h1>\n\n\n\n
      Vault includes user-lockout behavior for supported authentication methods including userpass<\/code>.<\/p>\n\n\n\n
      Repeated failed authentication attempts can temporarily result in immediate permission-denied responses.<\/p>\n\n\n\n
      For a classroom environment, encourage students to copy the lab password correctly:<\/p>\n\n\n\n
      StudentLab@2026\n<\/code><\/pre>\n\n\n\n
      rather than repeatedly guessing it.<\/p>\n\n\n\n
      \n\n\n\n
      83. Cleanup<\/h1>\n\n\n\n
      Because both servers are operating in development mode, cleanup is simple.<\/p>\n\n\n\n
      Remove sensitive shell variables:<\/p>\n\n\n\n
      unset DYNAMIC_CONSUL_TOKEN\nunset LEASE_ID\nunset CONSUL_HTTP_TOKEN\nunset CONSUL_MGMT_TOKEN\nunset VAULT_TOKEN\n<\/code><\/pre>\n\n\n\n
      Stop Vault:<\/p>\n\n\n\n
      kill \"$(cat \"$LAB_DIR\/vault.pid\")\" 2>\/dev\/null || true\n<\/code><\/pre>\n\n\n\n
      Stop Consul:<\/p>\n\n\n\n
      kill \"$(cat \"$LAB_DIR\/consul.pid\")\" 2>\/dev\/null || true\n<\/code><\/pre>\n\n\n\n
      Verify:<\/p>\n\n\n\n
      pgrep -a vault || true\n<\/code><\/pre>\n\n\n\n
      and:<\/p>\n\n\n\n
      pgrep -a consul || true\n<\/code><\/pre>\n\n\n\n
      Remove the lab files:<\/p>\n\n\n\n
      rm -rf \"$LAB_DIR\"\n<\/code><\/pre>\n\n\n\n
      Optionally remove the locally cached Vault CLI token created by vault login<\/code>:<\/p>\n\n\n\n
      rm -f \"$HOME\/.vault-token\"\n<\/code><\/pre>\n\n\n\n
      Unset:<\/p>\n\n\n\n
      unset LAB_DIR\nunset VAULT_ADDR\n<\/code><\/pre>\n\n\n\n
      Because development mode uses in-memory state, stopping the servers destroys the lab’s Vault and Consul runtime data.<\/p>\n\n\n\n
      \n\n\n\n
      84. What Students Should Remember<\/h1>\n\n\n\n
      Authentication<\/h2>\n\n\n\n
      Who are you?\n<\/code><\/pre>\n\n\n\n
      In this lab:<\/p>\n\n\n\n
      userpass\nusername = student1\npassword = StudentLab@2026\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Vault Authorization<\/h2>\n\n\n\n
      What are you allowed to do in Vault?\n<\/code><\/pre>\n\n\n\n
      Controlled by:<\/p>\n\n\n\n
      consul-engine-admin\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Vault Consul Role<\/h2>\n\n\n\n
      What type of Consul credential should Vault generate?\n<\/code><\/pre>\n\n\n\n
      Controlled by:<\/p>\n\n\n\n
      student-role\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Consul Authorization<\/h2>\n\n\n\n
      What can the generated token do inside Consul?\n<\/code><\/pre>\n\n\n\n
      Controlled by:<\/p>\n\n\n\n
      student-kv\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Dynamic Secret<\/h2>\n\n\n\n
      What credential did Vault dynamically create?\n<\/code><\/pre>\n\n\n\n
      Answer:<\/p>\n\n\n\n
      A short-lived Consul ACL token.\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Lease<\/h2>\n\n\n\n
      How does Vault track the lifecycle of that credential?\n<\/code><\/pre>\n\n\n\n
      Answer:<\/p>\n\n\n\n
      Using a Vault lease.\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      85. Final Architecture<\/h1>\n\n\n\n
                          +----------------------+\n                    |       student1       |\n                    +----------+-----------+\n                               |\n                               | username\/password\n                               v\n                    +----------------------+\n                    |   Vault Userpass     |\n                    +----------+-----------+\n                               |\n                               | authenticates\n                               v\n                    +----------------------+\n                    |    Vault Token       |\n                    |                      |\n                    | consul-engine-admin  |\n                    +----------+-----------+\n                               |\n                               | permits access\n                               v\n                    +----------------------+\n                    |  Consul Secret       |\n                    |  Engine: consul\/     |\n                    +----------+-----------+\n                               |\n                               | uses\n                               v\n                    +----------------------+\n                    |   student-role       |\n                    |                      |\n                    | Consul policy:       |\n                    | student-kv           |\n                    +----------+-----------+\n                               |\n                               | Vault talks to Consul\n                               v\n                    +----------------------+\n                    |      Consul          |\n                    |     ACL System       |\n                    +----------+-----------+\n                               |\n                               | dynamically creates\n                               v\n                    +----------------------+\n                    | Dynamic Consul Token |\n                    +----------+-----------+\n                               |\n                               | student-kv\n                               v\n                    +----------------------+\n                    | Consul KV            |\n                    |                      |\n                    | student\/*  -> ALLOW  |\n                    | other\/*    -> DENY   |\n                    +----------------------+\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      86. Master Lab Success<\/h1>\n\n\n\n
      If the entire lab works correctly, the following sequence has been proven:<\/p>\n\n\n\n
      Ubuntu\n  \u2193\nVault\n  \u2193\nuserpass\n  \u2193\nstudent1\n  \u2193\nVault Policy\n  \u2193\nConsul Secrets Engine\n  \u2193\nVault Consul Role\n  \u2193\nDynamic Consul ACL Token\n  \u2193\nRestricted Consul Permissions\n  \u2193\nVault Lease\n  \u2193\nRenew\n  \u2193\nRevoke\n  \u2193\nCredential becomes invalid\n<\/code><\/pre>\n\n\n\n
      That gives students an end-to-end introduction to Vault authentication, Vault authorization, the Consul dynamic secrets engine, Consul ACL authorization, dynamic credentials, TTLs, leases, renewal, and revocation<\/strong> in one coherent exercise.<\/p>\n\n\n\n
      \n\n\n\n
      Validation Notes<\/h1>\n\n\n\n
      This guide has been syntax-checked against the current official Vault 2.x<\/strong> and Consul 2.0.x<\/strong> documentation, including the current Userpass API, Consul secrets-engine API, Vault ACL capability model, Consul ACL bootstrap and policy commands, and Vault lease renew\/revoke commands. Vault’s current release notes identify 2.0.4<\/strong> as the August 4, 2026 fix release.<\/p>\n\n\n\n
      The lab intentionally uses only currently documented fields such as consul_policies<\/code>; older examples using legacy base64 policy<\/code>, older Consul token types, or deprecated role fields have been avoided. Vault’s current Consul API specifically identifies older policy<\/code> and policies<\/code> role parameters as deprecated in favor of the current Consul-policy model.<\/p>\n\n\n\n
      The commands have been validated against the current documentation rather than executed on your particular Ubuntu host, so the first run on your server should also be treated as the final environment-specific runtime validation.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Beginner-Friendly Hands-On Lab for Ubuntu Linux 1. Lab Objective In this lab, we will build the following environment from scratch: By the end of the lab, students… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1042","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1042","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1042"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1042\/revisions"}],"predecessor-version":[{"id":1043,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1042\/revisions\/1043"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}