AWS Secrets Engine templated session tags

[joemiller]

Is your feature request related to a problem? Please describe.

Not a problem per se. Perhaps it may lead to being able to better conform to certain AWS IAM best practices around using tags and ABAC-style policies.

Describe the solution you'd like

I have an example use case where it would be desirable for the AWS secrets backend to be able to apply session tags on credentials issued by the aws/sts/creds API. This would allow greater dynamism in the AWS backend.

example use case:

I want to auth OIDC tokens from my CI using the auth/jwt backend and a single auth role. Most CI providers are offering per-job OIDC tokens now. I will use Buildkite in this example but it applies to GHA and others.

• I want to be able to auth OIDC tokens from any repo in the org without having to create a new auth/jwt/role/<REPO> role for each.
• I want a single AWS Secrets role that each repo can get IAM creds (assumed_role) from and have the claims from the JWT applied as session tags.
• The session tags allow me to treat each issued AWS credential as unique by writing ABAC-style policies that use tags to differentiate each "user" (repo/pipeline in this example)

How this might look in practice:

1. Setup a single auth/jwt role buildkite-pipelines:

   vault write auth/jwt/buildkite-pipelines \
   bound_audiences="vault" \
   policies="buildkite-pipelines" \
   user_claim="pipeline_slug" \
   claim_mappings="pipeline_slug=pipeline_slug" \
   role_type=jwt

2. Create an AWS IAM role buildkite-pipelines. This role will be assumed by any BK pipeline in our org.
3. Create a single Vault AWS Secrets role named buildkite-pipelines that will assume the role created in the previous step:

   vault write aws/role/buildkite-pipelines \
   credential_type="assumed_role" \
   role_arns="arn:aws:iam:123456789012:role/buildkite-pipelines" \
   session_tags="pipeline_slug={{ identity.entity.alias.mount_jwt_1234567.custom_metadata.pipeline_slug }}"

Buildkite pipelines would use their OIDC token to auth to vault and fetch AWS creds. These creds would have a pipeline_slug session tag.

Then, an S3 bucket could be made available for all pipelines to use with a single bucket policy. They would be restricted to read/write/list on the path cache/<PIPELINE> where <PIPELINE> is the pipeline_slug conveyed from the claims on the BK OIDC token down to a session tag on the AWS IAM creds:

  "Resource": "arn:aws:s3:::my-bk-cache-bucket/cache/${aws:PrincipalTag/pipeline_slug}/*",

Describe alternatives you've considered

1. Using Vault, the alternative is to explicitly create jwt auth roles and secrets/aws roles for each pipeline.
2. This is a lambda-based example using GitHub Actions OIDC tokens. In this example a GHA job would send its JWT to the lambda which would parse out the claims and call the sts:AssumeRole API with those claims as session tags, returning the resulting creds to the caller. https://github.com/glassechidna/ghaoidc/blob/main/api/api.go

Explain any additional use-cases

In general I think this would go a long way towards allowing folks to expressing more ABAC-style IAM policies with Vault.

[harsimranmaan]

https://github.com/hashicorp/vault/pull/18813 is first step towards achieving this. Please upvote it so that we can land it on mainline and introduce templates in the future.

[harsimranmaan]

I have also added some thoughts on an alternative approach that is viable today using the Vault identity engine. https://harsimranmaan.medium.com/aws-abac-attribute-based-access-control-using-hashicorp-vault-e9a6c07c066e

[joemiller]

@harsimranmaan thank you for the article! I was not aware the identity engine could do that 🤦

[harsimranmaan]

It can do it but has its complexities around setting it up. For most orgs already hooked onto AWS secrets engine, native support is the way to go.