There are methods to list inline policies, user managed policies and aws managed policies etc
I couldn't find one to list the boundaries attached to a user.
I suppose there could be a way to add tags with users/boundaries to the policy and search for policies that have the certain tags.
There is no particular use case here, just wondering if I'd want to get the boundaries for that user, what would be a way to do it.
At a time, you can attach only one permissions boundary to an IAM user. Basically, a permissions boundary is just a managed policy. To retrieve the permissions boundary attached to an IAM user, you can make use of the GetUser call. This will return you the ARN of the managed policy attached as a permissions boundary. To view the JSON of the policy, you would have to subsequently call GetPolicy to retrieve the policy version in use, and then call GetPolicyVersion.
Seems to be the only way to go about it via API/CLI.
Related
I'm currently working on IAM and Access and i'm switching from Roles to Permission Set (to use AWS SSO). I have many custom managed policies, that I can't use with Permission Sets now, so I'm using AWS managed policies such as: PowerUserAccess, ViewOnlyAccess etc.
Some of them are pretty close to what i need but have a bit too many actions. Let's take the PowerUserAccess example.
PowerUserAccess gives all GuardDuty action. I want to block all write actions.
The perfect AWS managed policy for that is: GuardDutyReadOnlyAccess.
Is there an easy way to do that "substraction"?
PowerUserAccess - "Not"GuardDutyReadOnly?
such as:
ManagedPolicies:
- arn:....:PowerUserAccess
- arn:....:PowerUserAccess - 'not' arn:....:GuarddutyReadOnlyAccess
Or do i have to do an inline policy and reverting the GuarddutyPolicy? I would like to avoid Inline policies if possible.
Thanks!
It doesn't have to be inline, but you will have to created another policy. In your case you probably want to create a customer managed policy that denies the guard duty access, and attach that to the users (or even better, to the groups).
Be aware, there is a subtle side effect of doing a deny. If a deny exist it always wins, so if you decide you want to single out a user and grant him/her access to guard duty you'd have to be sure that the deny policy is NOT attached to that user. You can't just give them another policy that includes access.
I am currently learning AWS, and I stumbled upon this scenario where I want to grant access to a service to a user within the same AWS account as mine, using Roles.
So here is the detail of the scenario I am thinking of,
I am currently an admin IAM user 'A'. There is another IAM user 'B' with no access to EC2 service (infact he has access to nothing in AWS!).
I want this user B to temporarily have read-only access to EC2 instances. So I create a role, and attach a policy 'AmazonEC2ReadOnlyAccess' to it.
Now, I want 'B' to switch to this role when he logs in, so that he can view Ec2 instances.
I am aware that this can also be done by creating a group and assigning the policy to that group, and then adding this user 'B' to that group.
But I want to do this using roles.
I am not sure if this is even possible in AWS (or worse if this scenario itself is valid?), because the documentation only speaks about cross-account role switch.
Can anyone help me understand this, and let me know if this is even possible and what I need to do?
I'm not sure why you would do it like this rather than either:
Applying the role to a group and adding the user to a group
Applying the policy directly to a user.
I think you CAN do what you're trying to achieve, but only by giving the user permission to assume a role via a policy, which would mean you would have to give the user permissions via a policy or group anyway (I'm also not sure if this works for roles within the same account) - in this scenario it just makes more sense to apply the policy to the user directly, rather than doing switch roles.
If you really want to go ahead and use switch roles for this, you should be able to modify the guide here to allow you to do so:
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
If you wish to add an IAM user you simply attach the user to the roles trusted entity directly, for an IAM user group it is more complicated.
An additional policy is required to add the IAM user group to the role, as it is otherwise not possible to add IAM user groups to roles. As a result you have 2 policies for each permission to give rather than just 1.
UserGroup → Policy#1 → Role → Policy#2
Policy#1 is attached to the UserGroup and has a sts:assumeRole permission for the Role
Role has a trusted entity for the account it is actually in eg. arn:aws:iam::AWS_ACC_ID:root
Policy#2 has your actual permissions, and is attached to the role.
In the course of working with AWS I quite frequently run into a situation where I would need to confirm that a certain user or a group indeed has the access they should or should not have (or debug a policy that doesn't work correctly). For this purpose, I have created a "myusername-assumable" role whose permissions I can modify, and then assume it to test the given access. However, the problem is that many users have a complex collection of policies comprised of multiple group memberships in addition to some direct-attached policies. Since a role apparently can't be a member of a group, I currently have had to painstakingly rebuild a user's permissions, policy by policy, to match the desired user's or group's permissions I need to validate. To test an IAM user's permissions I could create a temporary set of keys, of course, but I would like to avoid that as a user can choose to rotate their keys at any point, and the presence of an extra key set would be confusing to them.
So my question is, is there any way (a script, a CLI command set..) to extract all the policies attached to an IAM user directly or via a group, and then reattach those policies to a role? I will eventually script this, but if someone happens to have an existing solution, that would be great!
My intention is simple- to create a role that I can assign to a standard user of my AWS account so that they can read/write to one of my S3 buckets.
I've created a policy to apply to the role and I'm happy with that bit.
The thing I'm a bit confused about is the "Select Role type" screen in the management console (see attached image). I can't work out what I'm supposed to choose at this stage as none of the descriptions seem to apply to the simple thing I'm trying to achieve.
Does anyone have any idea?
I think you are on the wrong path here. Roles are not ACLs for users, but for systems and services.
See: IAM Roles
If you want to grant a user access to some AWS resources you should have a look at the policy section. Either use a pre-build (like AmazonS3ReadOnlyAccess or AmazonS3FullAccess) or define a policy on your own.
You can then assign this policy to a user. If you want to manage multiple users this way, you can also use groups to assign policies to users.
As part of the process for onboarding new customers, I need to create an S3 bucket, create a new user, and grant that user permissions to get, list, and put to that bucket. I'd like to automate this process, which means that I need to create a "Provisioning" policy that grants a service only the permissions needed to do these things.
It seems pretty straightforward to use String Conditions in my Provisioning Policy to require the names of Users and Buckets start with a certain prefix. However, the PutUserPolicy seems to just take a text blob as its argument. I'd prefer to limit my Provisioning Policy to only be able to create Policies that grant the specific permissions that I need here; ideally only being able to grant users who names match a pattern the ability to get, list, and put to buckets who names match a pattern. (If this Policy is somehow hijacked, I'd prefer to limit their ability to create a user and grant it all privileges.)
Is there any way to get this level of fine-grained control?
No. IAM doesn't go into this much detail. You can't say "Only allow a user to create a policy with these permissions".
You would need to design your system in such a way that this policy can't be hijacked. Create a template policy and just make sure a new user can't inject anything into the inputs.
Also, on a separate note, it would be considered much better practice to use one bucket and give each user a folder inside that bucket. You can still control permissions to a key in a bucket. See the blog for more on this.