DEV Community: David Kerber

Test S3 ABAC locally with iam-lens

David Kerber — Wed, 10 Dec 2025 13:00:00 +0000

tl;dr

AWS just made managing access to S3 much more powerful, and a bit more complicated. S3 now supports attribute-based access control (ABAC) for general-purpose S3 buckets. With iam-lens, you can simulate and understand exactly how enabling ABAC on a bucket will affect access to a bucket before enabling it. Just add --s3-abac-override enabled to your simulate and who-can commands to see the effects of enabling ABAC on a bucket.

New S3 Attribute Based Access Control Functionality
S3 ABAC Support in iam-collect and iam-lens
Previewing S3 ABAC Locally
- Preview ABAC for a principal with iam-lens simulate
- Preview ABAC for a bucket with iam-lens who-can
Build Confidence Before You Flip the Switch

New S3 Attribute Based Access Control Functionality

In November 2025, AWS announced attribute-based access control (ABAC) for Amazon S3 general purpose buckets. It works more or less as you would expect. Tags on the bucket can be used with the context keys aws:ResourceTag/<tag-key> and s3:BucketTag/<tag-key>.

For example, this policy will only allow access to buckets (or objects in buckets) where the bucket tag Dept is Accounting.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountingBuckets",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetObject"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Dept": "Accounting"
        }
      }
    }
  ]
}

There’s one important caveat: Before this policy will work on a bucket, ABAC must be enabled on each S3 bucket. I assume there are concerns about ABAC suddenly working on S3 buckets in your account without you ensuring it has the effects you want. To enable ABAC on a bucket use the PutBucketAbac API. This is available in the console, the AWS CLI, boto3, and AWS SDKs.

The big question is: what is the impact of enabling ABAC on an S3 bucket?

S3 ABAC Support in `iam-collect` and `iam-lens`

iam-collect will now download the ABAC status of every bucket in your account and store the result in abacEnabled in the bucket metadata. This requires a new permission: s3:GetBucketAbac.

iam-lens will use the bucket information in your iam-collect data store to enable ABAC when running simulate or who-can. So by default, it will do what you expect.

Previewing S3 ABAC Locally

Seeing ABAC after it's enabled is great, but the key question is:

How will access change if ABAC is enabled for a bucket?

Let's say we have a role arn:aws:iam::111111111111:role/BobInAccounting that has this inline policy attached:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountingBuckets",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetObject"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Dept": "Accounting"
        }
      }
    }
  ]
}

This policy grants access to list and get objects in any bucket that has ABAC enabled and the Dept tag is set to Accounting.

Let's say we have a bucket called arn:aws:s3:::accounts-receivable with the Dept set to Accounting, but ABAC is NOT enabled.

Preview ABAC for a principal with `iam-lens simulate`

You can test this access using the simulate command:

iam-lens simulate --principal arn:aws:iam::111111111111:role/BobInAccounting \
                  --resource arn:aws:s3:::accounts-receivable \
                  --action s3:ListBucket
> Implicitly Denied

This returns implicitly denied because even though the tags match, ABAC is not enabled on the bucket, so BobInAccounting does not have access.

To test what effective access would be if you did enable ABAC add the --s3-abac-override argument.

iam-lens simulate --principal arn:aws:iam::111111111111:role/BobInAccounting \
                  --resource arn:aws:s3:::accounts-receivable \
                  --action s3:ListBucket \
                  --s3-abac-override enabled
> Allowed

Do the same thing with s3:GetObject by using an S3 object ARN:

iam-lens simulate --principal arn:aws:iam::111111111111:role/BobInAccounting \
                  --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
                  --action s3:GetObject
> Implicitly Denied

iam-lens simulate --principal arn:aws:iam::111111111111:role/BobInAccounting \
                  --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
                  --action s3:GetObject \
                  --s3-abac-override enabled
> Allowed

Using this, you can preview how your policies behave before actually updating your sensitive buckets or manually updating data in your iam-collect data store.

Preview ABAC for a bucket with `iam-lens who-can`

who-can lets you flip the question: instead of asking what one role can do, it tells you who can access a given resource.

who-can starts with a resource and determines which principals have access to it.

