AWS IAM Trust Policy for S3: A Comprehensive Guide

In the realm of Amazon Web Services (AWS), Identity and Access Management (IAM) plays a crucial role in securing resources. When it comes to Amazon Simple Storage Service (S3), which is a scalable object storage service, IAM trust policies are essential for controlling who can access your S3 buckets and the actions they can perform. An IAM trust policy defines the entities that are trusted to assume a role and access S3 resources. This blog post will delve into the core concepts, typical usage scenarios, common practices, and best practices related to AWS IAM trust policies for S3.

Table of Contents#

  1. Core Concepts
  2. Typical Usage Scenarios
  3. Common Practices
  4. Best Practices
  5. Conclusion
  6. FAQ
  7. References

Article#

Core Concepts#

IAM#

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to manage users, groups, and permissions. With IAM, you can define who can access which AWS services and resources and under what conditions.

Trust Policy#

A trust policy is a JSON document that defines which principals (such as IAM users, roles, or AWS accounts) are trusted to assume a role. When a principal is trusted, it can use the permissions associated with that role. In the context of S3, a trust policy can be used to allow other AWS services or external entities to access your S3 buckets.

S3#

Amazon S3 is an object storage service that offers industry-leading scalability, data availability, security, and performance. You can use S3 to store and retrieve any amount of data at any time, from anywhere on the web. S3 buckets are the fundamental containers that hold your data.

Relationship between IAM Trust Policy and S3#

An IAM trust policy can be attached to an IAM role. When a trusted principal assumes this role, it can then access S3 resources according to the permissions defined in the role's permissions policy. For example, a trust policy can allow an AWS Lambda function to assume a role, and the permissions policy attached to that role can grant the Lambda function access to read and write objects in an S3 bucket.

Typical Usage Scenarios#

Cross - Account Access#

Suppose you have two AWS accounts: Account A and Account B. Account A owns an S3 bucket, and Account B needs to access the bucket. You can create an IAM role in Account A with a trust policy that trusts Account B. Then, you can attach a permissions policy to the role that allows the necessary S3 actions (e.g., read, write). Users or services in Account B can then assume this role to access the S3 bucket in Account A.

Service - to - Service Access#

Many AWS services need to access S3 buckets as part of their normal operation. For example, an AWS Glue job might need to read data from an S3 bucket to perform data processing. You can create an IAM role with a trust policy that trusts the Glue service. The permissions policy attached to the role can grant the Glue job access to the relevant S3 bucket.

External Identity Providers#

If you are using an external identity provider (IdP) such as Active Directory or Okta, you can configure an IAM trust policy to trust the IdP. Users authenticated by the IdP can then assume an IAM role with permissions to access S3 buckets. This enables seamless integration between your on - premise identity infrastructure and AWS S3.

Common Practices#

Defining a Simple Trust Policy#

Here is an example of a simple trust policy that allows an AWS account (identified by its account ID) to assume a role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

In this example, the account with the ID 123456789012 is trusted to assume the role.

Combining with Permissions Policies#

A trust policy only determines who can assume a role. You also need to attach a permissions policy to the role to define what actions the role can perform on S3 resources. For example, the following permissions policy allows the role to list all buckets and get objects from a specific bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::*",
                "arn:aws:s3:::my - bucket/*"
            ]
        }
    ]
}

Best Practices#

Least Privilege Principle#

Always follow the principle of least privilege when creating IAM trust policies and permissions policies. Only grant the minimum permissions necessary for a principal to perform its tasks. For example, if a Lambda function only needs to read objects from a specific S3 bucket, don't grant it write permissions or access to other buckets.

Regular Review and Auditing#

Periodically review your IAM trust policies and permissions policies. Remove any unnecessary trust relationships or permissions. This helps to reduce the attack surface and ensure that only authorized entities can access your S3 resources.

Use Conditions in Policies#

You can use conditions in your IAM policies to add an extra layer of security. For example, you can restrict access to S3 resources based on the source IP address, the time of day, or the AWS region. Here is an example of a policy that restricts access to requests originating from a specific IP range:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my - bucket/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "192.0.2.0/24"
                }
            }
        }
    ]
}

Conclusion#

AWS IAM trust policies for S3 are a powerful tool for controlling access to your S3 resources. By understanding the core concepts, typical usage scenarios, common practices, and best practices, software engineers can effectively manage who can access their S3 buckets and what actions they can perform. Following the best practices, such as the principle of least privilege and regular auditing, helps to ensure the security and integrity of your S3 data.

FAQ#

What is the difference between a trust policy and a permissions policy?#

A trust policy defines which principals are trusted to assume a role, while a permissions policy defines what actions the role can perform on AWS resources (such as S3 buckets).

Can I use a trust policy to allow access from multiple AWS accounts?#

Yes, you can include multiple AWS account ARNs in the Principal section of the trust policy to allow access from multiple accounts.

Do I need to create a new role for each different type of access?#

It depends on your requirements. In some cases, you can reuse a role with different permissions policies attached. However, for security reasons, it's often better to create separate roles with specific permissions for different types of access.

References#

2025-10