There is a policy attached to user/role which is allowed to create other policies and roles, but, for example, original role doesn't have permissions to do s3:PutObject. Is there any way I can prevent this role/user from creating another policy which allows s3:PutObject and elevating it's own permissions by that?
If you grant users the ability to create policies and roles, then you trust them not to abuse it. Very few admins should have this ability.
The way to solve your case is for an uber-admin to create policies and roles, and for your user to be restricted to which policies/roles he can attach (see related article). You can also implement automation to validate the policies created by your uber-admins meet certain conditions.
Related
I want to be able to specify an iam group as the principal within my policy but i have been reading that you cannot specify an iam group as part of a resource based policy. I could potentially add in a list of iam users but then my policy would look really messy. What is the best approach to take if i cannot add an iam group arn as the principal within my policy.
If you cannot specify an IAM group as the principal in a resource-based policy, you have a few options:
Attach the policy directly to the IAM users: In this case, you would
need to specify each IAM user ARN in the policy. This approach can
quickly become messy and difficult to manage as the number of IAM
users grows.
Use an IAM role: An IAM role is a way to grant permissions to AWS
services or applications that run on AWS. You can create an IAM role
that can be assumed by IAM users or IAM groups. You can then specify
the IAM role in the policy instead of the IAM users or IAM groups.
This approach provides a cleaner and more scalable way to manage
permissions.
Use a service control policy (SCP): An SCP is a type of policy that
is used to set permissions boundaries for an AWS account. You can
use an SCP to allow or deny access to AWS services for IAM groups,
IAM users, or IAM roles. This allows you to manage permissions for
multiple users in a centralized and organized manner.
I would recommend option 2 or 3 as the best approach, as they provide a cleaner and more scalable way to manage permissions compared to specifying individual IAM user ARNs in the policy.
Am I able to allow a newly created IAM user to create arbitrary policies but limited to resources he created? For example if I allow a user to create S3 buckets, users and IAM/Bucket policies, I want him to be able to create policies for IAM user that are limited to buckets he created and not other buckets present in the account.
If I'm not able to specify such policy, is there any other way to achieve this? Some kind of namespacing within an account that could isolate that user's resources from all other IAM users?
This is related to AWS IAM Policy to allow user to create IAM User with specific Policy/Roles and I was wondering if something has changed since the time it was asked.
Check out Delegate permission management to developers by using IAM permissions boundaries
The documentation Permissions boundaries for IAM entities
AWS supports permissions boundaries for IAM entities (users or roles). 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
If a user in AWS is having AdministratorAccess policy attached, he has full AWS access for that account. But with permission boundaries attached to that user his access can be confined. For example say the user has permission boundaries set to AmazonDynamoDBFullAccess, then the full access is just confined to DynamoDB.
What is real benefit of above approach, one could have just removed the AdministratorAccess policy and attached AmazonDynamoDBFullAccess to the user to achieve the same restrictions/permissions.
Is there anything more to understand?
That is not not purpose of IAM Permission Boundaries, nor is it the way it operates.
From Permissions boundaries for IAM entities - AWS Identity and Access Management:
AWS supports permissions boundaries for IAM entities (users or roles). 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.
To explain via an example, let's say that a developer needs permission to create an IAM Role in their software development duties. This can be a very dangerous permission to assign because they could create a Role that has full Admin permissions, thereby granting themselves even more permission that desired.
To limit their abilities, a permission boundary could be added to the developer such that they are only able to create an IAM Role if the role they define is attached to a permission boundary that limits the permissions of the Role (eg so it can only be used to access S3 and DynamoDB, but not other services). It can be a little confusing, but think of it as a set of rules that must be attached to any permissions they give, so that they can't grant full permissions. It's a way to grant them permissions, but limits what permissions they can on-grant to other entities.
This concept is totally separate to assigning IAM managed policies that you mention in your question. In most circumstances, assigning an IAM managed policy is perfectly sufficient. Permissions boundaries only really apply when somebody has permission to create new IAM entities.
Suppose, I am AWS IAM user, is there any way so that I can check what resource permission has been given to me, using CLI or Console.
Unfortunately, there is no comprehensive tool for that. In IAM console you can only check your user's IAM profile or group permission you belong to.
But full set of privileges is a very complex thing to get. Apart from obvious IAM user or group permissions you can have:
IAM roles which you can assume,
resource policies which you are listed as a principle (e.g. bucket policy, kms key policy),
resource policies where a role you can assume is a principle,
cross-account permissions in IAM roles or resource policies,
AWS Organization level SCP permissions.
If the reason for asking this question is related to security, e.g., to check what resources were accessed by a compromised IAM user credentials, you suspend the credentials or delete the user. Also can inspect the CloudTrial history to check what resources a given IAM user accessed.
How do ECR policies differ from IAM policies?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Does it allow you to grant access not using IAM?
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Yep, they are. Both ECR repository policies and S3 bucket policies control permissions of specific resources rather than permissions of principals (identities). In the case of ECR, it lets you define permissions for a specific repository.
Does it allow you to grant access not using IAM?
Sort of. You need both an IAM policy and a repository policy to express some kinds of permissions. For example, an IAM policy on a user might have permissions like ecr:* in order to allow the user to make API calls to ECR and then a repository policy might grant control over a particular repository.
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
This is one of the primary use-cases of repository policies. A user in account A might have permission to make ECR API calls with ecr:* in the IAM policy. A repository in account B could then grant cross-account access to account A, at which point the account A user does not need to assume a cross-account role in order to access the repository.
According the documentation, you can allow cross-account access to your ECR with just the repo policy:
For Principal, choose the scope of users to apply the policy statement to.
You can apply the statement to all authenticated AWS users by selecting the Everybody check box.
You can apply the statement to all users under specific AWS accounts by listing those account numbers (for example, 111122223333) in the AWS account number(s) field.
You can apply the statement to roles or users under your AWS account by checking the roles or users under the All IAM entities list and choosing >> Add to move them to the Selected IAM entities list.
So you don't need to setup cross-account role assumption, but I imagine you would have to grant the appropriate permissions to the users/groups/roles in the remote account to allow them to talk out to your ECR.