AWS IAM Basic Concepts

Amazon Access Control (AWS Identity and Access Management)

IAM is used to control permissions on AWS resources that can be applied to a group of users as well as to individual users. At the same time, IAM can also be combined with other authentication systems, such as with Shibboleth, Microsoft ActiveDirectory. At the same time, you can also audit the access information (using AWS CloudTrail)

IAM enables you to securely control user access to AWS services and resources.
You can use IAM to create and manage AWS users and groups, and use various permissions to allow or deny their use of AWS resources

What is IAM?

AWS Identity and Access Management (IAM) is a web service that
Helps you securely control access to AWS resources.
You can use IAM to control which user is authenticated (logged in) and authorized (has permissions) to use resources.

When you first create an AWS account, you initially use a single sign-on identity with full access to all AWS services and resources in the account. This identity is called the AWS account root user, and you get it by logging in with the email address and password you used to create your account. It is strongly recommended that you do not use the root user for day-to-day tasks, even administrative tasks. Follow the best practice of using the root user only to create your first IAM user. Then keep your root user credentials safe and use them only for a few account and service management tasks.

basic concept

User

Instead of sharing your root account credentials with others, you can create individual IAM users in your account that correspond to users in your organization. IAM users are not separate accounts; they are users within your account. Each user can have their own password for accessing the AWS Management Console. You can also create individual access keys for each user so that users can make programmatic requests to use resources in the account

Each user may have his own username/password, as well as a secret key to access AWS resources (Access key ID and Secret access key), which can be used to access AWS resources in the program

Group

An IAM group is a collection of IAM users. Groups allow you to assign permissions to multiple users, making it easier to manage those users' permissions. For example, you might have a group called Admins and grant that group the types of permissions that administrators typically need. Any user in the group automatically has the permissions assigned to the group. If a new user joins your organization and requires administrator permissions, you can assign the appropriate permissions by adding the user to a group. Likewise, if someone in your organization changes jobs, you don't have to edit that user's permissions, just remove him from the old group and add him to the appropriate new group

A group represents a combination of users, such as admin, manager, customer, and so on.

Role

An IAM role is similar to a user in that it is an AWS entity that has permission policies that determine what it can and cannot do in AWS. However, roles are designed to be assumed by anyone who needs them, not uniquely associated with a person. Also, roles do not have any associated credentials (passwords or access keys). Conversely, if a user is assigned to a role, an access key is dynamically created and provided to the user

A role can be understood as a combination of policies. For example, DBOperator may have permission to operate the DynamoDB database. The person using the Role could be a user, or it could be an AWS service such as Lambda.

Role is like a hat, whoever wears it has corresponding permissions, which is different from User:

• User can log in on the console and has permanent authentication information, such as username and password, but the role cannot log in and has no authentication credentials
• user is generally used by someone, and role can be used by anyone who needs it, of course, it can also be used by user
• role accesses resources through a temporarily generated key, the default is 1h, the longest is 12h, in the role conduction scenario, the longest is 1h
• User can only exist under a certain account, role can be cross-account, but user can achieve cross-account by switching to other roles

Policies (Access Policies)

Access policies define access rights to AWS resources. It does not define who can access AWS resources, but only what operations can be performed on which AWS resources. As for who can access what resources, it depends on the policy of the user/group

When using AWS to create various policies, you can use this tool (login required): https://policysim.aws.amazon.com/

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "dynamodb:BatchGetItem",
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:eu-west-1:xxxxxxxx:table/ScoreTable>",
    }
  ]
}

Examples of the above four concepts

Take the simplest example: in a CMS system, all data is stored in DynamoDB, and the system is divided into two types of users: admin and customer. The admin can write to the database, and the customer can only read the database. This is how it can be designed like this:

Trust Relationships

Another possibility is that some resources are created based on Account1, and if you want to allow Account2 to access these resources, you need to use Trust Relationships. Its basic steps include:

• Create a Role in Account1 with permissions to access AWS resources
• Create a Trust Relationship in IAM, so that Account1 and Account2 have this trust relationship.
• Account1 allows Account2 to use assumeRole to obtain the Role in Account1, so that when Account2 accesses the resources in Account1, it is equivalent to having the Role in Account1, and this Role has the permission to access AWS-related resources in Account1.

Basic principles of using IAM

Avoid using root account

Just like root in Linux, you should avoid using the root account directly

Minimum authorization principle

Be sure to give the user the least privilege possible, otherwise there may be security risks

Always test thoroughly when changing permissions

Sometimes the combination of various policies can make the final access rights very complicated, so once you change the policy, you must pay attention to strict testing

When policies conflict

If policies conflict, the Deny policy must override the Allow policy