- Newest
- Most votes
- Most comments
When performing operations in an S3 bucket with KMS encryption enabled, the related KMS operations are performed in the context of the IAM principal that initiated the S3 operation [1].
For example, if you upload an object using the console while logged in as an IAM user, a kms:GenerateDataKey request will be sent to KMS using the IAM user principal, not a service role. The principal being used will still need permission to perform kms:GenerateDataKey in the IAM policy, as well as the key policy.
By default, a customer managed key policy will allow access to the key from any principal in the account, and an AWS managed S3 KMS key allows any principal in the account when calling via S3 (using "kms:ViaService": "s3.us-east-1.amazonaws.com").
A service role would only be required when S3 is performing the operations itself, e.g. replication. In this case, the replication role would need to be allowed these same permissions [2].
--
[1] https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-access-default-encryption/
[2] https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-replication/
Relevant content
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated a year ago
Thank you for your answer, in my understanding, since I am using AWS Signature Version4, S3 should not be able to get my secretKey, how can S3 use the IAM user principal? Does this mean that S3 can access resources of other services under my account in the context of this request?
It looks like this all happens internally, so it doesn't need access to your secret key. I can't find it explained in a lot of detail anywhere but it's partially explained here: https://docs.aws.amazon.com/accounts/latest/reference/security-iam.html
"Cross-service access – Some AWS services use features in other AWS services. For example, when you make a call in a service, it's common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal's permissions, using a service role, or using a service-linked role."
"Principal permissions – When you use an IAM user or role to perform actions in AWS, you are considered a principal. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a different service. In this case, you must have permissions to perform both actions."