According to this:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html#policies-grammar-bnf
The principal_block element is required in resource-based policies (for example, in Amazon S3 bucket policies) and in trust policies for IAM roles. It must not be included in identity-based policies.
so is this:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html
an Identity-based Policy?
Yes, we agree! The example policy you linked to is an identity-based policy. The policy does not contain a principal element.
To review, a principal is the entity that is allowed or denied access to a resource.
When you attach the policy to an IAM user, that user becomes the principal.
Therefore, in an identity-based policy the principal is not explicitly declared in the policy statement.
Here´s a quote from the AWS documentation, "In those cases [policies that
you attach to IAM users] , the principal is implicitly the user that
the policy is attached to (for IAM users)..."
(For more information, see https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)
Related
From AWS docs
For most resources, you only need an explicit allow for the principal in either an identity-based policy or a resource-based policy to grant access. IAM role trust policies and KMS key policies are exceptions to this logic, because they must explicitly allow access for principals.
it's clear that for most resources (that support resource-based policies), a resource-based policy is enough to grant access to an IAM principal (meaning, without the need to add an explicit Allow to an identity-based policy of the principal). Trust policies and KMS policies are notable exceptions, since a resource-based policy must be attached to the resource.
Are there any other resources, where a standalone resource-based policy is not enough to grant access to an IAM principal? Or equivalently, are there any services where both an identity-based & resource-based policy at the same time is required to allow access?
The services I tried so far worked fine (S3, SQS, Lambda), but there are more than 20 services that support resource-based policies, so I can't check all of them.
I expect to be no service which supports resource-based policy and requires an identity-based changes to grant access to the particular resource.
In absence of an explicit Deny, one valid* explicit Allow is sufficient:
If either the identity-based policy or the resource-based policy within the same acccount allows the request and the other doesn't, the request is still allowed. source
* Identity policies are valid for KMS only if the key (resource) policy explicitly permits them: Unlike other AWS resource policies, an AWS KMS key policy does not automatically give permission to the account or any of its principals.
In short: if I create an IAM policy containing a cross-account Principal, but the account in question is the one I'm already operating in, is that a no-op?
My understanding (from here) is that an IAM statement like the following can be used for cross-account access, i.e. to delegate to another account, allowing it to allow access to the resource in question:
{
Action = "kms:*"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::XYZXYZXYZXYZ:root"
}
Resource = "*"
}
(where XYZXYZXYZXYZ is some account ID, obviously).
But what if the account ID isn't another account? I'd hope this does nothing. I'd fear it grants full access. Latter option seems insane: can anyone confirm?
I am assuming this is in a KMS key policy otherwise specifying the principal would not make sense / would be disallowed by IAM anyway.
Therefore I am quoting https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html:
The following default key policy statement is critical.
It gives the AWS account that owns the KMS key full access to the KMS key.
Unlike other AWS resource policies, an AWS KMS key policy does not automatically give permission to the account or any of its users. To give permission to account administrators, the key policy must include an explicit statement that provides this permission, like this one.
It allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.
Without this permission, IAM policies that allow access to the key are ineffective, although IAM policies that deny access to the key are still effective.
It reduces the risk of the key becoming unmanageable by giving access control permission to the account administrators, including the account root user, which cannot be deleted.
The principals within the account do not immediately have access to the key but just adding a policy to them will grant them access. KMS is one of the few services with where both the resource and the identity policies need to grant the access.
I have a resource policy on my KMS key that allows access from the root account and some additional IAM roles used with Jenkins (Role A).
I was able to update an IAM policy for a User (User B) that allows access to the KMS key ARN and KMS:* actions. This allowed the IAM User to access the key for necessary actions.
From the documentation I was reading I was under the assumption that the KMS key resource policy needed to be updated to allow access to the key, but it seems updating the IAM User's policy allows for access.
How can I secure my KMS key so that the KMS key resource policy is the source of truth for what users/roles are allowed access to the key? Do I need to set an explicit Deny on the KMS key policy and set an excluding condition for Users/Roles that are allowed access?
Is what I'm currently observing the expected behavior with the KMS key policy and IAM User policy? Is this due to the IAM User's policy having an explicit allow for the key?
The effective permissions will be a logical intersection between the identity based policy of the IAM role and the resource based policy of the KMS key.
How can I secure my KMS key so that the KMS key resource policy is the source of truth for what users/roles are allowed access to the key? Do I need to set an explicit Deny on the KMS key policy and set an excluding condition for Users/Roles that are allowed access?
If you wanted to setup a "single source of truth", you would have to have the identity based policy whitelist all KMS actions and have the resource based policy deny certain ones as required.
I access a bucket with a lambda function and i get an "Access Denied" error, when i access it with a lambda function via boto3. If i set principal to "*" in the Bucket, all works fine. What is the issue?
"Sid": "DenyIncorrectEncryptionHeader",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
...
In the bucket policy, the principal to give allow permission to should be the lambda execution role and not the lambda service (lambda.amazonaws.com).
Adding more details, if the lambda execution role is in the same AWS account as the bucket, then an allow permission in the role should suffice. As long as there is no explicit deny in the bucket policy.
However, if the role and bucket are in separate accounts, the role has to have allow permission and the bucket policy has to give allow permission to the role.
The steps would be:
Create an IAM Role with a use-case of Lambda (this creates a Trust Policy that allows the AWS Lambda service to assume the role)
Add a Policy to the IAM Role that grants the required Amazon S3 permissions
Configure the AWS Lambda function to use this IAM Role
There is no need to use an Amazon S3 Bucket Policy for your stated requirements.
As a general rule, Bucket Policies are used when granting permission to everyone, and IAM policies should be used when granting access to specific Users or Groups. (However, there can be other situations for using Bucket Policies, such as granting cross-account access.)
You define policies that Grant access to resources generally but can I use a policy that grants access to the IAM user it's applied to?
I guess I want a bucket access policy but for an IAM user. I want to attach a policy to a user that says give a specific iam role access to me.