stenio123

# All tokens within Vault have an associated TTL (Root is the exception, having "infinite" TTL).
# For long running services, Vault allows the creation of "periodic tokens".
# These are special types of tokens created for long running services - for example a Jenkins server. 
# We needed to accomodate the fact that every token in Vault needs to have a ttl, however we expect this service to be long 
# lived, therefore it allows us to create a special token that can be renewed indefinitely, allowing a Vault admin to have 
# different max_ttl strategies without impacting long running services. The "period" parameter will work as the TTL for the 
# token, which needs to be renewed within that period. If it doesn't, Vault will not accept requests using that token
# until it is renewed.

# Example, confidering default system max_ttl and default_ttl:

stenio123

# Log into your vault instance if you haven't already
vault login root
# Enable the transit secret engine
vault secrets enable transit
# Create a key
vault write -f transit/keys/my-key
# Read the key, nothing up my sleeves
vault read transit/keys/my-key
# Write some base64 encrypted data to the transit endpoint
vault write transit/encrypt/my-key plaintext=$(base64 <<< "my secret data")

stenio123

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

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

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

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

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

Vault Examples

Examples highligthing different Vault features.

To have a list of valid CLI flags, use

vault -h
vault <FEATURE> -h

HA Replication

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" ]
}