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.
Related
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 am looking for a S3 bucket policy which can grant/restrict specific federated users access to the bucket. Federated users in aws uses IAM roles. Is there some way I can limit the access to a user even if the user has assumed the role. Is there a way I can specify federated users in a bucket policy? Also the S3 bucket is in a different account.
When a user is assuming a role, they are assigned a role-session-name. This can be used to track the identity of the user assuming the role.
From AWS JSON Policy Elements: Principal - AWS Identity and Access Management:
Specific assumed-role user
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
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)
I am trying to create IAM Policy which restricts passing the IAM Role to an EC2 instance that if instance id does not equal to i-1234567890abcd
There is no error in the policy but there is no effect of this policy either. If I remove Condition from the below policy, it works but it restricts the role to be attached to any EC2 instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["iam:PassRole"],
"Resource": ["arn:aws:iam::000000000000:role/MyEC2InstanceSpecificRole"],
"Condition": {
"ArnNotEquals": {
"ec2:SourceInstanceARN": "arn:aws:ec2:us-east-1:000000000000:instance/i-1234567890abcd"
}
}
}
]
}
I suspect that this is not possible.
The Granting a User Permissions to Pass a Role to an AWS Service documentation states:
To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.
When a user passes a role ARN as a parameter to any API that uses the role to assign permissions to the service, the service checks whether that user has the iam:PassRole permission. To limit the user to passing only approved roles, you can filter the iam:PassRole permission with the Resources element of the IAM policy statement.
Also on Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances it states:
PassRole is not an API action in the same way that RunInstances or ListInstanceProfiles is. Instead, it's a permission that AWS checks whenever a role ARN is passed as a parameter to an API (or the console does this on the user's behalf). It helps an administrator to control which roles can be passed by which users.
The normal use-case for PassRole is to ensure that users do not grant AWS Services any more permissions that they should be allowed to use themselves. It tries to avoid a situation where a non-Admin user passes an Admin role to a service with the sinister intention of then using that service to access resources that they would not normally be allowed to access. For example, launching an Amazon EC2 instance with an Admin role, so that they can then login to that instance and issue Admin commands that they would not normally be entitled to use.
The above documentation suggests that the PassRole permission is evaluated to confirm their permission to pass a certain role to a certain service, rather than how that service is going to use the role itself (eg by then assigning it to an EC2 instance to generate STS credentials).