I have one organization with multiple sub accounts. I would like to create IAM Policies that grant users full administrator access to any resources in specific sub account (or sub accounts). How can this be achieved?
From an AWS Organization perspective, you have control over the accounts and resources via Service Control policies (SCPs).
"However, an SCP never grants permissions. Instead, SCPs are JSON policies that specify the maximum permissions for the affected accounts."
With that in mind, you can't grant users full administrator access to any resources in a specific subaccount(s) using AWS Organization and AWS IAM Policies only.
This leads us to (roughly) 3 paths:
By default, if you create a member account as part of your organization, AWS automatically creates a role in the account that grants administrator permissions to IAM users in the management account who can assume the role.
The IAM Role in question is OrganizationAccountAccessRole. You can customize its name and use it to grant your users full administrator access across all the resources inside the AWS account.
See: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
Observations: Since this IAM Role is created in every account. You would need to intervene and limit the IAM Cross-Account access manually in each sub-account.
You can use AWS CloudFormation StackSets to deploy across multiple AWS accounts a list of IAM Roles your users could use for admin purposes (eg RoleFullAdmin, RoleReadOnly, RoleDevOps), and AWS Organizations enables you to create stack sets with service-managed permissions, using a service-linked role that has the relevant permission in each member account.
From your AWS Organizations management account (or delegated administrator account) you can deploy Stack Sets to current accounts and they are automatically deployed to every new account your create, keeping your resources in sync.
You can target accounts via account ID or organizational units (OUs).
See: https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html
Observations: Similar to 1, since you are using IAM Role Cross-Account access, you need to manually intervene in the policy trust relationship.
Add AWS IAM Identity Center (successor to AWS Single Sign-On) to your AWS Organizations
What you are looking for can be achieved by Permission Sets in the AWS IAM Identity Center.
You can customize the access per user and have a many-to-many relationship between User <-> Accounts <-> Roles. You can define one or more IAM Policies in the Permission Set.
AWS provides predefined permissions that you can use too.
See: https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html and https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetpredefined.html
Observations: You need to add an extra resource to your AWS Organization and configure the identity source of your users. This also requires a change in the process of "how to login to our aws account". Now you need to use the AWS SSO etc.
Related
A policy can be attached to a user or group. This controls what the users are able to do in AWS.
Policy can be attached to an AWS service? What is the relation between policy and AWS service?
And where does the concept of Role fit in all this?
In Amazon Web Services (AWS), a user is a person or system that interacts with the AWS platform. Users can have different levels of access to AWS services and resources, depending on their permissions.
A group is a collection of users that share the same permissions. Groups can be used to manage the permissions of multiple users at once, making it easier to manage and control access to AWS services and resources.
A role is a set of permissions that can be assumed by a user or system. Roles are used to grant users and systems access to AWS services and resources, without having to share or manage long-term credentials. Roles can be temporary or permanent, and can be assumed by users, applications, or services.
A policy is a document that defines the permissions for a user, group, or role. Policies are written in the AWS Identity and Access Management (IAM) policy language, and specify the actions and resources that a user, group, or role is allowed to access.
AWS services are the core components of the AWS platform, and include a wide range of cloud-based services for computing, storage, networking, analytics, machine learning, and more. AWS services can be accessed by users, groups, and roles, depending on the permissions granted by policies.
In summary, the relation between user, group, role, policy, and AWS services is as follows:
A user is a person or system that interacts with AWS services.
A group is a collection of users that share the same permissions.
A role is a set of permissions that can be assumed by a user or system.
A policy is a document that defines the permissions for a user, group, or role.
AWS services are the core components of the AWS platform, and can be accessed by users, groups, and roles with the appropriate permissions.
Think of role like a container holder for permissions which can be used to delegate access to users, applications, or services that don't normally have access to your AWS resources.
From docs
An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied
I have create a new Firestore project and want to be able to create, update and delete but simply trying to list buckets gives me the following error:
<user>#<project>.iam.gserviceaccount.com does not have storage.buckets.list access to the Google Cloud projec
In GCP When searching filtering roles, there doesn't appear to be specific storage or bucket roles. Similarly the only firestore role is Firestore Service Agent but can't see how to apply it.
I think I am confused by IAM, Principles, roles. Looks like IAM has permissions and roles attached to it and a principle is another name for the user?
Either way, how can I apply the correct roles and permissions to my service account credentials so that I can list buckets?
EDIT:
Screenshot
If you want your service account to have full access to the bucket(s), you can give it the IAM role Storage Admin. IAM roles actually include a bunch of permissions, in this case, it includes storage.buckets.list and many other permissions.
If you want more restriction on the service account permissions, you could give it some other roles defined here: https://cloud.google.com/storage/docs/access-control/iam-roles. For instance, if the service account only has to read information in buckets, you could give it the role Storage Object Viewer.
Another way to do it would be to give your service account role(s) directly in each bucket instead of defining the role in IAM. This way, you can give a service account access to a single bucket instead of giving it access to all the project's buckets.
Started recently understanding AWS IAM Roles, Groups, Roles and Permissions.
I understood that groups will be added with some Permissions and whoever the users got added into that group, will have an access to those specific AWS services provided in that group. Where as Role is used to provide an access from one Service to Other. (Say Lambda wants to have an access for CloudWatch).
My Query is: Suppose if Group (say 'dev') have added only 2 Permissions policy (say S3FullAccess, LambdaFullAccess)
and Role created for Lambda Service (having Permission policy "cloudwatchFullAccess"), then does a user from 'dev' group can able to access 'cloudwatch' service?
EDIT:
Another query: I didnt understood on How do we map Users/Groups to only specific Roles? orelse does Roles can be accessed by every user/group (assuming Permission policies already added in Groups of those services mentioned in the Roles)? Please clear me this too
The permissions from the role are only allowed by a principal (IAM user/IAM role/AWS Service) that has assumed the role. If your user had the permission to assume that IAM role and did it, then yes they would have those permissions.
However based on the policies they have they cannot assume the role, but Lambda (assuming it has a trust policy in place) can assume the IAM role in question.
This means that Lambda can perform any CloudWatch interactions, which would allow a user within the dev group to add code that interacts with CloudWatch within the Lambda function and then when triggering the Lambda function see the output of it.
They would not however be able to see the CloudWatch interface within the console, or directly interact with it on the AWS CLI.
To explain the difference between users, groups and role:
An IAM user is an entity with which you can interact directly through the console or CLI. It requires credentials to perform these interactions and gains its permissions from policies. It is generally advised not to use these for applications that reside in AWS.
An IAM group is an entity to group similar IAM users, providing them the same permissions. This allows a hierarchy to be easily maintained. No entity can become a group, it is an assignment to an IAM user.
An IAM role is similar to a user, in that it can interact with the console or CLI. However, to do this it must be assumed, which will provide the entity that assumed it with temporary credentials. An AWS service that assumes the role manages these temporary credentials for you.
For a user to assume the role, 2 things would need to be in place. The role would need to have a trust policy that enables the principal of the IAM user (or account) to assume that role. In addition the user would need to have permission to perform the sts:AssumeRole action on the IAM role resource.
More information about this can be found in the Granting a User Permissions to Switch Roles
documentation.
As per AWS documentation here - You cannot switch roles when you sign in as the AWS account root user.
If we go by AWS best practices i.e. not to use root user to perform actions, this restriction makes sense & supports why AWS does not allow role switch as root user. However, when using a Bucket policy, a root user in one account can access a Bucket in another account & AWS does not seem restricting that unlike roles (Technically, both are cross account actions using resource policies).
Why does this 'root user restriction' apply only for roles and not buckets - Any security reasons?
Access to services is normally granted via IAM permissions on IAM Users, IAM Groups and IAM Roles.
Some AWS services also permit the creation of policies that can grant access to aspects of that specific service. Examples are:
Amazon S3 bucket policies
Amazon SQS queue access policies
Amazon SNS access policies
These policies can be used to grant cross-account access, and also unauthenticated access such as public access to objects in Amazon S3 buckets and the ability to send unauthenticated messages to an Amazon SQS queue.
These policies are used to grant additional access. They do not involve "assuming" any additional roles.
I think there is some misunderstanding on the use of roles and a bucket policy with external account's root as principle.
The roles are meant to be temporary assumed, for someone or something that normally does not have permissions for some action. This could be a user or service from same or different account.
However, when you use other account's root in a bucket policy principle, you are giving that account permanent (until manually revoked by you) trust to the bucket for all or some actions on it. You use root as the principle so that the owner of the other account can delegate access to its own users or roles. You fully trust the other account to manage the access to the bucket without your involvement.
Off course if you are not comfortable giving such trust to the other account, you can limit access to you bucket to a given IAM user or a role only. This will obviously limit the ability of the owner of the other account to delegate access to your bucket.
What is the difference between an IAM role and an IAM user? The IAM FAQ has an entry explaining it, but it was vague and not very clear:
An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service such as EC2.
I think an IAM role is used for federated logins (using an IdP with SAML tokens for example), and they don't have permanent access keys that you can download like regular IAM users have (the "an IAM role doesn't have any credentials" part).
What do they mean when they say an IAM role can't make direct requests to AWS services? I can login to AWS Console (the web console) and create stacks etc, so it can't be that.
To understand the difference, let us go through IAM basic knowledge
IAM controls: Who (authentication) can do What (authorization) in your AWS account.
Authentication(who) with IAM is done with users/groups and roles whereas authorization(what) is done by policies.
Here the term
User - End user think about people
Groups- a set of users under one set of permission(policies)
Roles - are used to grant specific permission to specific actors for a set of duration of time. These actors can be authenticated by AWS or some trusted external system.
User and roles use policies for authorization. Keep in mind that user and role can't do anything until you allow certain actions with a policy.
Answer the following questions and you will differentiate between a user and a role:
Can have a password? Yes-> user, No-> role
Can have an access key? Yes-> user, No-> role
Can belong to a group? Yes-> user, No -> role
Can be associated with AWS resources (for example EC2 instances)? No-> user, Yes->role
AWS supports 3 Role Types for different scenarios
AWS service roles (for example: EC2, Lambda, Redshift,...)
Cross-Account Access: granting permissions to users from other AWS account, whether you control those account or not.
Identity Provider Access: granting permissions to users authenticated by a trusted external system. AWS supports two kinds of identity federation:
- Web-based identity such as Facebook, Goolge- IAM support ingeration via OpenID Connect
- SAML 2.0 identity such as Active Directory, LDAP.
To understand what role is, you need to read its use case, I don't want to reinvent the wheel so please read the following AWS documents:
https://aws.amazon.com/blogs/security/how-to-use-a-single-iam-user-to-easily-access-all-your-accounts-by-using-the-aws-cli/
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
Hope it helps.
Main actors in IAM are users, groups, roles and policies. And what you need to understand about AWS and never forget is that
Everything in AWS is an API
And to execute any API or any of its methods, first we have to authenticate and then authorize that particular user/group/role.
Ex: An operator wants to put an object to a S3 bucket. This process happens through a set of API calls within AWS. Basically we call the S3 API and a method of it to put the object into the particular bucket (say method put_object_in_s3). For that we may want to provide the name of the bucket, the object, and most importantly we need to provide set of credentials (username with password or secret key or etc) in order to tell the AWS API Engine who this user/group/role is.
The first thing API Engine does is, look at those credentials sent with the API. Then it validate those (whether they are correct, active) credentials indicating that this request is coming from a actual valid user, group or role. Then what the API Engine does is (as it now knows who sent this API request) it takes the policy documents associated with the particular operator (user or role) and evaluate them as a single view. That is we check whether the action called in the API is authorized for that operator.
IAM user - In the context of IAM, a user is a “permanent” named operator (human or machine). What’s important to note is that it’s credentials (credentials maybe username password or access key or a secret key) are permanent and stays with that named user. So by that AWS knows that what are the authentication methods (username password authentication method or secret key method or etc) for this user (as its permanent and stays with the user).
IAM group - As in the above image, a group is a collection of users. And note that a user can be in many groups as well.
IAM roles - Roles are not Permissions !!!. A role is also an authentication method just as IAM users and groups. As a user, a role is also a operator (could be a human, could be a machine). Difference is that credentials with roles are temporary.
Policy Documents - As stated earlier, roles are not Permissions. Permissions in AWS are completely handled by objects called Policy Documents. Policy Documents are JSON documents. Policy Documents can directly be attached to Users, Groups or Roles. When a policy document gets attached to any of above operator, then only they get permissions do stuff.
A policy document lists things like: Specific API or wildcard group of APIs that gets whitelisted against which resources, and Conditions for those API executions (like allow only if this user, group or role in the home network or allow from any location, allow only at certain times of day and etc)
Last but not least, Authentication in AWS is done via (IAM users,
groups and roles) whereas Authorization is done by Policies.
What do they mean when they say an IAM role can't make direct requests to AWS services? I can login to AWS Console (the web console) and create stacks etc, so it can't be that.
You are an IAM User (with some attached IAM Roles).
Think of IAM Roles as capabilities.
You give an IAM User capabilities (e.g. "can create Lambda function", "can upload to S3").
Note on Federated Users:
From http://docs.aws.amazon.com/IAM/latest/UserGuide/id.html:
A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.
So, a federated user is similar to an IAM user which you can attach IAM Roles to. Except that you have an external identity provider.
Technically, you are NOT using a role as your identity when you login to AWS console. You are using your federated user account (with its own attached roles) as your identity.
An IAM user is an account which can be used by a person or an application. A user has credentials to log in and perform actions with the privileges assigned to that account.
An IAM role is something virtual that a resource can assume. For example, an EC2 instance can assume a role and execute AWS command with that assigned privileges. The same goes for other services like API gateway, Lambda, Kinesis, RDS and so on.
What do they mean when they say an IAM role can't make direct requests to AWS services?
The role itself is not able to perform any tasks since it has to be assumed by somebody or something. Somebody can also be someone logged in through identity federation and then assume a role.
I am practically new to AWS but I have implemented similar concepts in backend applications. Therefore, I would make an attempt to simplify this more from a newbie perspective.
IAM User - This is an actual account registered into the AWS IAM platform. This means that this is a person/application that is an actual entity. Note that this entity can do nothing, just an existence. Like when I signup for an application, my user entity is created and I can log in with provided credentials and have a profile.
IAM Group - This is a collection of specific users. Although this can also give identity, the focus is on the specific individuals that make the group. For example, how we group employees into departments in organizations based on their specific specialities and skillsets.
IAM Policies - This part seems easiest to understand. This is a specific rule/permission/access to a resource spelt out in clear dos and don'ts in a JSON format. Each policy is about a particular resource. A resource can be anything from an EBS volume, a Lamda Function, or even IAM itself.
IAM Role - This is like a title with specific responsibilities, i.e. a group of policies(permissions/access) that anyone with this title will have. For example, if we have a title of "Note-Taker", anyone from different departments can be assigned this title temporarily for a meeting, a period etc. And only those with this permission will be able to access the note-taking app. However, we can have some roles that will fit well with a group, e.g. all members of the accounting department can have the title of an accountant, which gives access to the books of account. But we can have another title of director, which has access to delete books of account, and this will cut across all departments.
Federated Users - These are entities also, but with no profile in the company(IAM). They are like contractors who can be assigned certain roles or titles through an acquired trust from the Federating platform as well as the access due to those titles. The good thing is that if the Federating platforms replace a user, there would be no reason to deactivate the old user and give access to the new one because the platform is the one with the access and not the "user".
IAM User - An user/application accessing AWS Resources
IAM Roles - Set of permissions/policy that can be applicable to an user or resource.
You can apply Roles to IAM user and to an AWS Resource too.
E.g., Apply IAM Role to Lambda Function. Function can only with that IAM Role.
IAM role is an entity which has specific access defined by the policy. And that access is. It doe snot have the permanent creds (Access keys and Secrets Access Keys)- it works on the "AssumeRole" method where token is granted for accessing the different AWs resources.
IAM User has the permanent access keys and secret access keys, we can define the permissions on the resources , IAM ROLE can be assumed by the IAM USER , as it has the keys - it can have access to the resources all the time...
IAM Policy (permissions- read,write etc.) apply to User,Group and Roles.
User- when a user want to access anything in AWS cloud, it must have IAM policy assigned.
Group - when a group of users is assigned with common IAM policy.
Roles - It needs when a service want to access another service. Service must be assigned with role that have policy assigned to perform certain actions in the AWS cloud. In other words, We can't directly assign policies on Service, first we need to create Role and then assign policy on that role.
Note: Roles are intended to be not used by physical people, instead use by AWS services only.