Skip to content

Hetzner Vault (new vault)

whttps://github.com/Attracs/docker-hashicorp-vault/tree/main/hetzner-vault

Stable: New Vault GCP service account: cc-vault-stable@attracs-services-195009.iam.gserviceaccount.com New Vault vault role: production-servers

Why is HAProxy included in the docker-compose.yml? I don't know unfortunately. It was included in the old stable setup, I just copied it.

Expected behaviour of new Vault configuration updates

  1. Updates to Vault configuration are applied immediately by Vault.
  2. Applications that use the modern way of fetching Vault secrets can, but might not also be able to refresh vault configurations on-the-fly.
    1. Example of this is TMS applications: config-diff-vault Supervisor command is able to fetch the latest Vault configurations and will tell you the new configurations but the application itself fetches all of the necessary Vault configurations during boot and saves them to memory. Thus you have to restart applications to apply any changes made during an application's uptime.

Updating Vault

tL;DR: * Vault updates should be first tested in Dev, then they should be applied to actual use in Nightly and only when Nightly tests look good it should be updated to Stable.

Longer explanation: 1. Updates that can break the Vault, like updating Vault's major version or configuration changes that may negatively affect the use of Vault, like modifying or enabling new authentication methods should be first tested in Dev. 2. Previously tested changes in Dev should be then tested in Nightly. 1. Also new changes that are more minor are first tested in Nightly. 3. Lastly new changes are updated to Stable.

Dev

You can run a mostly local-setup dev-mode Vault by running the hetzner-vault/dev/ Terraform (TODO, Terraform creates a GCS bucket) and docker-compose up -d

Nightly

In order to use the Nightly Vault secrets for an application, you need an instance and a Vault-whitelisted service account attached to the instance in the correct project. This is because the service account that is attached to the Hetzner Vault only has access to a single project, in which it lists and reads all of the service accounts and instances in the project and determines what access each instance and service account should have based on those listings and comparing it to the Vault roles.

Stable

Using the Stable secrets also requires an instance and a Vault-whitelisted service account attached to the instance in the correct project.

Subpages