IAM resource based policy implicit allow¶
Resource policy are typically used to allow cross account access for resources where it is supported some of which include:
S3
SQS
SNS
SES
KMS
Step Functions
Event Bridge
Glue
OpenSearch
API Gateway
Cloudwatch Logs
Lex v2
AWS private CA
Secrets Manager
EFS
Backup
ECR
Lambda
The AWS Documentation states when evaluating requests within the same account the rules are evaluated by AWS as follows:
By default, all requests are implicitly denied with the exception of the AWS account root user, which has full access.
An explicit allow in an identity-based or resource-based policy overrides this default.
I want to make my policy as brief as possible, at the same time lock down access within the same account as much as possible. My question is which resource based policy have such an explicit allow?
From my experiments these are services that implicit allow same account access via resource policy.
Implicit allows are based on the absence of an explicit deny statement.
SQS¶
Here I test it for SQS, I created a SQS queue with a custom defined resource-policy:
{
"Version": "2012-10-17", "Id":
"DenyIfSourceAccountAndPrincipalOrgIdMatch", "Statement": [{
"Sid": "DenyAccessIfSourceAccountAndPrincipalOrgIdMatch", "Effect":
"Deny", "Principal": "*", "Action": "sqs:*", "Resource":
"arn:aws:sqs:us-east-1m:003422198502:test", "Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgId": "o-r2rjrevijr", "aws:SourceAccount":
"${aws:AccountId}"
}
}
}]
}
This SQS resource policy denies access to all principals *
for any SQS actions
sqs:*
on the named queue if the aws:PrincipalOrgId
is not equal to
o-r2rjrevijr
(the current org) and the aws:SourceAccount
is not equal to the
current AWS account ID.
Then I created a IAM users with permission to
SQS:SendMessage
Since the resource policy has not explicitly allowed the action for my principal but testing it still works, we can be certain there is an implicit allow for same account access for SQS.
Summary¶
Services that have implicit allow in the resource-based policy:
S3
SQS
This means that the IAM resource policy has no need for same account allow statements.
Services that do not have implicit allow in the resource-based policy that I have tested using a similar method to SQS:
KMS
IAM
A note about KMS¶
KMS is special in that the default policy is granted to the account principal as follows:
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
When the principal in a key policy statement is the account principal, the policy statement doesn’t give any IAM principal permission to use the KMS key. Instead, it allows the account to use IAM policies to delegate the permissions specified in the policy statement.
Links¶
List of resource supporting resource-based policy
Really good summary of IAM policy Forward access session Access undenied Re-Invent slides more details than AWS Doc
Comments
comments powered by Disqus