The Vault Installer will create IAM roles for each Vault deployment/Service Account, and attach an

inline policy that allows a pod that assumes the IAM role access to ASM. However, it restricts it to

only access the secrets that it requires.

Using Permissions Boundaries can enforce that the Vault Installer can only give IAM roles the

GetSecretValue policy. It will also create the secrets and push them to ASM.

It will create the roles, policies and secrets with a specific path prefix (given in values.yaml)

to separate Vault’s IAM resources from the rest of a client’s IAM resources in their AWS

account. For example, you could find the IAM role 'vault-account' at 'tm_iam_prefix/vaultaccount_' and the secret in 'tm_iam_prefix/secret_prefix/vaultaccount'.

A concrete example of an access policy for Vault applications is as follows (where you

would supply the values for ‘Region’, 'AccountId', 'tm_iam_prefix' and 'secret_prefix' in

values.yaml).

{

"Version": "2012-10-17",

"Statement": {

"Effect": "Allow",

"Action": "secretsmanager:GetSecretValue",

"Resource": [

"arn:aws:secretsmanager:Region:AccountId:secret:tm_iam_prefix/secret_prefix/vault-account"

]

}

}

The policies for each role would give access to only the secrets within ‘tm_iam_prefix/

secret_prefix/’ that it requires to function.

Having both a ‘tm_iam_prefix’ and a ‘secret_prefix’ allows for more than one Vault instance

to use the same ASM instance, by having a unique ‘secret_prefix’ value per Vault instance.

We suggest setting the tm_iam_prefix to something similar to ‘tm-prefix/$cluster_name’

and secret_prefix to something similar to ‘$namespace’, as this gives isolation across different

Vault instances in different clusters.

Vault installation will also deploy the SecretProviderClass CRs that the CSI secret driver will

use to find which secrets it needs to fetch from ASM for each pod.