AWS Secret Engine: context keys

For a use case I need to providing to different applications access to its own s3 bucket. I need a logical separation from different applications so one cannot access other data. I achieve the goal using credential_type=assumed_role with an s3 bucket wiht its restriction policy for each application, a vault role for each applications and an AWS IAM Role for each application/bucket.

Application needs to have its own vault role and its own s3 bucket sure, but if the vault during assume role could inject some context information, one could reduce AWS objects e.g. by reducing them to a single role (with s3 buckets policies that will filter based on conditional on context information, e.g. approle name or other information known from vault).

AWS Secret Engine credential_type=assumed_role may benefit from adding context information used in AWS policies, I think something like this AWS global condition context keys.

In all that you didn’t actually ask a question.

However, the simple work around to your issue (I think) is that you can lock access to the role using a policy that’s setup on the auth that only your “app” needs access to. If that doesn’t use and you have an enterprise license, you could use namespaces to segregate the app.

Hi @aram,
can you be more specific on how to restrict access to a single “role” that should give access to all s3 buckets ? If AppX can access the role governing access to all buckets of all App, AppX will be able to access all s3 bucket by design (so also that of other App). A simple application configuration for auth and for bucket name can overcome the restriction applied.

I think that only a bucket policy can restrict AppX to use only its own s3 bucket and can do that using specific AppX information hidden by vault (so that can be secretly passed by vault only and not know externally).

You’re confusing the AWS dynamic access account role with the “role” defined for access. One account in AWS is allowed to create other accounts, and assign policy, that’s your “root” account that you give over to Vault to manage. [ Note that this should NOT be your AWS root account, it’s just badly named in Vault documentation ].

After that point, when the admin defines a role in AWS, lets call it AWS-role-y, that role can have any policy (inline or defined in AWS) that the admin believes the role needs, i.e. read only to S3Bucket 123 access to ARN:s3:…123 and only that policy that applies to one bucket.

So when AppX requests access to AWS-role-y the resulting generated AWS key only gets the final role to access that one bucket, and nothing else.

Hi @aram,
probably I’m missing something as I know Vault root user has nothing to do with AWS IAM root user and Vault Role is all another thing than AWS IAM Role.

For my case Vault root user (AWS IAM user create for vault) will use Vault Roles of credential_type=assumed_role. Vault root user through a VAULT Role (e.g, myVAULTRole1) defined like this below will assume AWS IAM Role (e.g. myAWSRole1):

vault write {path}/roles/myVAULTRole1 \
role_arns=arn:aws:iam::{account_id}:role/myAWSRole1 \

By the VAULT Role Vault root user will assume AWS IAM Role and its permissions. It is possible to define multiple AWS IAM Roles inside a Vault role, but doing so you’ll not achieve customer logical environment separation anymore.

Using AWS IAM Role policy will give access to single S3 Bucket.

Defining a VAULT Role for every customer e.g. an AppRole allowed to read its VAULT Role will use sts creds to access its dedicated S3 Bucket.

This works perfectly for customer environment logical separation at the price of (customer = N):

  • N x (S3 Bucket and its bucket policy)
  • N x (VAULT Role)
  • N x (AWS IAM Role)
  • At least N x (AWS IAM Policy for Role)

The only methond I see to mitigate such objects sprawl wolud be filtering on S3 Bucket Policy level, but filtering information should be introduced by Vault Role, so we’ll can have (customer = N):

  • 1 x (AWS IAM Role)
  • 1 x (AWS IAM Policy for Role) (allow access to any S3 Buckets with spec bucket name prefix)
  • 1 x (VAULT Role) (assuming above single AWS IAM Role annd passing e.g. the AppRole as IAM custom context info)
  • N x (S3 Bucket and its bucket policy filtering for contect info)

So if you are using the assumed_role option you would have an IAM user that is used by the AWS secret engine (The Vault “root” user, which needs to have permissions to assume all the other IAM roles). You then have as few or as many IAM roles as you wish, each with an associated Vault role.

You can attach additional policies (which act as a filter to reduce permissions otherwise allowed by the IAM Role) by specifying a policy_document in the Vault role. Using that could could have one IAM Role which allows access to every S3 bucket, and then have a different policy_document for several Vault roles (which all use the common IAM Role) that limit access to a single bucket each time.

Alternatively you could use the iam_user option in Vault instead of the assumed_role option. You then don’t have to create any IAM Roles in AWS at all. You would then fully manage all permissions within the settings of each Vault role.

Hi @stuart-c,

(iam_user option)
I like assume_role when it is supported as Vault leave to native AWS mechanism (STS) the burden to manage creds liveness internally and securely, propaply returnoing temporary credentials more quickly as no user will be created on AWS IAM anymore so there is probably less call latency, having probably more secure credentials without floating IAM Users although temporary, leaving AWS IAM User console clean from potentially lot of temporary users created to access many S3 Buckets, etc.

( policy_document in the Vault role)
You are right for Vault Role policy document, in effect I missed this rows i documentation:

Further, you can specify both a policy_document and policy_arns parameters;
if specified, each acts as a filter on the IAM permissions granted to the
assumed role.

So I probably can use syntax like this for each Vault Role to restrict further on assumed role permissions.

vault write {path}/roles/myVAULTRole1 \
role_arns=arn:aws:iam::{account_id}:role/myAWSRole1 \
credential_type=assumed_role \
  "Version": "2012-10-17",
  "Statement": [
      "Effect": "...",
      "Action": "...",
      "Resource": "..."

This bring us to solution like this (customer = N):

  • 1 x (AWS IAM Role)
  • 1 x (AWS IAM Policy for Role) (allow access to any S3 Buckets with spec bucket name prefix)
  • N x (VAULT Role) (assuming above single AWS IAM Role with policy restricting )
  • N x (S3 Bucket and its bucket policy filtering for contect info)

this is a big step forword, reducing to 1 AWS IAM Role, so I think this is the best solution as now.

There are still many Vault Roles to create and manage also if there is a unique information (e.g. AppRole) Vault can probably pass to STS to be used as token/ticket custom creds information S3 Bucket policy can use to filter on with conditional. This could improve a lot use cases like this, not so uncommons I think.

Thank you, I’ll give a try to role policy_document suggestion.