An AWS account has resources and users. It also has an account-id.
By default a root user is created, and this user has complete and unrestricted access to all resources in your AWS account.
AWS IAM is used to manage users (identity) and resource access (access management) on an AWS account.
All AWS resources have a unique identifier known as an ARN.
An IAM user is itself a resource and has an ARN. An IAM Policy, Role, Group are also resources and therefore have ARNs.
IAM users give an identity to external entities (API, CLI, WEB UI). AWS resources already have an identity called an ARN, so a user is just a way of giving external entities an ARN.
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources for your users. You use IAM to control who can use your AWS resources (authentication) and what resources they can use and in what ways (authorization).
IAM is an AWS service that allows you to create users and manage access to AWS resources.
IAM has a few core concepts: User, Policy, Role, Group.
When you first create an AWS account, you are the root user. You can use the root account credentials sign in to the AWS Management Console.
The root user is like the root user on a linux machine, it has complete and unrestricted access to all resources in your AWS account, including access to your billing information and the ability to change the root password.
With this in mind, there are two apparent issues:
- it is not a good practice to regularly access your account with this level of access,
- what to do when another person needs to access and manage your AWS account.
To solve these issues on any physical machine, you would create another user, AWS IAM is used to accomplish this, you can create an IAM user.
An IAM user can be configured to enable sign in to AWS Management Console, and up to two access keys that can be used with the API or CLI.
By default, IAM users can't access anything in your account. You grant permissions to a user by creating a policy and attaching the policy to the user. You can grant one or more of these policies to restrict what the user can and cannot access.
An IAM policy is a rule or set of rules defining the operations allowed/denied to be performed on an AWS resource.
The ruleset is basically a list of permissions.
A policy by itself is useless, as is a newly created IAM user, you can attach policies to a user to grant permissions to a user.
Policies can be granted in a number of ways:
- Attaching a managed policy. AWS provides a list of pre-defined policies such as
AmazonS3ReadOnlyAccess. - Attaching an inline policy. An inline policy is a custom policy created by hand.
- Adding the user to a group that has appropriate permission policies attached.
- Cloning the permission of an existing IAM user.
Example of a policy:
// a policy that grants all operations to all S3 buckets
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
}
// a policy that grants more granular access, only allowing retrieval of
// files prefixed by the string Bobs - in the bucket called Hello-bucket
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::Hello-bucket/*",
"Condition": {"StringEquals": {"s3:prefix": "Bobs-"}}
}
}Aside from attaching a policy to a user, you can attach them to a role or a group.
Sometimes your AWS resources need to access other resources in your account.
For example, if we wanted to restrict a Lambda function's access, we could do this by creating an IAM user and putting that user's credentials to the Lambda function but this isn't secure.
An IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS.
However, a role does not have any credentials (password or access keys) associated with it.
Instead of being uniquely associated with one person, a role can be taken on by anyone who needs it.
In the case of the previous example, the Lambda function will be assigned with a role to temporarily take on the permission.
Roles can be applied to users as well. In this case, the user is taking on the policy set for the IAM role.
A Resource can assume an IAM role, roles are useful as they are dynamic, temporary, reusable.
An IAM group is a collection of IAM users. You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users.
Amazon Resource Names (ARNs) uniquely identify AWS resources. We require an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls.
ARN is really just a globally unique identifier for an individual AWS resource.
It takes one of the following formats:
arn:partition:service:region:account-id:resourcearn:partition:service:region:account-id:resourcetype/resourcearn:partition:service:region:account-id:resourcetype:resource
Some examples of ARN (Note the different formats used):
<!-- Elastic Beanstalk application version -->
arn:aws:elasticbeanstalk:us-east-1:123456789012:environment/MyApp/MyEnvironment
<!-- IAM user name -->
arn:aws:iam::123456789012:user/David
<!-- Amazon RDS instance used for tagging -->
arn:aws:rds:eu-west-1:123456789012:db:mysql-db
<!-- Object in an Amazon S3 bucket -->
arn:aws:s3:::my_corporate_bucket/exampleobject.png