6. Why this presentation? What to expect?
● Not pretending to be an expert just sharing what worked/what didn’t and hopefully
save some time for some of you
● Technical details and references
● Slides will be available online - you don’t have to remember/photo/screenshot
everything
7.
8. I’m Andrey
● Enjoying life as technology
specialist, father and endurance
athlete
● 10+ years in the industry
● Writing tools
● Fixing automation, projects and
organisations
● Meetups/conferences organizer
● Speaker
● Trainer
● Certified this and that
9. Terraform
● Infrastructure as code
● Execution plans
● Resource graph
● Change automation
● Open Source modules
● Providers for almost everything
10. Vault
● Centrally Manage Secrets to Reduce Secrets Sprawl
● Shift from static secrets to short-time dynamically
generated ones
● Avoid shared secrets thus better audit trail
● Protect Sensitive Data Across Clouds and Private
Data Centers
● Break glass procedure
11. Where do we start?
Collect requirements and clarify context
12. Questions to ask - deployment and operations
● Where to deploy? VM? Container? Baremetal?
● Patch or scratch?
● How to access? VPN? Public? Service mesh?
● How to unseal?
● How to get in initial secrets? (Ex. TLS)
● What storage is available?
● Where to stream logs?
● Where to stream telemetry?
● How to extract audit files?
● Multi-datacenter?
● One per env or one for all?
13. Look for best practices and templates
● https://registry.terraform.io/modules/hashicorp/vault/aws/0.0.9/submodules/vault
-cluster
● https://www.gruntwork.io/infrastructure-as-code-library/v0.13.3/terraform-aws-va
ult/modules/vault-cluster
● https://github.com/hashicorp/vault-helm
● https://learn.hashicorp.com/vault/operations/ops-reference-architecture
14. Vault production (min) readiness checklist
● TLS termination
● Vault HA storage - ACL and encryption
● Local storage encryption
● Auto-unseal using KMS
● Stripped down image, infra as code,
encryption, minimal exec rights
● No ssh or other kind of remote access, NACL
for outgoing traffic
● IDS
● Backups and DR
● Logs and telemetry export from the node
● Audit on, sync audit files to remote storage,
integrity check for audit files
● Sync audit files to archive
● MFA delete on for archive buckets
● Audit files parsing and anomaly detection
● Availability/performance monitoring and
alerting
More here https://learn.hashicorp.com/vault/operations/production-hardening
17. To start configuring Vault via Terraform we need...
● Vault URL configured as VAULT_ADDR env variable
● Vault token (root token will do for the start but revoke it afterwards together with the
rest of the root tokens)
● A good idea what are you after…
More here https://www.youtube.com/watch?v=fOybhcbuxJ0 and here
https://www.terraform.io/docs/providers/vault/index.html
21. You probably need more than one...
● Humans - operators and developers
● Machines - CI/CD, bots, etc
● Things - Apps, Infra etc
A good idea is to use MFA for humans, limit from where
auth methods could be invoked
22. Auth -> Role -> Token with policy
Ex.
LDAP -> LDAP backend Group -> Token with
policy
23. LDAP
● Leverages existing IAM setup
● Delegates credentials validation
● Used my humans
● Would be a good idea to simplify login procedure for your users
More here https://www.vaultproject.io/docs/auth/ldap.html
26. Policy
data "vault_policy_document" "example" {
rule {
path = "secret/*"
capabilities = ["create", "read", "update", "delete", "list"]
description = "allow all on secrets"
}
}
resource "vault_policy" "example" {
name = "example_policy"
policy = "${data.vault_policy_document.example.hcl}"
}
https://www.terraform.io/docs/providers/vault/d/policy_document.html
27. Policy
● You will need a policy to manage policy...
● Deny by default
● Do not have to match LDAP group name but easier for users if it
does
● Member of multiple groups gets multiple policies
More here https://learn.hashicorp.com/vault/getting-started/policies
28. Things to consider
● token_no_default_policy
● token_bound_cidrs
● token_ttl
● token_max_ttl
29. AppRole if you really have to...
● If you don’t have a better way
● Mostly used for CI
● Initial secret issue
● No good way to audit access
More here https://www.vaultproject.io/docs/auth/approle.html
51. Database creds
● Creation and revocation statements are hard
● If not done right Vault won’t be able to revoke creds
● Consider RDS IAM auth where possible
52. Secrets rotation
DB_SECRET_ENGINE_MOUNTS=$(vault secrets list -format=json | jq -r '. | to_entries[] | select(.value.type |
startswith("database")) | .key')
for DB_SECRET_ENGINE_MOUNT in ${DB_SECRET_ENGINE_MOUNTS}; do
DB_CONNECTION_NAMES=$(vault list -format=json ${DB_SECRET_ENGINE_MOUNT}config | jq --raw-output .[])
for DB_CONNECTION_NAME in ${DB_CONNECTION_NAMES}; do
vault write -force ${DB_SECRET_ENGINE_MOUNT}rotate-root/${DB_CONNECTION_NAME}
done
done
53. Secrets rotation
terraform taint aws_iam_access_key.iam_auth
terraform taint aws_iam_access_key.secret_engine
terraform apply
It is possible to do the same via API but then Terraform gets confused
https://www.vaultproject.io/api-docs/secret/aws/#rotate-root-iam-credentials
Note! Keys are still in Terraform state - encrypt state storage and state itself!
55. KV state issue
● Terraform provider for Vault in some cases(?) does not re-read KV and newly added
values are not readable/found
● terraform state rm data-source
data "vault_generic_secret" "rundeck_auth" {
path = "secret/rundeck_auth"
}
provider "rundeck" {
url = "http://rundeck.example.com/"
auth_token = "${data.vault_generic_secret.rundeck_auth.data["auth_token"]}"
}
56. Final thoughts
● Vault introduction is a journey
● Doing it as code is the most safe way available
● Re-use and share where/when possible
● There is still some glue needed here and there
● We need to build best practices - keep learning, keep sharing