Let's use the same bucket and see what we find.

who-can --resource arn:aws:s3:::accounts-receivable \
        --actions s3:ListBucket
{
  "simulationCount": 42,
  "allowed": [
    {
      "principal": "arn:aws:iam::111111111111:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_demo",
      "service": "s3",
      "action": "ListBucket",
      "level": "list"
    }
  ],
  "allAccountsChecked": false,
  "accountsNotFound": [],
  "organizationsNotFound": [],
  "organizationalUnitsNotFound": [],
  "principalsNotFound": []
}

Similar to what we found using simulate, since ABAC is not enabled on the bucket BobInAccounting does not have access to list the bucket.

You can override this using the --s3-abac-override argument:

who-can --resource arn:aws:s3:::accounts-receivable \
        --actions s3:ListBucket \
        --s3-abac-override enabled
{
  "simulationCount": 42,
  "allowed": [
    {
      "principal": "arn:aws:iam::111111111111:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_demo",
      "service": "s3",
      "action": "ListBucket",
      "level": "list"
    },
    # 🪣 BobInAccounting is included in the output now because we are simulating ABAC being enabled on the bucket.
    {
      "principal": "arn:aws:iam::111111111111:role/BobInAccounting",
      "service": "s3",
      "action": "ListBucket",
      "level": "list"
    },
  ],
  "allAccountsChecked": false,
  "accountsNotFound": [],
  "organizationsNotFound": [],
  "organizationalUnitsNotFound": [],
  "principalsNotFound": []
}

Do the same thing for S3 object access using an S3 object ARN:

# This will not include BobInAccounting
who-can --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
        --actions s3:GetObject

# This will include BobInAccounting
who-can --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
        --actions s3:GetObject \
        --s3-abac-override enabled

If no --actions are specified, who-can will automatically test all actions for the resource. You can use simple bash tools to preview the effects of enabling ABAC on a bucket and its objects.

# Test all bucket actions without and with ABAC
who-can --resource arn:aws:s3:::accounts-receivable \
        --sort > bucket.json

who-can --resource arn:aws:s3:::accounts-receivable \
        --sort \
        --s3-abac-override enabled > bucket-abac.json

# Test all object actions without and with ABAC
who-can --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
        --sort > object.json

who-can --resource arn:aws:s3:::accounts-receivable/invoice.pdf \
        --sort \
        --s3-abac-override enabled > object-abac.json

