Why does AWS add uid to Secret Store ARN?

Question

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

Wooer

I don't see the problem, the ARN is exposed as an attribute according to the docs. Unfortunately you'll most likely only get speculations here unless somebody from AWS thinks this implementation details should be public knowledge. – Flowering

I do have a valid scenario where I would like to build a template in terraform where I can patternize a secret arn with account, environment, application, etc. All I'm going to do is query the AWS environment for that secret arn using those same parameters. Things are usually bigger than what they seem and you can't try to force an entire cloud architecture into your particular use case when there are valid and unforeseen reasons for it. Might as well adapt. – Woodborer

I have noticed that if you're fine with skipping the extra security Maurice is talking about in his answer AWS accepts the secret name without the extra random bits at the end. – Medora

Answer 1

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.

Flowering

Thanks. This is a good explanation. But as you explained in the example with IAM Roles, why not do the same thing? It feels like a lazy design on the AWS side to just add a uid at the end to the arn. Where is user experience here? – Wooer

IMO the user experience of the IAM implementation is terrible. A policy shouldn't just become invalid for now apparent reason. We've worked with this in a cross-account setup and it's a nightmare. We have roles that can be assumed by different entities and if you want to update part of the policy you may be suddenly confronted with an "Invalid Principal in Policy" error during a CloudFormation stack update, which usually requires manual intervention. I wish they did something similar/obvious as they did with the secrets manager for IAM. – Flowering

@Flowering I first noticed the IAM role/user physical address (which for IAM resources starts with AKAI) on ECR policies. Usually roles exist at a rate of one per account so it shouldn't be a problem. Secrets though, they now can be replicated across regions, but again, having region in the arn should make them unique enough from that perspective. Your scenario is plausible, possible and probable so voted up. I've never seen the assume role scenario you mentioned.... – Woodborer

Security trumps user experience when aws is not willing to expend potential hundreds of thousands of dollars due to user error in order to satisfy UE. @BogdanPolovko The answer is simple, AWS is HUGE: different teams, different service design, different solutions. Is the result of AGILE methodology and what came afterwards. They're not going to re-build an entire service just for that, Apple has really done a lot of damage giving people the wrong impression about computing. If you complain they'll tell you they are following their SLA, which is to be responsible for the DC side of things. – Woodborer

Answer 2

To fix your scripts and templates, the ARN can be acquired dynamically.

Here's how to do it in Terraform:

// dynamically acquire the opaque ARN based on the secret name
// implicit dependency: assumes that the secret already exists
data "aws_secretsmanager_secret" "mysecret" {
  name = "name-of-my-secret"
}

Then you can access the arn as:

data.aws_secretsmanager_secret.mysecret.arn

Lydell

The point being, it's not necessarily a problem that the ARN is unpredictable. The ARN is generated based on an AWS-internal algorithm and, in the normal case, you shouldn't need to hard-code the ARN itself into your configs and scripts because the the value can be acquired dynamically when the script is executed. – Lydell

Answer 3

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-??????

Sheerlegs

This works for IAM policies resource patterns (because, well, they are ARN patterns, not ARNs). This doesn't work in other situations where the exact ARN is required. e.g. the ValueFrom property from the Secrets section in a container definition of an ECS task definition requires the exact ARN (reference). – Branham