SecretEngine

Static vs Dynamic Secrets

Secrets never expire
Required by legacy apps
Secrets are often shared among team members -> no accountability
Secrets are valid 24/7
Frequently the target for penetrators
Secrets are rarely rotated
Manual process
Secrets tend to live perpetually -> result of technical debt, employee turnover, ...

Create secrets on-demand
Each secret has an associated leases
Each leases determines when and how a secret expires
Secret is revoked in both Vault and at the origin
Control if a secret/token can be renewed with granularity
Allow secrets to expire automatically or manually revoked when required
Some Examples:
- CI/CD pipeline access to public cloud environments
- Elevated Account for Vulnerability Scanning
- Privileged access for administrators
- Database credentials for applications

are components that can store, generate, or encrypt data
- Many secret engines can be enabled in Vault
- You can even enable multiple instances of the same secret engine
- Secrets engines are plugins that extend the functionality of Vault
Secret engines are enabled and isolated at a path
- All interactions with secret engines are done using the path
- Path must be unique

Use Vault to generate and manage the lifecycle of crednetials on-demand
No more sharing credential
- Credentials get revoked automatically at the end of its lease
- Audit trail can identify points of compromise
Use policies to control the access based on client's role
Available Secret Engines: Active Directory, AliCloud, AWS, Azure, Consul, Cubbyhole, Database, Identity, Google Cloud, Google Cloud KMS, Key management, KMIP, Kubernetes, KV, MongoDB Atlas, Nomad, LDAP, PKI, RabbitMQ, SSH, Terraform Cloud, TOTP, Transform, Transit, Venafi
- KV: version 1 and 2
- Database: Cassandra, Couchbase, Elasticsearch, HanaDB, InfluxDB, MongoDB, MongoDB Atlas, MSSQL, MySQL/MariaDB, Oracle, PostgreSQL, Redshift, Snowflake, Custom
- Key Management, Azure Key Vault, AWS KMS, GCP KMS

Cubbyhole and Identity are enabled by default (can't disable)
Any other secret engine must be enabled
Secrets engine are enabled and isolated at a path, paths do not need to match the secret engines name or type
Privileged user: vault admin, security team
- Enable the secret engine
- Configure the connection to the backend platform (AWS, Database, ...)
- Create roles that define permissions to the backend platform
- Create policies that grant permission to read from the secrets engine
Vault Clients
- Read a set of credentials using token and associated policy
- Renew the lease before its expiration if needed (or permitted)
- Renew the token if needed (or permitted)
Commands
- vault secrets {disable|enable|list|move|tune}
- vault secrets enable aws
- vault secrets tune -default-lease-ttl=72h pki/
- vault secrets list -detailed
- vault secrets enable -path=developers kv-v2
- vault secrets enable -description="my kv" kv

vault read aws/creds/data-consultant
- data-consultant: role created
- command will return access_key and secret_key
vault read database/creds/oracle-reporting
- oracle-reporting is the created role
- command will return username and password to access database

AWS: vault write aws/config/root access_key=$Access_key secret_key=$secret_key region=$region
Database: vault write database/config/prod-database plugin_name=mysql-aurora-database-plugin connection_url=$ConnectioN_string allowed_roles=$role username=$username password=$password

Key/Value secrets engine is used to store static secrets
- Ther are two versions: v2 (kv-v2) is versioned but v1 (v1) is not
- Access to KV paths are enforced via policies (ACL)
Secrets written to KV secrets engine are encrypted usin 256-bit AES
Secrets ar stored as key-value pairs at a defined path, e.g. secret/applications/web01
- Writing a new secret will replace the old value
- Writing a new secret requires the create capability
- Updating/overwriting a secret to an existing path requires update capability
When running Vault in -dev mode, vault enables a KV v2 secrets engine at the secret/ path by default

vault kv put kv/app/db @secret.json

#secrets.json
{
  "pass": "123",
  "user": "admin",
  "api": "89793duodsoi"
}

vault kv get kv/app/db
vault kv rollback -version=1 kv/app/db
vault kv patch kv/app/db user=hat: update 1 kv pair
vault kv get -format=json kv/app/db: output in json format, default is table
vault kv get -version=3 kv/app/db: return specific version, default is the latest version
delete on KV V1 is a delete - the data is destroyed. KV V2 delete is a soft delete - data is not destroyed which can be restored with a undelete/rollback action
a destroy (only KV V2) is a permanent action - detroyed on disk, cannot be restored except for Vault/Consul restore action

To support versioning, KV V2 adds metadata to key value entries which is used to determine creation date, the version of the secret, etc.
Introduces two prefixes that must be accounted for when referencing secrets and/or metadata (for API and when writing Vault Policies)
- cloud/data - data is where the actual KV data is stored
- cloud/metadata - the metadata prefix stores our metadata about a secret

is used to store arbitrary secrets
enabled by default at the cubbyhole/ path
Its lifetime is linked to the token used to write the data
- No concept of TTL or refresh interval for values in cubbyhole
- Even the root token cannot read the data if it wasn't written by the root
Cubbyhole secrets engine cannot be disabled, moved or enabled multiple times

curl --header "X-Vault-Token: $token" --request POST --data '{"certificaiton": "hcvop"}' https://domain.com/v1/cubbyhole/training
curl --header "X-Vault-Token: $token" https://domain.com/v1/cubbyhole/training

Instead of sending secrets over the network unencrypted, can use cubbyhole's response wrapping feature
Enables the retrieval of secrets from a path and Vault will store them inside of another token's cubbyhole
- This token is called the wrapping token
- The wrappin token is temporary and limited by TTL
- It is also a single-use token
The wrapping token can be sent across the network and the user can unwrap the token to retrieve the real data (secrets)
Benefits of response wrapping
- privacy by ensurin that any secret transmited across the network is not the actual secret
- malfeasance detection by ensuring only a single party can unwrap the token and gain access to the secrets (because it's a single-use token)
- limitation of the lifetime of the secret exposure because the wrapping token has a defined TTL
vault kv get -wrap-ttl=5m secrets/certification/hvcop: will get a wrap token instead of the actual secrets
vault token lookup $wraptoken: see details about the wrap token

vault unwrap $wrapping_token
or
export VAULT_TOKEN=$wrapping_token vault unwrap
or
vault login $wrapping_token
vault unwrap

Last updated 1 year ago