Vault as the Connect CA

This is the hands-on lab for Section 11 (HashiCorp Vault Integration) of the Consul 101 course. A single Ubuntu VM runs a Vault dev server and a single-server Consul datacenter with ACLs already bootstrapped and the service mesh (Connect) enabled. You put Vault in charge of the two most sensitive pieces of Consul security: the certificate authority behind the mesh, and the ACL tokens that gate every request.

You will:

• Enable two Vault PKI secrets engines (a root and an intermediate), write the

Consul access policy, and point Consul's Connect CA at Vault with `consul connect ca set-config`, then prove the provider flipped from `consul` to `vault` while the mesh keeps working

• Enable Vault's Consul secrets engine and give it a scoped Consul token

(`acl = "write"`) so Vault can mint and revoke ACL tokens

• Map a Vault role to an existing Consul ACL policy so every token issued from

the role is born with exactly that policy attached

• Read a dynamic Consul ACL token out of Vault with `vault read consul/creds/<role>`,

confirm it is a real, scoped Consul token, and renew its lease

• Revoke the lease and watch Consul reject the token immediately, the property

that makes dynamic credentials so much safer than static ones

By the end you will have moved both the Connect CA key and Consul's ACL tokens into Vault, the exact integration pattern that underpins production Consul plus Vault deployments.