Due to the excessive power of root permissions, it is necessary to divide them into multiple users and groups to set permissions.

AWS IAM
What is IAM?

Operation Mechanism

The architecture of IAM is as follows:

graph LR;

Policy1-->Permission;
Policy2-->Permission;
Policy3-->Permission;
Permission-->Role;
Permission-->Group;
Group-->User;
User-->Password;
User-->Credentail;
Role-->id1[External Users];
Role-->id2[AWS Internal Services];

Policy

Official Documentation

When a policy is attached to a user or group, it allows or denies permission for the user to perform specific tasks on specific resources.

It is defined in JSON format, and there is a graphical tool Visual Editor available
Written policies can be tested using IAM Policy Simulator

Components

• Effect
• Action
• Resource
• Condition
• Principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Effect

It can be Allow or Deny
By default, IAM users do not have permission to use resources and API actions, so all requests are denied
When both Allow and Deny are present, the Deny policy is applied, prioritizing security
By default, everything is denied, so usually, you need to write Allow policies.

Action

List of operations permitted or denied by the policy

Example:

"Action": [
    "ec2:AuthorizeSecurityGroupIngress",
    "ec2:AuthorizeSecurityGroupEgress",
    "ec2:RevokeSecurityGroupIngress",
    "ec2:RevokeSecurityGroupEgress",
    "dynamodb:*"
],

Resource

Resources affected by the policy

Example:

"Resource": "arn:aws:ec2:region:account:security-group/*",

Condition

Optional parameter used to control when the policy takes effect
For example, access to S3 is only allowed when connecting from a specific IP or using MFA for login

Example:

"Condition": {
    "IpAdress": {
        "aws:SourceIP": "10.14.9.0/14"
    }
}

Principal

Principal

An optional parameter that specifies the entity restricted by the policy, such as “User” or “Application”

Example:

"Principal": { 
  "AWS": [
    "arn:aws:iam::123456789012:root",
    "999999999999"
  ],
  "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}

Permission

Consists of multiple policies assigned to users, groups, or roles

IAM Group

Permissions can be assigned to a group
Adding a user to a group grants them the group’s permissions, making it easier to manage or change permissions

IAM User

Managed by the root account
When logging in through the web, a unique 12-digit ID is used with an account password
For programmatic or CLI operations on AWS, Credentials are required

For security reasons, it is common to create an admin IAM user for management
Rather than using the root user directly

• IAM users can belong to one or more IAM groups
• IAM users cannot belong to one or more IAM roles simultaneously; switching must be done through Assume Role
  • Assume Role is also an action in a policy (“Action”: “sts:AssumeRole”)

Role

Can be used for external system integration or communication between internal AWS services

For example, placing a role that allows creating S3 Bucket Policies on an EC2 instance
Allows the EC2 instance to issue commands or use programs to create S3 Buckets

Without long-term login credentials (password/access keys), temporary security login data is generated during the session

Using roles effectively can avoid frequent adjustments to user policies

For example:

Normally, a user’s access to S3 is restricted
After applying a role with Admin permissions, they gain S3 Admin permissions

Supplement

AWS Access Analyzer can be used to track changes in project permissions