stenio123

cat vault_audit.log |  jq 'select(.request.path | startswith("secret"))'

stenio123

New test

# Mount database backend
vault mount database

# Configure MySQL connection
vault write database/config/mysql \
    plugin_name=mysql-legacy-database-plugin \
    connection_url="vaultadmin:vaultadminpassword@tcp(127.0.0.1:3306)/" \
    allowed_roles="readonly"

stenio123

vault list database/config
vault read database/config/postgres
vault list database/roles
vault read database/roles/readonly

# Step 0: Enable dynamic database credential service
vault secrets enable database

# Step 1: Configure connection String

stenio123

Vault and Long Running Apps

Solving Secure Token Introduction

Assuming the applications have a client token, Chef cookbooks can leverage the Vault Ruby gem, direct API calls, native language integrations or the Vault client installed in the VM.

Traditionally, to deliver credentials to retrieve this client token, the Trusted Entity model is used. This is great when deploying in the cloud (AWS, Azure, GCP), using Kubernetes or Jenkins as part of a CI/CD pipeline.

However for applications with no guarantee of ever being redeployed, but that have Chef agents running at a recurring interval, there are at least two potential approaches:

---

stenio123

Enable AppRole

vault enable approle

Create role, and specify number of times SecretId can be used

vault write auth/approle/role/my-role     secret_id_ttl=10m     token_num_uses=10     token_ttl=20m     token_max_ttl=30m     secret_id_num_uses=40

stenio123

1. Clone git repository:

git clone git@github.com:stenio123/vault-ruby.git

2. Move to desired branch:

git checkout added-namespaces

stenio123

PKI Secret Engine

Create Limited Policy and Token for this demo

cat > pki.policy <<EOA
# Enable secrets engine
path "sys/mounts/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

stenio123

Cubbyhole Single Use Secret

By leveraging the Cubbyhole secret engine, we can store a secret that only one token can retrieve. Once that token is expired or revoked, the secret is gone. When creating the token, you can limit number of uses.

# Creates token that will be shared. It will be used once to write a secret, second time to read then it is revoked
vault token create -use-limit=2 -policy=default -metadata="name=stenio"
# Output -<TOKEN>

stenio123

Vault Namespaces Demo

Vault Namespaces supports a variety of ways of interacting with Vault.

# Config
vault namespace create marketing

echo '
path "secret/*" {
    capabilities = ["create", "read", "update", "delete", "list", "sudo"]

stenio123

# start vault in dev mode
VAULT_UI=true vault server -dev -dev-root-token-id="password"

# write some secrets for our example usage
curl --request POST \
     --silent \
     --header "X-Vault-Token: password" \
     --header "Content-Type: application/json" \
     --data '{ "options": { "cas": 0 }, "data": { "username": "administrator", "password": "hunter2" } }' \
     http://127.0.0.1:8200/v1/secret/data/dev | jq '.'