I have my enterprise Quicksight in place and with users using our company email to register an account (like john.doe#mycompany.com). We're using Gmail for business.
On the other hand we have developed another application backed by AWS Cognito user pool using Google as an identity provider, and since this is the same user base our intention was to use the same user pool for Quicksight access. In addition we will develop a Lambda that would synchronize Cognito user group association with Quicksight memberships if/when necessary.
I've followed the example described here https://aws.amazon.com/blogs/big-data/use-amazon-quicksight-federated-single-sign-on-with-amazon-cognito-user-pools/, but the problem is that even though I login as different users I get access to Quicksight via same IAM role. The Quicksight user associated with this role has a specific username starting with CognitoQuickSight1-AuthRole-KX4Y16... and email associated with the user I used to login the very first time.
Now I'm wondering if in this setup it's even possible to have different roles associated with different users so they can be differentiated on Quicksight side? Or is there any other way to achieve this?
I don't think you can assign QuickSight user specific permission on Federated users.
Some AWS services allows to use the user identity in the resource base IAM policy. For example S3 (to allow user to access only their 'directory' in a bucket) and DynamoBD (to allow user to only access item where their identity is the primary key).
According to https://docs.aws.amazon.com/quicksight/latest/user/security_iam_service-with-iam.html Quicksight does not support Resource based or Tag based policies.
I am writing a user policy using AWS Cognito User Pools for an app that needs to be compatible with an old ad hoc user management system we had previously used on S3 with IAM while we move to a better user management model using Cognito.
The old system used arn:aws:s3:::[Our Bucket Name]/${aws:username}/* in the group policy to only allow a user access to objects using their username. I had thought that using the same username in Cognito would allow us to use a duplicate role policy allowing the Cognito users the same access, but according to this, the aws:username is not present for Cognito; that only has the aws:userid, which, if I am reading this right, is essentially a randomly generated unique string that has nothing to do with the username and so cannot be used for this purpose.
Is there any other way I can give the Cognito user access to a given IAM username's folder in S3 on the basis of the same name through a role policy? The only way I can think of is to make custom policies on a per-user basis, but I would prefer to keep changes to our existing user creation system to a minimum.
Short answer: don't mix IAM with Cognito. Write an app/service/api to provide the objects to the authorized user.
Long Answer: IAM is for admins or services of AWS. Do not mix it with the Cognito. Cognito is for storing and providing tokens to your users. You might ask how to provide the objects within bucket-name/user-test to user-test:
Store User Access Rights in S3: For each user have a bucket access-rights/user-test. It should conclude the user rights; for example you can have as a Json:
{
username: string,
access-bucket-name: string
}
Additional Service: You can have authentication service to check the user is authenticated (using Cognito), then based on the body of the token, get the username; and check its rights (first step) and the application should provide the object from the initial bucket the user wants to access.
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.
I am creating shortlived users on AWS on the fly and while debugging why these newly created logins tended to fail with an InvalidAccessKeyId realised that just adding a small sleep solved the problem.
xref How long should I wait after applying an AWS IAM policy before it is valid? re: time for consistency throughout AWS
My follow up question to the above: is there a way to synchronously create a consistent IAM policy? Or at least a way to know they are ready to use?
Amazon IAM is not designed for providing short-lived credentials. You should create IAM Users for long-lived requirements, such as logins for humans and logins for persistent applications.
An IAM User should not be used for application login purposes. For example, if you are creating an Instagram-like application, you should maintain your own database of users or utilize Amazon Cognito for user authentication.
So, how do you then grant users access to AWS resources? For example, if you have an Instagram-like application and you wish to grant application users the ability to upload/download their pictures in Amazon S3 but want to restrict access to a certain bucket and directory?...
The answer is to create temporary credentials using the AWS Security Token Service (STS). Credentials can be created with a given policy for a specific period of time. These credentials work immediately. For example, if an Instragram-like user logs into the app, the backend app could generate temporary credentials that allow the user to access a specific directory within a specific Amazon S3 bucket for a set period of time (eg 15 minutes). These credentials are then passed to the mobile app/web browser for direct access to AWS services.
I am planning on a web page that creates an instance for an user using a specific AMI. Is there any AWS method to let the user approve my web application to do this using their credentials? (i. e. getting a secret token with certain privileges)
Similar to when you let a Facebook application have access to certain information of your profile. I am looking for a way to get a token from the user signed in so that I can create an instance for them.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
I looked into AWS Cognito but this doesn't seem to be what I am looking for.
Similar to when you let a Facebook application have access to certain information of your profile.
AWS and Facebook are not similar in any sense. Facebook is a web application. AWS something entirely different.
Facebook has users, but AWS has accounts, which in turn have users... but in AWS, don't need a user's permission to do things to resources -- what you actually need is an account's permission to do things to its resources, because resources are associated with the account, not the user.
I am looking for a way to get a token from the user signed in so that I can create an instance for them.
Users sign in to the AWS console. After this, there is no such concept as a user allowing an external application doing things under the "signed in" user's auspices.
The user has to have sufficient permissions to either create sufficiently-privileged temporary IAM credentials (such as with GetSessionToken or AssumeRole from the IAM API) and hand them over to you, or create an IAM user with sufficient privilege and hand the keys to that user over to you... or you provide them with the ARN of one of your IAM users, and your customer gives your user permission to perform the actions or assume a role in your customer's account, created for the purpose.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
That can't be avoided, by design... and, in any event, whatever exactly you are planning, your model seems flawed: it would only be a naïve user who would allow you to do this. I have accounts that are allowed to launch hundreds of instances concurrently. Does it make sense that I would allow a third party to have access to credentials that could run up a huge bill for me? (If AWS trusts a set of credentials to launch instances, then it trusts them to launch instances -- all the way up to the account's instance limits).
If you want a user to be able to launch an instance from your AMI, you can simply list it on the AWS Marketplace, or you can share the AMI with the user's account, or even just make the AMI public.