Docker Compose - Hashicorp's Vault and Consul Part B (EaaS, dynamic secrets, leases, and revocation)

bogotobogo.com site search:

Note

Continued from Docker Compose - Hashicorp's Vault and Consul Part A (install vault, unsealing, static secrets, and policies), in this post, we'll see additional features of Vault such as EaaS (Encryption as a Service), dynamic secrets, leases, and revocation.

At the end of this post, we'll have the following directories/files:

More files will show up if we expand the directories. Most of them were created by Vault.

Encryption as a Service

Before we look at dynamic secrets, we may want to review the Transit backend, which can be used as an "encryption as a service" for:

Encrypting and decrypting data "in-transit" without storing it inside Vault.
Easily integrating encryption into our application workflow.

The primary use case for transit is to encrypt data from applications while still storing that encrypted data in some primary data store. This relieves the burden of proper encryption/decryption from application developers and pushes the burden onto the operators of Vault.

Let's go back to the bash session in the container, enable the Transit secrets engine:

bash-4.4# vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/

Then, configure a named encryption key:

bash-4.4# vault write -f transit/keys/foo
Success! Data written to: transit/keys/foo

Usually each application has its own encryption key.

Encrypt:

bash-4.4# vault write transit/encrypt/foo plaintext=$(base64 <<< "my precious")
Key           Value
---           -----
ciphertext    vault:v1:7FEiJbqZwbo7cCBopwO2OFbXeCYG/0WlinU77oihPiDfhkN+t0v55Q==

Decrypt:

bash-4.4# vault write transit/decrypt/foo ciphertext=vault:v1:7FEiJbqZwbo7cCBopwO2OFbXeCYG/0WlinU77oihPiDfhkN+t0v55Q==
Key          Value
---          -----
plaintext    bXkgcHJlY2lvdXMK

Decode:

bash-4.4# base64 -d <<< "bXkgcHJlY2lvdXMK"
my precious

Now we can test with UI:

Dynamic Secrets

As we already know, Vault supports a number of dynamic secret backends for generating secrets dynamically when needed. For example, with the AWS and Google Cloud backends, we can create access credentials based on IAM policies. The Databases backend, meanwhile, generates database credentials based on configured roles.

Dynamic Secrets are generated on demand. They have limited access based on role, and they are leased for a period of time. They can be revoked and come with an audit trail.

As an example, let's look at how to generate AWS credentials using the AWS backend. Let's enable the AWS secrets backend:

bash-4.4# vault secrets enable -path=aws aws
Success! Enabled the aws secrets engine at: aws/

Authenticate with our own AWS credentials:

# vault write aws/config/root access_key=A...A secret_key=P...7
Success! Data written to: aws/config/root

Then, create a role:

bash-4.4# vault write aws/roles/ec2-read arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
Success! Data written to: aws/roles/ec2-read

Here, we created a new role based on AmazonEC2ReadOnlyAccess, which is an AWS-managed policy. As the name suggests, it give users read-only access to the EC2 console; they cannot perform any actions or create new resources. We can also use an inline policy to create a custom role based on our individual needs.

Create a new set of credentials:

bash-4.4# vault read aws/creds/ec2-read
Key                Value
---                -----
lease_id           aws/creds/ec2-read/8c26c68b-627b-36f4-8319-d6aaaf8f3b26
lease_duration     768h
lease_renewable    true
access_key         AKIAQV57YS3YIBOZLJUS
secret_key         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
security_token     <nil>

We should now be able to see the user within the "Users" section on the IAM console on AWS:

Leases and Revocation

In this section we'll learn how to define a custom lease period and revoke a secret before the end of that period.

Let's create a new AWS role:

bash-4.4# vault write aws/roles/foo \
>     policy=-< {
>   "Version": "2012-10-17",
>   "Statement": [ { "Effect": "Allow", "Action": "ec2:*", "Resource": "*" } ]
> }
> EOF
Success! Data written to: aws/roles/foo

bash-4.4# vault read aws/creds/foo
Key                Value
---                -----
lease_id           aws/creds/foo/f14d1c46-6b7e-0658-bdab-4adc3cf67083
lease_duration     768h
lease_renewable    true
access_key         AKIAQV57YS3YEWJ6FBXE
secret_key         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
security_token     <nil>

Note that we have the lease_duration!

If we want the lease period for all AWS IAM dynamic secrets to be 30 minutes:

bash-4.4# vault write aws/config/lease lease=1800s lease_max=3600s
Success! Data written to: aws/config/lease

Since we set the lease_max to 3600s, we'll be able to renew the lease once.

For a revoking example, let's create a new credential:

bash-4.4# vault read aws/creds/foo
Key                Value
---                -----
lease_id           aws/creds/foo/5b586c22-4192-5111-af7d-804a4aacfa2b
lease_duration     30m
lease_renewable    true
access_key         AKIAQV57YS3YINO5YUC3
secret_key         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
security_token     <nil>

To revoke this credential, we may want to grab the lease_id and then run the following:

bash-4.4# vault lease revoke aws/creds/foo/5b586c22-4192-5111-af7d-804a4aacfa2b
Success! Revoked lease: aws/creds/foo/5b586c22-4192-5111-af7d-804a4aacfa2b

To revoke all AWS creds:

bash-4.4# vault revoke -prefix aws/
WARNING! The "vault revoke" command is deprecated. Please use "vault lease
revoke" instead. This command will be removed in Vault 0.11 (or later).

Success! Revoked any leases with prefix: aws/

Refs