- Newest
- Most votes
- Most comments
The policy statements in that document article that specify the Service codestar-notifications.amazonaws.com in the Principal element are for cases where the CodeStar Notifications service principal is sending notifications to SNS. The policy statement works the way you suggested: kms:GenerateDataKey is used by SNS to generate an encryption key for storing the message at rest, while it's waiting to be sent, and kms:Decrypt is used by SNS (at the request of CodeStar Notifications) to read the message to send it to the recipients of the topic.
When you send messages to SNS with a Lambda function, it'll be your own Lambda function and not the AWS service CodeStar Notifications that is requesting SNS to deliver a message. The Lambda function will be doing the same kind of operation as CodeStar Notifications, but the Lambda will be running under its own execution role, and that's why it needs to have the equivalent permissions for encrypting and decrypting messages, so that it can "borrow" them to SNS for processing your message. CodeStar Notifications does exactly the same, but it acts under the codestar-notifications.amazonaws.com service principal, while your Lambda function runs under the IAM execution role you've given it.
When any principal calls an AWS service, such as SNS, the operation will generally be performed under the permissions of the calling principal, not those of the target service. That's why the permissions to use the KMS key aren't configured in or for SNS but in the permissions of the calling principal (like the IAM role used to run your Lambda function) and in the permissions of the KMS key as the resource.
Relevant content
asked 2 years ago
- AWS OFFICIALUpdated 3 months ago
I understand that action will be performed by principal. But the principal is CodeStar Notifications. So I thought that CodeStar Notifications will perform the decrypt and generateDataKey. One thing in you answer is that: "The policy statement works the way you suggested: kms:GenerateDataKey is used by SNS to generate an encryption key for storing the message at rest, while it's waiting to be sent, and kms:Decrypt is used by SNS (at the request of CodeStar Notifications) to read the message to send it to the recipients of the topic". Why SNS do the action even though the principal is not SNS. Does this mean CodeStar Notifications allow SNS to do the action on it behalf ? Sorry for long comment but I still got confused about this
Yes, that is correct. When any principal calls an AWS service and asks it to perform an action that involves the service calling another AWS service, the first service (SNS) will make the call to the second service (KMS) under the security context of the principal that called the first service (SNS). This technique for service-to-service calls is called a Forward Access Session (FAS) in AWS IAM.
The principal calling KMS via SNS will be the same principal that called SNS. In this case, where the AWS service principal
codestar-notifications.amazonaws.comsends an SNS notification, the call SNS makes to KMS is also made bycodestar-notifications.amazonaws.com. When your Lambda function calls SNS, it'll be the execution role of your Lambda function that calls SNS and which SNS uses to call KMS (which is why you had to add the KMS permissions to your Lambda function's execution role).Wow, thanks for your valuable information. I have checked the document and it explain exactly the case. But when sns call kms under the security context of the principal, which is code star, technically, I think the security context is code pipeline. This mean that sns will check permission of code pipeline, not code star, right ? I checked the document https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html, combine with your answer and tested out on aws. I do notice that the behavior work differently in both cases.
Thanks for your responding. I understand the codestar part. But why I do not need to provide allow statement in kms key policy like code star when calling sns from lambda. Because as I understand that, if in resource policy, there are no allow statement, then the request will be rejected, even though there is allow in IAM role. In lambda role, there is allow statement for decrypt, generateDateKey, but since in key policy, there are no allow so I think the request will be rejected, which is not. Sorry for keeping asking this but I do want to understand the lambda case more better