Made to work with Minikube and an existing Vault deployment (in default namespace).
Run as numbered, executing shell files and applying yaml files, or follow the walkthrough below.
Optionally deploy the test pod with kubectl apply -f test_pod.yaml
to see if works as designed.
NB: Requires Vault to be running, unsealed, and the Vault client to be authenticated.
Enable the kubernetes backend.
vault auth enable kubernetes
kubectl apply -f 1_vault_integration.yaml
This will create the following resources:
- An
application
namespace. - A
vault-reviewer
service account in thedefault
namespace (where Vault resides). - A
vault-auth
service account in theapplication
namespace (where the app resides). - A Cluster Role Binding, giving the
vault-reviewer
rights to auth delegation.
kubectl get secret $(kubectl get serviceaccount vault-reviewer -o json | jq -r '.secrets[0].name') -o json | jq -r '.data .token' | base64 -d - > token.txt
vault write auth/kubernetes/config \
[email protected] \
kubernetes_host=https://192.168.99.100:8443 \
kubernetes_ca_cert=@$HOME/.minikube/ca.crt
vault policy write application-kube-auth application-kube-auth.hcl
This configures the following policy:
path "secret/application/*" {
capabilities = ["read"]
}
path "secret/vault_test" {
capabilities = ["create", "read", "update", "delete", "list"]
}
Using the previously created policy and service accounts, we can now create a demo
role which we can use in the application.
vault write auth/kubernetes/role/demo \
bound_service_account_names=vault-auth \
bound_service_account_namespaces=application \
policies=application-kube-auth \
period=60s
Check if it's configured correctly:
vault read auth/kubernetes/role/demo
This application is configured to authenticate to Vault using its kubernetes token, write a secret, read it, and delete it (see vault_test.py
). It currently adheres to the policy defined in 4.1, but can of course do some unauthorized things as well :).
kubectl apply -f test_pod.yaml