vault-kubernetes-workshop | HashiCorp Vault on @ GoogleCloudPlatform Kubernetes | Identity Management library

The first step is to install Vault. To install the Vault binary in the current working directory, run the install script. This will install Vault using the sethvargo/hashicorp-installer Docker container which verifies GPG signatures and checksums from the download. This represents a "best practices" installation for installing secure software like Vault. By verifying the signature of the SHASUMs and then verifying the SHASUMs themselves, we guarantee both the integrity of the download and ensure the binary has not been tampered with beyond it's original publishing. For added security, you can download and compile Vault yourself from source, but that is out of scope for this workshop. Cloud Shell does not persist things in /usr/local/bin or /usr/bin between sessions. As such, Vault will be installed in ~/bin. We recommend installing other binaries or software you need between sessions in this folder.
Vault requires a storage backend to persist its data. This workshop leverages Google Cloud Storage. Vault does not automatically create the storage bucket, so we need to create:. Cloud Storage bucket names must be globally unique across all of Google Cloud. The bucket will be named "${PROJECT}-vault-storage". For security purposes, it is not recommended that other applications or services have access to this bucket. Even though the data is encrypted at rest, it is best to limit the scope of access as much as possible.
Vault will leverage Google Cloud KMS to encrypt its unseal keys for auto-unsealing and auto-scaling purposes. We must create the KMS key in advance:.
Lastly, we need to configure our local Vault CLI to communicate with these newly-created Vault servers through the Load Balancer. Since we used custom TLS certificates, we'll need to trust the appropriate CA, etc. This will:.
Set VAULT_ADDR to the Load Balancer address
Set VAULT_CAPATH to the path of the CA cert created in previous steps for properly verifying the TLS connection
Set VAULT_TOKEN to the decrypted root token by decrypting it from KMS
Next we will explore techniques for retrieving static (i.e. non-expiring) credentials from Vault. The kv secrets engine is commonly used with legacy applications which cannot handle graceful restarts or when secrets cannot be dynamically generated by Vault.
Enable the KV secrets engine
Create a policy to read data from a subpath
Store some static username/password data in the secrets engine
Next we configure Vault to generate dynamic credentials. Vault can generate many types of dynamic credentials like database credentials, certificates, etc. For this example, we will leverage the GCP secrets engine to dynamically generate Google Cloud Platform CloudSQL MySQL users. This process can take up to 10 minutes to complete.
Create a CloudSQL database
Enable the database secrets engine
Configure the database secrets engine
Create a "role" which configures the permissions the SQL user has
Create a new policy which allows generating these dynamic credentials
Update the Vault Kubernetes auth mapping to include this new policy when authenticating