What is an IAM policy, and can you explain the basic structure of a policy document in AWS?

Question

Accepted Answer

An IAM policy is a JSON document that defines permissions by specifying what actions are allowed or denied on which resources. Policies are the mechanism through which you grant and restrict access in AWS and similar cloud platforms.

The basic structure of an AWS IAM policy document contains several key elements. The Version field specifies the policy language version, which should always be set to 2012-10-17, the current version. The Statement field contains one or more individual permission statements, each of which includes the following components.

Effect is either Allow or Deny, indicating whether the statement grants or restricts access. Action specifies the AWS service actions being controlled, such as s3:GetObject for reading S3 objects or ec2:StartInstances for starting EC2 instances. You can use wildcards like s3:* to match all S3 actions, though this should be used sparingly. Resource identifies the specific AWS resources the statement applies to, specified using Amazon Resource Names or ARNs. For example, arn:aws:s3:::my-bucket/* targets all objects in a specific S3 bucket. Condition is an optional element that adds additional constraints, such as restricting access to specific IP ranges or requiring MFA authentication.

There are several types of policies in AWS. Identity-based policies are attached to IAM users, groups, or roles. They define what actions the entity can perform. Resource-based policies are attached to resources like S3 buckets or SQS queues and define who can access the resource. AWS managed policies are pre-built by AWS for common use cases like ReadOnlyAccess or AdministratorAccess. Customer managed policies are custom policies you create for your specific needs. Inline policies are embedded directly within a single user, group, or role.

A key principle to understand is that IAM policies default to deny. If there is no explicit Allow statement for an action, it is denied. If there is an explicit Deny statement, it overrides any Allow statements. This means you can use deny policies as guardrails to prevent specific dangerous actions regardless of other permissions.

In Azure, the equivalent is role definitions and role assignments using Azure RBAC. In GCP, IAM policies bind members to roles on specific resources. While the syntax differs, the core concept of defining who can do what on which resources is consistent across all providers.

A best practice is to start with the most restrictive policy possible and add permissions as needed, rather than starting with broad access and trying to restrict it later. This approach ensures you maintain the principle of least privilege from the beginning.