Skip to content
This repository has been archived by the owner on Dec 31, 2022. It is now read-only.
/ vault-init Public archive

Automate the initialization and unsealing of @hashicorp Vault on @GoogleCloudPlatform

License

Notifications You must be signed in to change notification settings

sethvargo/vault-init

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

28 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

vault-init

The vault-init service automates the process of initializing and unsealing HashiCorp Vault instances running on Google Cloud Platform.

After vault-init initializes a Vault server it stores master keys and root tokens, encrypted using Google Cloud KMS, to a user defined Google Cloud Storage bucket.

Usage

The vault-init service is designed to be run alongside a Vault server and communicate over local host.

You can download the code and compile the binary with Go. Alternatively, a Docker container is available via the Docker Hub:

$ docker pull sethvargo/vault-init

To use this as part of a Kubernetes Vault Deployment:

containers:
- name: vault-init
  image: registry.hub.docker.com/sethvargo/vault-init:0.1.2
  imagePullPolicy: Always
  env:
  - name: GCS_BUCKET_NAME
    value: my-gcs-bucket
  - name: KMS_KEY_ID
    value: projects/my-project/locations/my-location/cryptoKeys/my-key

Configuration

The vault-init service supports the following environment variables for configuration:

  • CHECK_INTERVAL ("10s") - The time duration between Vault health checks. Set this to a negative number to unseal once and exit.

  • GCS_BUCKET_NAME - The Google Cloud Storage Bucket where the Vault master key and root token is stored.

  • KMS_KEY_ID - The Google Cloud KMS key ID used to encrypt and decrypt the vault master key and root token.

  • VAULT_SECRET_SHARES (5) - The number of human shares to create.

  • VAULT_SECRET_THRESHOLD (3) - The number of human shares required to unseal.

  • VAULT_AUTO_UNSEAL (true) - Use Vault 1.0 native auto-unsealing directly. You must set the seal configuration in Vault's configuration.

  • VAULT_STORED_SHARES (1) - Number of shares to store on KMS. Only applies to Vault 1.0 native auto-unseal.

  • VAULT_RECOVERY_SHARES (1) - Number of recovery shares to generate. Only applies to Vault 1.0 native auto-unseal.

  • VAULT_RECOVERY_THRESHOLD (1) - Number of recovery shares needed to trigger an auto-unseal. Only applies to Vault 1.0 native auto-unseal.

  • VAULT_SKIP_VERIFY (false) - Disable TLS validation when connecting. Setting to true is highly discouraged.

  • VAULT_CACERT ("") - Path on disk to the CA file to use for verifying TLS connections to Vault.

  • VAULT_CAPATH ("") - Path on disk to a directory containing the CAs to use for verifying TLS connections to Vault. VAULT_CACERT takes precedence.

  • VAULT_TLS_SERVER_NAME ("") - Custom SNI hostname to use when validating TLS connections to Vault.

Example Values

CHECK_INTERVAL="30s"
GCS_BUCKET_NAME="vault-storage"
KMS_KEY_ID="projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/key"

IAM & Permissions

The vault-init service uses the official Google Cloud Golang SDK. This means it supports the common ways of providing credentials to GCP.

To use this service, the service account must have the following minimum scope(s):

https://www.googleapis.com/auth/cloudkms
https://www.googleapis.com/auth/devstorage.read_write

Additionally, the service account must have the following minimum role(s):

roles/cloudkms.cryptoKeyEncrypterDecrypter
roles/storage.objectAdmin OR roles/storage.legacyBucketWriter

For more information on service accounts, please see the Google Cloud Service Accounts documentation.