Feature Request: Add ttl and max_ttl to AWS secret engine roles

[andrejvanderzee]

In our use-case, the AWS secret engine should support values for ttl and max_ttl per role. When not specified, the values should be taken from enable/mount options.

Consider the following configuration (in our internal provision format):

secret_engine "aws/sts" {

  enable {
    description = "AWS STS token provider"
    type = "aws"

     config {
        default_lease_ttl = "6h"
        max_lease_ttl = "12h" 
     }
  }

  path "config/root" {
    access_key  = "{{getEnv "AWS_VAULT_USER_ACCESS_KEY"}}"
    secret_key  = "{{getEnv "AWS_VAULT_USER_SECRET_KEY"}}"
    region      = "eu-central-1"
    max_retries = 20
  }

  path "roles/sre" {
    arn = "xyz"
  }

  path "roles/deploy" {
     arn = "xyz"

     # Feature request: The following options could override the config/lease settings.
     ttl = 30
     max_ttl = 30
   }
}

We want to keep the deploy-role strict to max 30 seconds and prevent the client for setting higher ttl values: Higher values give malicious clients a longer timeframe to do harm. Now we are forced to mount separate secret engines for the roles sre and deploy.

If agreed, I volunteer to implement this feature request as I am familiar with the vault code and particular the AWS part.

[andrejvanderzee]

The merit behind this is that the sre-role is provided to our sre team-members to fetch AWS STS credentials to their laptops for interacting with AWS. These can be up to 12h before they must expire.

On the other hand, the deploy-role is for our CI pipelines where GitLab runners (ec2 instances at AWS) authenticate at the vault to get AWS STS credentials. These credentials must be as short as possible to do their job. If someone manages to hack/misuse the runners, he should not be able to obtain STS tokens of 12h.

The AWS secret engine currently does not allow for different max_ttl per role, which forces us to mount separate secret engines for different roles and speficy the max_ttl in the mount config. The provisioning of vault is already a rather complex task, having to split out different roles over different secret engines does not make this easier.

[vishalnayak]

I don't see why we shouldn't implement this feature. @joelthompson and @jefferai thoughts?

[joelthompson]

Makes sense, but one note of caution on these things:

the deploy-role is for our CI pipelines where GitLab runners (ec2 instances at AWS) authenticate at the vault to get AWS STS credentials.

and

We want to keep the deploy-role strict to max 30 seconds and prevent the client for setting higher ttl values

This will probably work for IAM users, but sts:AssumeRole and sts:GetFederationToken have minimum lifetimes of 900 seconds, so you won't be able to set a TTL or max TTL below that for those credential types (which it sounds like you want to do).

[andrejvanderzee]

@joelthompson In reality we actually use values higher than 900s for sts:AssumeRole so we did not reach the minimum. Though, we did reach another AWS maximum of 12h.

[chrishoffman]

Implemented in #5500