Why do I need the “update” capability on the “auth/token/create” path to read an AWS secrets engine generated secret?

6
votes

I followed the guide at https://www.hashicorp.com/resources/best-practices-using-hashicorp-terraform-with-hashicorp-vault.

It's good, but when I use Terraform to get dynamically created AWS creds from Vault I get a 403 error.

I've solved the problem, but I don't quite understand why I need to add the additional capability (especially since it wasn't in the guide) and what problematic side-effects it may have.

Non-working policy:

path "aws/creds/dev-role" {
  capabilities=["read"]
}

Working policy:

path "aws/creds/dev-role" {
  capabilities=["read"]
}

path "auth/token/create" {
  capabilities=["update"]
}

The expected result is that when I run "terraform plan" it gives me a list of things it's going to do.

The error I get when I don't include the "update" capability is:

provider.vault: failed to create limited child token: Error making API request.

RL: POST https://:8200/v1/auth/token/create Code: 403. Errors:

  • 1 error occurred:

  • permission denied

1
terraformhashicorp-vault

1 Answers

2
votes

My understanding is that the Vault provider does not just try to use the Vault token returned from the AWS auth result, but tries to make a temporary child token from the returned token so that the vault provider can specify how long it wants the child token to live.

This also makes it easier to kill some child tokens later if you want to, while leaving other tokens generated from your AWS credentials alive.