Why does AWS add uid to Secret Store ARN?

user_4972059 0
Viewed 284

I hate it when I'm creating a secret store in AWS and it adds a random uid at the end of the ARN. Example: arn:aws:secretsmanager:us-east-1:xxxxxxxx:secret:secrets-store-development-k8s-klbiCG This messes up Terraform templates and makes me cringe every time I need to make ENV variables for each environment. Please, explain why is this being done so that I could be more at ease. I will share my good karma with you in exchange

amazon-web-services
2 Answers

I don't think this implementation detail is publicly documented, so unless you find somebody working at AWS to answer this, you'll probably only get guesses.

Disclaimer: This is a guess, but I think it makes sense

As the name of the service suggests, Secrets Manager is built to store secrets to which access should probably be tightly controlled and limited. If the ARN is predictable, you'd open yourself up to the following problem:

  1. Alice creates a secret demo with the ARN arn:aws:secretsmanager:(...):secret:demo
  2. Alice now creates an EC2 instance and adds an instance profile to it, that allows the GetSecret action on the demo secret identified by it's ARN arn:aws:secretsmanager:(...):secret:demo
  3. Now Alice deletes the secret and after the minimum required amount of time (7 days) the secret gets deleted. Alice doesn't update the policy on the EC2 instance, because granting access to a non-existent secret doesn't seem like a big problem or she just forgets it.
  4. After about a week Bob comes along and creates a secret, which he also decides to call demo and as a result of the predictable ARN, the secret's ARN looks like this: arn:aws:secretsmanager:(...):secret:demo
  5. Unbeknownst to him, the instance Alice had created a week ago now has access to Bob's secret

This isn't ideal for a service that's supposed to keep your secrets protected.

A simple solution is to add a random suffix to the secrets name.

Other examples in the wild

In AWS there is a similar problem with IAM and roles where they chose to implement it in a different way.

If you set create a role you add a trust relationship to it. This trust relationship or assume role policy defines which principal is allowed to assume this role.

Suppose you set up a role Bob and then create a role Eve and allow the ARN of the Bob role to assume the role Eve.

Now you delete the Bob role and recreate it with the same name. You'll observe that the new Bob role has the same ARN as the old one. When the new Bob role tries to assume the Eve role they'll get an AccessDenied error. Now you scratch your head, because you're confused. You think it should work, because you added the ARN, which hasn't changed, to the trust policy ...or did you?

You open up the trust policy and in the assume role policy, you'll see a cryptic ID instead of the ARN you had placed there earlier. That's because in assume role documents AWS uses the physical ID of the underlying role and not the ARN. New Bob has a new physical ID, that's why this doesn't work. They do this exactly for the reasons I outlined above.

user_64858810

For someone who need the ARN

Follow this doc, it shows that we can generate the ARN using the wild card character ? in place of the last 6 random characters like -

arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????
user_57185910
Related