3

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

Maurice
  • 11,482
  • 2
  • 25
  • 45
Bogdan Polovko
  • 115
  • 1
  • 11
  • 1
    I don't see the problem, the ARN is exposed as an attribute according to the [docs](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/secretsmanager_secret). Unfortunately you'll most likely only get speculations here unless somebody from AWS thinks this implementation details should be public knowledge. – Maurice Feb 25 '21 at 16:44
  • 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. – eco Aug 16 '22 at 21:30
  • 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. – DaedalusAlpha Sep 02 '22 at 12:25

2 Answers2

4

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.

Maurice
  • 11,482
  • 2
  • 25
  • 45
  • 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? – Bogdan Polovko Feb 26 '21 at 13:16
  • 1
    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. – Maurice Feb 26 '21 at 15:19
  • @Maurice 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.... – eco Aug 16 '22 at 21:20
  • 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. – eco Aug 16 '22 at 21:26
0

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-??????
Md. Shohag Mia
  • 322
  • 3
  • 13
  • 2
    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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-secret.html)). – Maxime Rossini Sep 30 '22 at 16:41