Looking at an example key policy:
{
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/ExampleUser"
},
"Action": [
"kms:Encrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": [
"lambda.us-west-2.amazonaws.com"
]
}
}
}
My question (and this applies to both allow/deny policies) – why does the principal in this case even matters? I mean, a Lambda function may exist in an AWS account, it will have it’s own role and it will assume that role when trying to execute something that requires a key in KMS. Naturally once it passes IAM evaluation it will also have to pass the key policy evaluation so.. does that mean that in the example I pasted (which comes from AWS docs) the principal should actually be a role? The same question applies to EC2. An EC2 instance doesn’t know (nor cares) which principal created it, so I’m guessing that when EC2 wants to access KMS the role it assumes is being checked? an not the ARN of the user that created that instance?
1 Answers
Yup, a principal can either be a Role, User or even a Service. For Lambda, it has an execution role, which then tries to access the key. Regardless of which user created this role, the role itself must be granted access to the key before it can be used.
I agree this lecture really just skims over the top of the subject. It pretty much just reads key parts of the documentation without really explaining it in any depth.