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?
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.