AWS – IAM

IAM stands for Identity and Access Management, is Amazon web service that manages your users and their access to your AWS resources. You use IAM to control who is authenticated and authorized to use AWS resources such as EC2 servers, SQS queues, or Route53. It is so important for you to know what IAM is and how it works if you are managing your company’s AWS infrastructure.

IAM role is universal which means that you have one IAM web service for all regions.

The “root account” is the account that you set up when you sign up with AWS. This account has admin access to your AWS resources. As a best practice, do not use your root user credentials for your daily work. Instead, create IAM entities (users and roles) for your daily work. It is highly recommended that you do not share your root user credentials with anyone because doing so gives them unrestricted access to your account. It is not possible to restrict the permissions that are granted to the root user.

It is highly recommended that you create an IAM user for yourself and then assign yourself administrative permissions for your account. You can then sign in as that user and add more users as needed. Also set up multifactor authentication for you and for all the users within your AWS account. This will add another layer of security to your AWS environment.

What does IAM do?

• Authenticates and authorizes your users (users and roles) to perform actions on AWS resources (biggest task).
• Centralize control of your AWS account.
• Share access to your account.
• Granular permissions.
• Multi-Factor authentication for users.
• Rotate user password.

Secret and Access keys

You only see the secret and access keys once, when creating a new user or when generating new keys, so save them in a secure location.

You use secret and access keys to make requests to AWS APIs from your code or from CLI.

You don’t use your secret and access keys to log in to your AWS console.

Terms to remember

Users – a user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials. Think of this as people who have access to your AWS account. An IAM user doesn’t have to represent an actual person; you can create an IAM user in order to generate an access key for an application that runs in your corporate network and needs AWS access.

Groups – a collection of users under a set of permissions.

Roles – a role specifies a set of permissions that you can use to access AWS resources that you need. It is like a user. You mostly use roles when you are already in one AWS resource and you want to use another AWS resource.

Policies – a policy is an object (document) in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal entity (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied.

Principals – a person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS.

Authentication – to authenticate from the console as a root user, you must sign in with your email address and password. As an IAM user, provide your account ID or alias, and then your user name and password. To authenticate from the API or AWS CLI, you must provide your access key and secret key. You might also be required to provide additional security information.

Authorization – you must also be authorized (allowed) to complete your request. During authorization, AWS uses values from the request context to check for policies that apply to the request. It then uses the policies to determine whether to allow or deny the request.

Resource – an AWS resource is an object that exists within a service. Examples include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket.

Policy – 3 types of IAM policies

AWS Managed Policy – an AWS policy is created and administered by AWS and can’t be changed by users. AWS managed policies are designed to provide permissions for many common use cases. Full access AWS managed policies such as AmazonDynamoDBFullAccess and IAMFullAccess define permissions for service administrators by granting full access (Create, Read, Update, Deleted) to a service.

Customer Managed Policy – Customer managed policies are policies that you create and that you can attach to multiple users, groups, or roles in your AWS account. You have complete control over these policies. A great way to create a customer-managed policy is to start by copying an existing AWS managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment.

Inline Policy – an inline policy is a policy that’s embedded in a principal entity (a user, group, or role)—that is, the policy is an inherent part of the principal entity. Once you delete the entity the inline policy goes with it.

AWS IAM Best Practices

• Throw away your root account access keys. In 99% of cases, you don’t need them. I have not found a reason to use root user access keys.
• Create individual users for whoever needs access to your AWS environment. Don’t share credentials especially root account console login and access keys.
• Use groups to give users permission like backend-dev for backend developers, frontend-dev for frontend developers, data for data developers, or dev-ops.
• Grant the least privilege. When you create IAM policies, grant only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.
• Use an AWS managed policy before creating a customer-managed policy.
• Use a customer-managed policy before creating an inline policy.

---