I have a IAM group called group-dev and couple of users attached to this group, I have custom IAM policy(below). Does this IAM policy alone be sufficient for users in that group to encrypt and list kms keys?
Basically My goal is to create IAM group with policy attached to couple of users, and when new users are added i don't want to go about do double work like adding them to group and then adding them to kms key policy. So would it work with the below policies ?
IAM group inline policy
{
"Action": [
"kms:List*",
"kms:Encrypt",
"kms:Decrypt",
"kms:Describe*",
"kms:Get*"
],
"Effect": "Allow",
"Resource": "*"
},
kms policy
{
"Id": "key-consolepolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxx:root"
},
"Action": "kms:*",
"Resource": "*"
}
Below are snippets from aws doc: https://docs.amazonaws.cn/en_us/kms/latest/developerguide/kms-dg.pdf#page=95&zoom=100,96,105
Allowing multiple IAM users to access a CMK
IAM groups are not valid principals in a key policy. To allow multiple IAM users to access a CMK, do one of
the following:
• Add each IAM user to the key policy. This approach requires that you update the key policy each time
the list of authorized users changes.
• Ensure that the key policy includes the statement that enables IAM policies to allow access to the
CMK (p. 72). Then create an IAM policy that allows access to the CMK, and then attach that policy to
an IAM group that contains the authorized IAM users. Using this approach, you don't need to change
any policies when the list of authorized users changes. Instead, you only need to add or remove those
users from the appropriate IAM group.
Looks like there are contradicting statements, or is it something i misunderstood?
. Enables IAM policies to allow access to the CMK.
IAM policies by themselves are not sufficient to allow access to a CMK. However, you can use them
in combination with a CMK's key policy if the key policy enables it. Giving the AWS account full
access to the CMK does this; it enables you to use IAM policies to give IAM users and roles in the
account access to the CMK. It does not by itself give any IAM users or roles access to the CMK, but it
enables you to use IAM policies to do so. For more information, see Managing access to AWS KMS
CMKs (p. 69).
First to compare how these work together each CMK (Customer Managed Key) is created with a key policy that restricts which principal (the caller of the action i.e. IAM Role/IAM User/Service) can access it (and the permissions that the principal will have). It does not matter whichever IAM permissions you grant, if your key policy does not allow the permission no IAM user (including the root user) can perform the action.
The IAM policy attached to the users will grant the maximum permissions that the user can perform. When the action is evaluated the key policy permissions are evaluated as well, if the permission is allowed in both policies the principal will be allowed to perform the action.
So in summary, for KMS both the key policy and the IAM policy permissions must allow access. The permissions you have would allow the users to have the majority of access to the KMS key.
Related
Is it possible to allow a user to create policies that doesn't contain any IAM Write actions, such as iam:CreatePolicy or iam:AttachPolicyRole?
The reason I'm asking is that the company I work at has a single person which can create policies & roles for security reasons. But this is quickly becoming a bottleneck, and we would like to transfer the responsibility of creating roles & policies to more people in a secure fashion. One way I can think is to limit the actions a policy can have, and the most sensitive actions are IAM actions, but I don't know if this is possible.
IAM has an important feature called permissions boundaries:
A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
A permissions boundary is designed to restrict permissions on IAM principals (IAM users and IAM roles). It enforces a centrally-managed boundary that can’t be exceeded, even if broader permissions are granted by some other policy attached to the IAM principal.
Permissions boundaries can also be used to restrict what permissions that IAM principal can grant when creating new IAM principals.
Here's an example of an IAM statement that you could add to an IAM user's policies that would allow that user to create new IAM users and roles but restrict the created roles and users to a specified permissions boundary:
"Statement": [
{
"Sid": "AllowIAMCreate",
"Effect": "Allow",
"Action": [ "iam:CreateUser", "iam:CreateRole" ],
"Resource": "*"
},
{
"Sid": "DenyIAMCreateWithoutBoundary",
"Effect": "Deny",
"Action": [ "iam:CreateUser", "iam:CreateRole" ],
"Resource": [
"arn:aws:iam::1234567890:user/*",
"arn:aws:iam::1234567890:role/*"
],
"Condition": {
"StringNotEquals": {
"iam":PermissionsBoundary": "arn:aws:iam::1234567890:policy/DevBoundary"
}
}
}
]
Here's a good introductory video: Prevent privilege escalation with AWS IAM permission boundaries
yes, you can create customer managed policies.by just a simply adding a permission in that policy.
Can a role be assumed if it does not have a Trust policy?
If a given IAM user has an attached identity based policy saying that he/she can call sts:AssumeRole for a given role (inside the same account), but the user is not described in the Trust policy of this role, will he/she be able to assume the role?
Usually only the resource based policy or the identity based policy should be enough to give rights for the user, but is it different for the roles?
Thanks
will he/she be able to assume the role?
Yes, of course she/he will be able to do it, as long the trust policy allows the account to assume the role. For example, a role has to have the trust policy of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "<account-number>"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
This way, your IAM user does not need to be explicitly listed in the trust policy, but trust policy is required and at least you should specify the account which can assume it. But the drawback is that any IAM user or role from the <account-number> account that has sts:AssumeRole permissions can assume the role.
it does not have a Trust policy?
Trust policy is required, so you can't have a role without such such a policy.
Update
Lets assume you have a role with a trust policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxx:user/UserA"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
The role can be assumed only by userA. UserB will not be able to assume this policy, regardless of his permissions.
A Trust Policy specifies the "Principal" which can assume the role it is attached to. That principal can be various different types of entity, such as an AWS service (e.g. to create a role applied to EC2 instances), or the identifier of another AWS account (to grant cross-account access). It cannot be omitted or be a wildcard.
If the principal identifies an AWS account, then it is trusting the AWS account as a whole. In a sense, all users in that account have been included in the trust policy, but to assume the role they also need permission to make the appropriate AssumeRole API call. This delegates responsibility to the administrator of the other AWS account to decide which users should be able to assume the role.
This can be used to create a hierarchical arrangement of accounts:
All users are created in a single AWS account, which has no other resources.
The actual resources - EC2 instances, S3 buckets, etc - are in separate AWS accounts.
Each account defines roles granting access to some of these services, with a trust policy listing the central account as the Principal. These roles do not list individual users or groups as trusted, they just define sets of permissions.
The users in the central account are each granted AssumeRole access to an appropriate subset of the roles in the different accounts. The effect is similar to using Groups or Managed Policies to grant multiple users the same access.
What is (or should be) the relationship between a S3 bucket policy and its designated administrator's user policy?
E.g. suppose I've newly created a bucket:
$ aws --profile admin --endpoint-url http://localhost:4572 s3 mb s3://foo
make_bucket: foo
I want user bucket_admin to be able to administer the bucket (not necessarily exclusively). To do this, should I create/apply a bucket policy along the lines of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Principal": { "AWS": "arn:aws:iam::000000000000:user/bucket_admin" },
"Resource": "arn:aws:s3:::foo/*"
}
]
}
...or create/apply a user policy along the lines of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource":["arn:aws:s3:::foo/*"]
}
]
}
?
Your bucket policy applies to only one principle, the bucket_admin user. It can't be used by a role, other IAM user or a group, if you want to have more identities being able to administer the bucket.
The IAM policy does not have a principle by definition. It means you have to attach it to an identity, such as IAM role, user or group. This gives you more flexibility on how to distribute the permissions to the bucket. It can be only the bucket_admin, or you can create a group of bucket admins, or have role which can be assumed by an EC2 instance.
Also with IAM policy it is easier to check who/what is using it. You just go to IAM console, and to Policy Usage and you will get a list of all identities which use the policy. With bucket policies, you have to go manually over all buckets and inspect their policies to check who can be admin of buckets.
Good general comparison of resource vs IAM policies is here:
Identity-Based Policies and Resource-Based Policies
Also useful read as IAM policies can be attached to roles:
How IAM Roles Differ from Resource-based Policies
In addition to #Marcin's answer, which is great...
We use bucket policies mostly for bucket-level checks - ensure the traffic is SSL, ensure the traffic originates from a specific VPC, etc.
Using roles attached to IAM users is an easier way of controlling user access.
The exception is where a user is trying to access a bucket in another account - in this case, both a bucket policy and an IAM policy is needed https://docs.aws.amazon.com/AmazonS3/latest/dev/example-walkthroughs-managing-access-example2.html
I have an application where I am using Cognito to authenticate users and giving temporary access to AWS Console but that user is able to see all other buckets, I want that user just should be able to see or access buckets created by him.
Currently, I have given S3FullAccess Policy to Cognito users. Can anyone suggest which policy I should attach?
As per my R&D, I can some policies are there that can restrict particular user or allow particular user but my users will be dynamic, so I cannot hard-code the values and also policies like allowing/restricting access to particular buckets, I want only users who create buckets should be able to access not other users.
This is something which i found
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:userid}/*"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name/home/${aws:userid}",
"arn:aws:s3:::bucket-name/home/${aws:userid}/*"
]
}
]
}
But this is listing all buckets and the only accessible bucket is what put in the code above, I want for new user, it should show nothing and as it creates, it should show that only
This is not going to be easy and you will need to create your own policy and enforce some conventions. You have 3 options.
But first, if each user just needs their own S3 space look at S3 Prefix [here](
https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-authentication-part-3-roles-and-policies/) Also, you can do this on the S3 resource bucket. I have a template for doing this here in gitlab
Now back to answering your question.
Option 1; They will need to set a tag when they create the bucket where an "owner" tag is equal to their identity. I striked this one out because despite being listed in the IAM policy I'm pretty sure it doesn't work with S3.
Option 2: The prefix of the bucket name is equal to their identity.
Then you can use the feature of variables and tags in IAM Policy. Read here
Note that coginto users are web federated identities so the variable aws:username is not aviable for you. Use the aws:userid variable and the value will be role id:caller-specified-role-name where role id is the unique id of the role and the caller-specified-role-name is specified by the RoleSessionName parameter passed to the AssumeRoleWithWebIdentity request
Option 3: Use IAM Access Policy
I can not find a link to the how to at the moment. But from here is a detailed description.
Q: How do I control what a federated user is allowed to do when signed in to the console?
When you request temporary security credentials for your federated
user using an AssumeRole API, you can optionally include an access
policy with the request. The federated user’s privileges are the
intersection of permissions granted by the access policy passed with
the request and the access policy attached to the IAM role that was
assumed. The access policy passed with the request cannot elevate the
privileges associated with the IAM role being assumed. When you
request temporary security credentials for your federated user using
the GetFederationToken API, you must provide an access control policy
with the request. The federated user’s privileges are the intersection
of the permissions granted by the access policy passed with the
request and the access policy attached to the IAM user that was used
to make the request. The access policy passed with the request cannot
elevate the privileges associated with the IAM user used to make the
request. These federated user permissions apply to both API access and
actions taken within the AWS Management Console.
The nice thing about this approach is you programmatically create the access policy.
I know how to create user, group and role in AWS IAM.
I can also attach policies to each of them.
For example, after selecting a group, you can go to permissions tab, and attach some policies to it.
However, I don't know how to attach a role to a user or group.
I looked on documentation and forums, but did not find anything, and appreciate your help.
You can't assign IAM role to IAM user or group, see the notes from this AWS official doc :- https://aws.amazon.com/iam/faqs/
Q: What are IAM roles and how do they work?
AWS Identity and Access Management (IAM) roles provide a way to access AWS by relying on temporary security credentials. Each role has a set of permissions for making AWS service requests, and a role is not associated with a specific user or group. Instead, trusted entities such as identity providers or AWS services assume roles. For more information, see IAM roles.
It looks like it's not straight forward to attach IAM role to IAM user, follow https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html on how to do it.
In the past, I've created IAM role for my ec2-instance and when launching that instance, I can choose that IAM role and my ec2-instance will have all the permissions set in that IAM role, likewise you can assign a role to other ec2-services, this is the most used scenario of IAM role.
To assign IAM role to an IAM user, do the following:
Open the IAM Dashboard
Select the role that you want to assign to an IAM user
Edit the trust policy
add the ARN of the IAM user in the Principal's section
That's it. Now test it out using the Switch Role feature.
Follow the same procedure to assign IAM role to an IAM group.
I'd be careful about modifying trust relationships - if they're poorly configured they can lead to your account or resource being compromised.
When granting explicit access to a user/group on the same account you should not be modifying the Trust Relationship of the role. To clarify further:
The roles should have a trust relationship of something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<YOUR ACC ID>:root"
},
"Action": "sts:AssumeRole",
}
]
}
What this essentially means is I'm delegating permissions to this role to the account listed in "arn:aws:iam::<YOUR ACC ID>:root" -- its now up to the IAM operator of that account to grant access to this role using a policy such as this one:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Effect": "Allow",
"Resource": "<role arn>"
}
]
}
This policy can be attached to a user or group and that user or the users in the group will be able to assume the role that has the trust relationship above.
A User can be placed in a group to gain the permissions associated with the group or can assume a role to enter a session where permissions are now that of the roles. Users have an access key and secret access key.
Groups are only used to provide permissions to users, i.e a user is placed in a group.
Roles are a temporary set of permission, i.e a user assumes a role and is granted temporary credentials for the life of the session. Role sessions will have an access key, secret access key, and a session token.
An IAM role is an IAM entity that defines a set of permissions for
making AWS service requests. IAM roles are not associated with a
specific user or group. Instead, trusted entities assume roles, such
as IAM users, applications, or AWS services such as EC2.
It is clearly documented here.
https://aws.amazon.com/iam/faqs/