
Today, I had the opportunity to learn about scaling secrets management using Vault. While I won't go into detail about our previous approach to save some embarrassment, I will say that it didn't align with the core principles of Vault. However, one of my colleagues addressed security risks by implementing Vault's dynamic secret features in our cicd pipelines. This involved adding various authentication methods and configuration bits, which gave me a better understanding of how Vault was intended to be used. As I continue to learn more about it, I am continually impressed by the thoughtful design behind it. Kudos to the HashiCorp team, as well as my team for digging deeper into Vault!

#### Jenkins

We created a test CICD pipeline consisting of the following steps:

- login to Vault with github method (github token)
- sleep for 10 seconds (to wait until queued api calls are processed)
- make a sample api call to AWS (e.g. aws ecr describe-repositories)
- print out the result for debugging purposes
- revoke a lease_id (part of the output from the previous step) associated with temporary aws credentials
- make another api call to verify that it errors out (403)

#### AWS

- create an IAM policy allowing iam-related actions
- create a dedicated user that can create temporary users (let's call it `vault-root-user`) and attach the policy created above
- create another IAM policy allowing certain actions on certain resources (e.g. read/write access to ECR and S3 for a jenkins agent)
- create a group and attach the policy above to group temporary users that will be created/deleted by jenkins agent

#### Vault

- enable the AWS secrets engine and configure the credentials of the vault-root user to connect to AWS
- configure a vault role that maps to a set of permissions in AWS as well as an AWS credential type. Alternatively, an iam group (e.g. `iam_groups=cicd`) can be supplied instead of a set of permissions
- create a policy dedicated to github auth method, allowing limited access (e.g. read/list) to the `/aws/creds/*` path
- enable the GitHub auth method and attach a token policy
- update the existing default policy by adding another rule that allows revoking a lease_id

```
path "sys/leases/revoke/*" {
    capabilities = ["update"]
}
```

Key outcomes from the above include that AWS credentials have temporary, limited access, so there's no need to worry about any potential secrets being leaked once the pipeline is finished.

Additionally, we can explore the integration of Vault and Terraform, both of which are HashiCorp products, by codifying the Vault configurations. This powerful combination would amplify the benefits of Infrastructure as Code (IaC). I'm excited to give it a try in the next round!
