High Availability - The Vault cluster will be provisioned in multi-server mode for high availability.
Google Cloud Storage Storage Backend - Vault's data is persisted in Google Cloud Storage.
Production Hardening - Vault is configured and deployed based on the guidance found in the production hardening guide.
Auto Initialization and Unsealing - Vault is automatically initialized and unsealed at runtime. Keys are encrypted using Cloud KMS and stored on Google Cloud Storage.
Tutorial
Create a New Project
In this section you will create a new GCP project and enable the APIs required by this tutorial.
In this section you will provision a three node Kubernetes cluster using Google Kubernetes Engine with access to the vault-server service account across the entire cluster.
Warning: Each node in the vault Kubernetes cluster has access to the vault-server service account. The vault cluster should only be used for running Vault. Other workloads should run on a different cluster and access Vault through an internal or external load balancer.
Provision IP Address
In this section you will create a public IP address that will be used to expose the Vault server to external clients.
In this section you will create the vault statefulset used to provision and manage two Vault server instances.
Create the vault statefulset:
kubectl apply -f vault.yaml
service "vault" created
statefulset "vault" created
At this point the multi-node cluster is up and running:
kubectl get pods
NAME READY STATUS RESTARTS AGE
vault-0 2/2 Running 0 1m
vault-1 2/2 Running 0 1m
Automatic Initialization and Unsealing
In a typical deployment Vault must be initialized and unsealed before it can be used. In our deployment we are using the vault-init container to automate the initialization and unseal steps.
kubectl logs vault-0 -c vault-init
2018/11/03 22:37:35 Starting the vault-init service...
2018/11/03 22:37:35 Get https://127.0.0.1:8200/v1/sys/health: dial tcp 127.0.0.1:8200: connect: connection refused
2018/11/03 22:37:45 Vault is not initialized. Initializing and unsealing...
2018/11/03 22:37:53 Encrypting unseal keys and the root token...
2018/11/03 22:37:53 Unseal keys written to gs://vault-1541283682815-vault-storage/unseal-keys.json.enc
2018/11/03 22:37:53 Root token written to gs://vault-1541283682815-vault-storage/root-token.enc
2018/11/03 22:37:53 Initialization complete.
2018/11/03 22:37:55 Unseal complete.
2018/11/03 22:37:55 Next check in 10s
2018/11/03 22:38:05 Vault is initialized and unsealed.
2018/11/03 22:38:05 Next check in 10s
The vault-init container runs every 10 seconds and ensures each vault instance is automatically unsealed.
Health Checks
A readiness probe is used to ensure Vault instances are not routed traffic when they are sealed.
Sealed Vault instances do not forward or redirect clients even in HA setups.
Expose the Vault Cluster
In this section you will expose the Vault cluster using an external network load balancer.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
vault-load-balancer LoadBalancer XX.XX.XXX.XXX <pending> 8200:31805/TCP,8201:32754/TCP
Smoke Tests
Source the vault.env script to configure the vault CLI to use the Vault cluster via the external load balancer:
source vault.env
Get the status of the Vault cluster:
vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 0.11.4
Cluster Name vault-cluster-46821b83
Cluster ID dcd56552-27d0-fa18-4ccc-25b252464971
HA Enabled true
HA Cluster https://XX.XX.X.X:8201
HA Mode standby
Active Node Address https://XX.XXX.XXX.XX:8200
请发表评论