- 최신
- 최다 투표
- 가장 많은 댓글
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.
Hi.
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.
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.
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.
관련 콘텐츠
AWS 공식업데이트됨 2년 전
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.