AWS IAM

AWS IAM (Identity and Access Management) is a web service that helps you securely control access to AWS resources. It controls both Authentication (verifying who you are) and Authorization (verifying what you are allowed to do).

By using IAM, you can manage who can log into your AWS account, what specific permissions they have, and which AWS services can interact with one another.

1. Core Components of IAM

IAM revolves around four core concepts that define "Who", "What", and "Where":

• Users: A permanent identity that represents a single person or an application that interacts with AWS directly. A user has a permanent name and a set of static credentials (like a password for the web console, or an Access Key ID and Secret Access Key for the CLI/SDK).

• Groups: A collection of IAM users. You do not assign permissions directly to individual users. Instead, you assign a permission policy to a Group (e.g., a "Developers" group or an "Admins" group), and any user added to that group automatically inherits those permissions.

• Roles: A temporary identity that does not have permanent passwords or access keys. Instead, a role is "assumed" by someone or something that needs temporary access permissions. When a role is assumed, AWS Security Token Service (STS) dynamically generates short-lived safety credentials that expire automatically (usually within 1 to 12 hours).

  • Example: If an application running on an EC2 instance needs to read files from an S3 storage bucket, you do not hardcode a user’s access keys inside the app. Instead, you create an IAM Role with S3 read permissions and assign that role directly to the EC2 server hardware.

• Policies: A JSON document that formally defines permissions. Policies state exactly which API actions are allowed or denied, on which specific resources, and under what conditions. Policies can be attached directly to Users, Groups, or Roles.

2. Structure of an IAM Policy Document

An IAM policy is written as a structured JSON object containing one or more declaration statements. A standard policy block uses four mandatory explicit elements:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadForLogs",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-production-logs",
        "arn:aws:s3:::company-production-logs/*"
      ]
    }
  ]
}

• Effect: Determines whether the policy block will Allow or Deny the requested action.

• Action: Specifies the specific API operation or list of operations being targeted (e.g., s3:GetObject, ec2:StartInstances, dynamodb:PutItem).

• Resource: Identifies the precise AWS asset the actions are targeting, defined using an ARN (Amazon Resource Name) format (e.g., arn:aws:s3:::bucket-name).

• Condition (Optional): Specifies the exact criteria under which the policy is valid, such as restricting access to a specific corporate IP address range, enforcing multi-factor authentication (MFA), or checking a date timestamp.

3. The Policy Evaluation Logic Hierarchy

When a user, script, or application makes an API request to AWS, the IAM service evaluates all attached policies following a strict, predictable constraint-satisfaction sequence.

• 1. Default Deny: By default, all requests are implicitly denied from the start. If no explicit policy matches the request, the request is rejected.

• 2. Explicit Deny Check: The engine evaluates every applicable policy layer. If a single "Effect": "Deny" statement is found anywhere in any policy matching the request, the evaluation stops immediately and the request is rejected. An explicit deny always wins over an allow.

• 3. Evaluation Sequence: The request must move through multiple security validation boundaries:

  1. Organization Service Control Policies (SCPs): Verifies if the parent AWS account permits the action.

  2. Resource-based Policies: Checks if the targeted resource allows the request (e.g., an S3 Bucket Policy).

  3. IAM Permissions Boundaries: Validates if the user's maximum assigned privilege limit allows the action.

  4. Identity-based Policies: Checks the inline or managed policies attached directly to the user or assumed role.

• 4. Final Decision: If an explicit "Effect": "Allow" matches the requested action and resource across the required layers, and absolutely no explicit Deny exists, the request is changed to an Allow. Otherwise, it reverts back to the default implicit Deny.

4. IAM Best Practices for Production

• The Principle of Least Privilege: Never grant wide administrative access ("Action": "*") to developers or applications. Only grant the absolute minimum permissions required to perform the specific job task.

• Enforce Multi-Factor Authentication (MFA): Require hardware or virtual MFA tokens for all human users logging into the management web console, especially for accounts with administrative access.

• Never Create Permanent Root Access Keys: The root user account (created via the initial email address) has absolute power. Lock the root credentials away, configure MFA immediately, and use IAM roles and identity-based accounts for daily engineering operations.

• Utilize IAM Roles for Compute Resources: Do not store long-lived access keys inside server configuration files, environment variables, or Git repositories. Use EC2 Instance Profiles or ECS Task Roles to inject short-lived, automated security tokens natively.