Manages a HashiCorp Vault cluster in Azure.

• Creates a cluster with X nodes
• Auto unseal with Azure Key Vault
• Load balanced with an Azure Application Gateway
• Lets Encrypt certificate for the cluster
• Linux VM as a Bastion host
• All initial secrets stored in Azure Key Vault

These are generated by Terraform and stored in Azure Key Vault by repo iac-azure-vault-components

• Handled by user_data module
  • custom_data, used by cloud-init
  • vmss instance will have a log at /var/log/cloud-init-output.log with output from the custom_data script
  • https://learn.microsoft.com/en-us/azure/virtual-machines/linux/cloud-init-troubleshooting
  • https://learn.microsoft.com/en-us/azure/virtual-machines/linux/cloud-init-deep-dive?source=recommendations
• Uses MSI to allow auto-join and auto-unseal
• Requires one time manual un-seal after provisioning - need a bastion or jump box to access the scale set (vault operator init)

• Vault must be initialized after intallation, and unsealed. Vault will use Azure key vault to auto unseal in the future

# vault cli doesn't recoginize the ca cert?
export VAULT_SKIP_VERIFY=true

# copy the unseal keys and root token - one time operation per cluster after provisioning
# these should be stored securely, like in an azure keyvault
azureuser@hcv-Tbngw-vmss-nonprod-eastus000000:~$ vault operator init
Recovery Key 1: 5Dq66YoWKqYhU0EnKj4d2OJqHD34Z4gsExqtol83XYnV
Recovery Key 2: /Kgchx1ozP4HzSpqBHggr8tR8kU2clpg/yXLVhurKqhB
Recovery Key 3: ecbDB4ZDeZPy+Yoqz3ZYm/kHDixlm8FVBgoxKdnWOMuZ
Recovery Key 4: MWNaAkFVdPJ6WWUl/UN0m7kqVUXV5thNyg3UIxxG5sFo
Recovery Key 5: 56yNsfDzLaTU1UsA5FzsEZxRvgQ5zghRlR0G5QeSGhiH

Initial Root Token: export VAULT_TOKEN=hvs.o9npdWL24GjRzsxVYlVDEMwn

Success! Vault is initialized

Recovery key initialized with 5 key shares and a key threshold of 3. Please
securely distribute the key shares printed above.

# exec unseal 3 times, using 3 of the 5 unseal keys from above
# on the 3rd one the "sealed" status should change to false
vault operator unseal


curl --insecure https://localhost:8200
curl --insecure https://vault.dev.diehlabsplatform.com

• Idea:
  • Use a GRS storage account
  • VMSS instances will have permission to connect via NFS or other means?
  • The VM MSI will have permissions in Vault to read raft data
  • The "init script" for the VMs will configure a cron job that will perform a raft snapshot and copy the data to the storage container

• Migrate from gitlab to azure for terraform state
• Enable "dead server cleanup"
• Use remote state to fetch DNS details like dns parent group rg name, etc
• Use avail zones for agw/lb
• Use avail zones for vm scale set
• Use resource_vesionless_id for akv secrets
• to limit traffic to vault nodes to be from the load balancer, update api_addr to the IP of the lb in modules/user_data/templates/install_vault.sh.tpl
• add monitoring
• Backup vault data https://developer.hashicorp.com/vault/tutorials/standard-procedures/sop-backup#automated-backup-procedures
• change script in user_data module to a complete cloud-init.conf?
  • download hashicorp vault binary
  • configure vault
  • start and autoenable vault service
  • copy tls certificates from akv https://learn.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-automate-vm-deployment#inject-certificates-from-key-vault

CHANGE APP GW FRONTEND CONFIG FROM PRIVATE TO PUBLIC (LISTENERS) REMOVE HCV-VAULT-LB NSG RULE "DENYALLINBOUND_INTERNET?

No outputs.