# 👀 Compare bucket access with and without ABAC enabled
diff bucket.json bucket-abac.json
10a11,16
>       "principal": "arn:aws:iam::111111111111:role/BobInAccounting",
>       "service": "s3",
>       "action": "ListBucket",
>       "level": "list"
>     },
>     {

# 👀 Compare object access with and without ABAC enabled
diff object.json object-abac.json
10a11,16
>       "principal": "arn:aws:iam::111111111111:role/BobInAccounting",
>       "service": "s3",
>       "action": "GetObject",
>       "level": "read"
>     },
>     {

Build Confidence Before You Flip the Switch

S3 ABAC is a long-awaited and powerful way to manage access to S3 at scale. We hope iam-lens helps you move faster and make the internet a little bit safer for all of us while leveraging it.

If you have any questions or feedback please file an issue or join our Discord.

Fantastic AWS Policies and Where to Find Them

David Kerber — Wed, 24 Sep 2025 11:19:05 +0000

tl;dr

You can't secure what you can't see.

AWS has dozens of policy types scattered across dozens of services, regions, and accounts.
iam-collect is built to find them all.

Answer your questions, secure your accounts, and make your customers safer.

📚 So Many Policies, So Little Time
👤 Who's Doing What Around Here? (Principal Policies)
🔓 Who Left the Door Open? (Resource Policies)
🧟‍♂️ Oh Look, Even More Policies
📦 Fine, Just Download Everything - iam-collect
🔍 Okay, Now What?
- 🛠 Inspect Your Resources
- 🤖 Data and AI, like peanut butter and chocolate
- ✨ Build Your Own Magic
🚀 The End is the Beginning

📚 So Many Policies, So Little Time

One of the best things about AWS IAM is it allows you to do almost anything. One of the challenging things about AWS IAM is it allows you to do almost anything. This flexibility is made possible through several different policy types. If you are in charge of any kind of AWS security or governance, it's critical you understand all of these and their impact.

So what are all these policies and how do we get them?

👤 Who's Doing What Around Here? (Principal Policies)

A principal is any entity that can take actions on AWS resources. It can be a user, a service, a role, or even a GitHub Action. These are in your account as IAM Users and Roles.

On their own, principal policies can only grant access to resources in the same account as the principal.

Managed Policies

These are the managed policies that can be used for multiple users, roles, and groups in your account. Every account comes with AWS Managed Policies that AWS creates and manages. Policies that you create and manage are called Customer Managed Policies.

User and Role Policies

Users and roles in AWS can have managed policies applied to them. They can also have inline policies attached directly to a single IAM user or role.

Group Policies

IAM users can be placed into groups. Groups can have both managed and inline policies, and every policy attached to a group applies to all users in that group.

Permission Boundaries

A permission boundary is a special managed policy that can be applied to a user or role to limit their overall access. Permission boundaries don't grant access, they define the outer limits of what a principal can do, even if other policies would normally allow it.

Service Control Policies

Service Control Policies (SCPs) are an AWS Organizations policy type that applies to principals in your organization. They can be applied to individual AWS accounts or groups of accounts called Organizational Units. SCPs can't grant access, they can only limit access.¹ They are useful to enforce broad security rules across all your principals and can be significantly customized.

🔓 Who Left the Door Open? (Resource Policies)

With principal policies, you start with the principal and manage what resources they have access to. Resource policies are reversed, they start from the resource and manage what principals have access.

Resource policies unlock new capabilities, such as sharing a resource with a principal in another account, or an AWS service. Not every resource type supports resource policies.

Most resource policies apply to a single resource, but like all things AWS, it depends.

Resource policies are required for:

Key Management Service (KMS) keys
IAM Roles - the policies are called "trust policies"

For other resources, resource policies are optional.

IAM Role Trust Policies

Every IAM role has a trust policy that defines who can assume it. This policy controls access for sts:AssumeRole, sts:AssumeRoleWithWebIdentity, and sts:AssumeRoleWithSAML calls. A principal must be allowed in the trust policy to assume the role, no matter what other policies say.²

Key Management Service Key Policies

Every key in Key Management Service (KMS) must have a resource policy defining what principals or accounts have access to that specific key. If access isn't granted through the KMS key policy, it won't happen—not even for the root user. It's possible to completely lock yourself out of a KMS key this way so be careful.

VPC Endpoint Policies

This is a kind of resource policies related to Private Link. When you create a VPC endpoint inside your VPC, a policy is always required. This policy determines what identities can send traffic through the endpoint and what resources they can access. By default all traffic is allowed but this can be customized with a policy document.

S3 Bucket and Access Point Policies

S3 buckets can have their own policies granting fine-grained access to the bucket or even specific prefixes with the bucket.

As bucket policies grew more complex, AWS introduced access points to "simplify" access management. Access points have their own policies. This way consumers can access a bucket through a dedicated access point that has its own detailed access point policy. There are single region and multi-region access points.

S3 also has object lambda access points that can be configured to run a lambda every time an S3 access point is used. Those have their own policies as well.

Different "S3" bucket types have different support for bucket policies and access points:
| Bucket Type | Bucket Policies | Access Points |
|-------------|----------------|---------------|
| General Purpose Buckets | ✅ | ✅ |
| S3 Table Buckets | ✅ | ❌ |
| S3 Vector Buckets | ✅ | ❌ |
| S3 Express Directory Buckets | ✅ | ✅ |
| S3 Outpost Buckets | ✅ | ✅ |

S3 Buckets also have per bucket and per account settings for Block Public Access.

Organizations Resource Policy

Typically AWS Organizations APIs can only be used from the management account of an organization. AWS has created this unfortunately named policy that allows you to delegate organizations API access to principals in other accounts.

Organizations Delegated Administrators

Many actions that are only allowed in the organization management account by default can be delegated to delegated administrator accounts, it's critical to know which accounts these are and what services they can manage.

Simple Email Service (SES) Sending and Identity Authorization Policies

In SES you can create resource policies for specific email identities (domains or email addresses) that allow other AWS accounts to send email from those identities. This is useful for organizations with a centralized identity management account that handles email domains.

You can also create a sending authorization policy that applies to your entire account. This is useful if you want to allow another account to send email on your behalf without having to create a resource policy for each identity.

Other Resource Policies

Tons of other resources support resource policies such as:

API Gateway REST APIs
Backup Vaults
DynamoDB Tables and Streams
ECR Registries - the registry for the entire region and account.
ECR Repositories - every individual repository
EFS File Systems
Glacier Vaults
Lambda Functions and Layer Version - Every layer version can have its own policy 😳
SNS Topics
SQS Queues
Secrets Manager Secrets
SSM Incident Manager Contacts and Response Plans
Serverless Application Repositories
Rekognition Projects
Migration Hub Refactor Spaces
Lex Bots
Elemental Media Stores
CodeBuild Report Groups and Artifact Repositories
Signer Profiles
Kinesis Data Streams
Event Bridge Schema Registries and Buses
CloudWatch Delivery Destinations
CloudTrail Dashboards, Channels, and Event Data Stores
Redshift Serverless Namespaces
Redshift Namespaces
OpenSearch Domains
Managed Streaming for Kafka Clusters

Resource-ish Policies

Some custom policies in AWS don't apply directly to a single resource or account but are somewhere in between.

AWS Entity Resolution allows custom policies for sharing multiple kinds of resources.
AWS IoT allows a centralized policy for managing access to different IoT Resources
CloudWatch Account Policies are managed at the account level for delegating access to CloudWatch Log Groups.
AWS Glue has a per-region policy that can be used to manage access to any Glue resource in that region.

AWS Resource Access Manager

As you can see, lots of AWS resources allow you to attach policies to resources. Resource Access Manager (RAM) enables sharing resources when the service doesn't directly support resource policies.

You can think of RAM as "resource policies as a service". It allows you to share resources outside their account even if the service doesn't support resource policies. It has to be enabled by your AWS organization first. It supports 70+ resource types notably subnets, security groups, and firewalls.

Resource Control Polices

Finally there are resource control policies (RCPs), an AWS Organizations feature that allows you define policies that apply to all resources in an account or organization unit.

Remember: SCPs apply to principals in your organization, while RCPs apply to the resources themselves. Together, they help close the loop on what's allowed—and by whom.

🧟‍♂️ Oh Look, Even More Policies

IAM Identity Center Permission Sets

IAM Identity Center is used as a single sign on solution for accessing multiple roles in multiple AWS accounts from a single place. It provides user management or you can connect your own identity provider, such as Okta or Entra ID.

Within Identity Center you can create permission sets that define a set of policies (AWS managed, customer managed, inline, or a permission boundary) that can then be assigned to multiple user/account pairs. To know what permissions a user in Identity Center has, you need to have all of the permissions sets that apply to that user.

📦 Fine, Just Download Everything - iam-collect

That’s a lot of policies. And a lot of places for risk to hide.

iam-collect downloads IAM policies, organization policies, resource policies, RAM shares, and SSO permission sets, across every account, in one place.

Here is the quickest way to get started:

# Install
npm install -g @cloud-copilot/iam-collect
# Make a configuration file
iam-collect init
# Download data for the current account
iam-collect download
# Look at your data
ls -R ./iam-data

Now you have a full snapshot of IAM reality instead of assumptions or best guesses based on staring at Terraform.

💬 Real-world feedback:

iam-collect (and the accompanying iam-lens) were simple to stand up quickly and let us get straight to the interesting part: analyzing our tangled web of IAM policies. David has been incredibly receptive to feedback and quick to add new features as we've needed them. We're excited to use these tools even more in the future.

Jeremy Talis, Security Lead @ Pinterest

By default, it uses the credentials in your environment and saves data to the iam-data folder. It requires a minimum set of permissions to operate.

A single folder can hold data for an unlimited number of AWS accounts and organizations across multiple partitions.

Customizing Data and Auth

iam-collect is built to be ridiculously configurable. You can:

Select which accounts, services, and regions data will be collected from
Assume a role in each account to collect data
Assume an initial role before assuming roles in other accounts
Have separate auth for each account

Storage Options

iam-collect can store data in:

A folder on your local disk
An S3 bucket with any prefix

🔍 Okay, Now What?

The primary purpose of iam-collect is to power iam-lens. We'll talk more about that in a future post and there is a lot you can do with it in the mean time.

Whether you're:

a security lead trying to reduce audit time,
a platform engineer building IAM tooling,
or a consultant trying to answer “who can do what”

iam-collect gives you a clean, reliable starting point.

🛠 Inspect Your Resources

Using a bit of cli and utilities like jq you can quickly get information. Want to find all customer managed policies in your SSO permission sets? Try this:

ls collect/aws/aws/accounts/*/sso/permissionset/*/customermanagedpolicies.json   | xargs -n1 jq -r '.[].arn' | uniq | sort

🤖 Data and AI, like peanut butter and chocolate

There are an infinite number of questions you might want answered with your IAM data. So iam-collect has a set of detailed agent instructions to use with your downloaded data.

Simply download the agent instructions:

curl -O https://raw.githubusercontent.com/cloud-copilot/iam-collect/main/docs/AgentInstructions.md

Then use these instructions to answer questions:

What trust polices allow a Principal "*" to assume the role?
What RAM shares are sharing resources outside of my organization?
What managed policies that are in use use a wildcard "*" action?
What AWS managed policies are in use?
Are there any users in my root account without permission boundaries?
What principals have a policy with the action "iam:PassRole" with a "*" resource?

These questions are about what the policies contain—not necessarily their full effect, which is harder for models to reason about. That's where iam-lens comes in later.

✨ Build Your Own Magic

Every year, new tools emerge to help analyze IAM policies, SCPs, and other access controls. They all start with the same first step: downloading policies from from AWS.

“First download all the policies” is often an annoying large part of the work; especially if you want to do it across multiple accounts and organizations.

I hope that by having a tool that just downloads the policies - which people may already have done - you can start with the most valuable step: bringing your industry expertise to AWS policies.

🚀 The End is the Beginning

No more guessing, clicking through the console, or trying to remember if that wildcard was "just for testing."

Start with the truth. Then secure it.

See the documentation to get started.

Footnotes

The way SCPs can limit access may include not having an Allow statement. See the full SCP documentation for details. ↩
You can use arn:aws:iam::ACCOUNT_ID:root to allow any principal in an account to assume a role. The principal still needs access to the sts:AssumeRole action in their own policies. ↩

DEV Community: David Kerber

Test S3 ABAC locally with iam-lens

tl;dr

Table of Contents

New S3 Attribute Based Access Control Functionality

S3 ABAC Support in iam-collect and iam-lens

Previewing S3 ABAC Locally

Preview ABAC for a principal with iam-lens simulate

Preview ABAC for a bucket with iam-lens who-can

Build Confidence Before You Flip the Switch

Fantastic AWS Policies and Where to Find Them

tl;dr

Table of Contents

📚 So Many Policies, So Little Time

👤 Who's Doing What Around Here? (Principal Policies)

Managed Policies

User and Role Policies

Group Policies

Permission Boundaries

Service Control Policies

🔓 Who Left the Door Open? (Resource Policies)

IAM Role Trust Policies

Key Management Service Key Policies

VPC Endpoint Policies

S3 Bucket and Access Point Policies

Organizations Resource Policy

Organizations Delegated Administrators

Simple Email Service (SES) Sending and Identity Authorization Policies

Other Resource Policies

Resource-ish Policies

AWS Resource Access Manager

Resource Control Polices

🧟‍♂️ Oh Look, Even More Policies

IAM Identity Center Permission Sets

📦 Fine, Just Download Everything - iam-collect

Customizing Data and Auth

Storage Options

🔍 Okay, Now What?

🛠 Inspect Your Resources

🤖 Data and AI, like peanut butter and chocolate

✨ Build Your Own Magic

🚀 The End is the Beginning

Footnotes

S3 ABAC Support in `iam-collect` and `iam-lens`

Preview ABAC for a principal with `iam-lens simulate`

Preview ABAC for a bucket with `iam-lens who-can`