By using AWS re:Post, you agree to the Terms of Use
/How do I restrict AWS secret by Lambda alias?/

How do I restrict AWS secret by Lambda alias?


I want to have a QA secret and a Production secret, and I want a Lambda QA alias to only be able to access the QA secret, and likewise with the Lambda Production alias and the Production secret.

Each Lambda function alias uses a single execution role, set at the function level. So any IAM policies attached to this role would apply to all aliases. This means that the QA alias lambda could access the Production secret. So an execution-role based policy does not appear to be the answer.

I am trying to understand how to apply resource-based policies to the secrets, but it appears that I cannot choose the Principal to be a fully-qualified ARN to the Lambda alias. Is it possible to do this?

Unless I am misusing these systems, it seems impossible to keep secrets separate and secure with Lambda aliases.

3 Answers

I am not sure if it is possible or not, but I would recommend that you do not use aliases for this purpose but rather separate into two (or more) different environments. At least dev and prod. This way you reduce the blast radius of mistakes happening in your dev account, e.g., consuming all account's concurrency which may affect production.

answered 3 months ago
  • Your point about blast radius is a good one. However, I'm not ready to move to that architecture yet, but would like to increase security. iwasa had an interesting discovery in the second part of their answer, which is that execution roles can be changed at a per-version level. I'm already changing the docker image per-version when I deploy, so adding this is not much more work, and it enables what I am looking for.

Accepted Answer


I saw this question and tried various things.
But I couldn't.

Unfortunately, neither Lambda's Execution Role nor Secret's Rolebase Policy seem to be able to include a specific ARN (eg alias) as a condition.

If you want to limit with IAM roles, I think you should separate QA and Production at the function level and above, as @Uri advises.

Alternatively, Lambda has a different Execution role for each version.
You can indirectly separate roles if the alias points to another version.
This also enables role-based secret access control.

answered 3 months ago
  • Interesting! I didn't realize that the Lambda roles are inherited/instantiated similar to how the container image on a Lambda is changed: you change it at the function level, then create a new version from that function template. In theory, I could do the same thing: change the role AND the docker image, then create the new version from that function template, then re-point the alias. Since this actually solves the question that I had, I'm marking this as the answer, though Uri does make good points about blast radius.


If you need to restrict secrets to certain functions, you need to create a new role. You can't restrict by alias IIUC.

  "Effect": "Allow",
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "arn:aws:secretsmanager:ap-southeast-1:${ACCOUNT_ID}:secret:/${ENVIRONMENT}/secretA"

Typically each role would have some ${ENVIRONMENT} variable in it too btw, usually isolated to an account.

answered 3 months ago
  • That won't work, since a Lambda function's role applies to all of its aliases. Giving that role access to a production secret would allow the QA lambda to access it too.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions