Trust Issues: What Do All these JSON files actually mean?

Trust Issues: What Do All These JSON Files Actually Mean?

Speakers: David Kerber

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=j0YTgEKciCg

Overview

David Kerber, an AWS consultant and self-described IAM obsessive, presented a suite of open-source tools he built to solve what he calls the fundamental problem of cloud security: AWS IAM is the most important security control and effectively nobody understands it. The three tools -- IAM Simulate (a from-scratch policy evaluation engine), IAM Collect (a policy downloader that captures every policy across an entire AWS organization), and IAM Lens (a CLI that combines them for real-time policy analysis) -- enable instant, offline evaluation of IAM request outcomes with detailed explanations of how every policy statement was evaluated. The live demo showed capabilities ranging from debugging why an SCP denied a request to mapping which principals across an entire organization can assume a given role, complete with the specific conditions under which access would be granted.

Background

▶ Watch: IAM is the most important part of cloud security and nobody understands it (1:30)

AWS IAM has evolved over more than a decade to handle an expanding set of security scenarios, introducing SCPs, RCPs, permission boundaries, resource policies, session policies, and an ever-growing matrix of condition keys. The result is a system that is extraordinarily powerful but nearly impossible to reason about manually. As Kerber noted, the global population of people who truly understand IAM could fit in a very small room, and approximately 30% of them are named Dan. AWS provides an IAM Policy Simulator, but it is limited in scope, speed, and the detail of feedback it provides. The IAM documentation serves as a "field guide to map navigation" -- useful for learning how to read maps, but not helpful when you need to know how to get from point A to point B right now.

The problem has two dimensions: the micro lens (can you understand what a single IAM policy does and how different requests would be evaluated against it?) and the macro lens (across hundreds of policies and thousands of accounts, how do all these policies interact?). Existing tools address neither dimension with sufficient depth and speed for practitioners who need to iterate on policy development or investigate security posture at enterprise scale.

Key Findings

▶ Watch: IAM Simulate: from-scratch policy engine with 200+ test cases (5:30)

IAM Simulate is a ground-up reimplementation of the AWS IAM policy evaluation engine. It understands all policy types (identity policies, resource policies, SCPs, RCPs, permission boundaries), all condition operators, cross-account evaluation differences (same account vs. cross-account in the same org vs. different orgs), and service-specific quirks (STS and KMS evaluate resource policies differently from other services). For every request, it returns three things: a decision (allowed, implicitly denied, or explicitly denied), a detailed explanation (line-by-line analysis of how every statement in every policy was evaluated), and conditions under which the request might be allowed (e.g., "this would be allowed if the source VPC matched this value"). The engine also performs policy validation -- if you accidentally use NotResource in an SCP (which is not allowed), it will catch the error before running the simulation. The tool has 200+ end-to-end JSON test cases covering every scenario the team could identify.

IAM Collect downloads every piece of information needed to determine the outcome of any IAM request across an entire AWS organization: all principals, metadata, managed policies, inline policies, groups, org structure, SCPs, RCPs, resource policies (with a long tail of resource types being actively expanded), and Resource Access Manager shares. All data is stored in a conflict-free format that supports multiple organizations and even multiple partitions (commercial + GovCloud).

IAM Lens combines the two as a CLI with three primary commands:

• simulate: Evaluate whether a specific principal can perform a specific action on a specific resource, with optional verbose output showing the full evaluation chain. Supports expectation assertions (--expect allowed) with return codes suitable for automated testing.
• who-can: Given a resource and one or more actions, enumerate every principal across the entire organization that can perform those actions, including the conditions under which access is granted.
• principal-can: Given a principal, consolidate all allow statements, intersect with boundaries (permission boundaries, SCPs, RCPs), subtract deny statements, and produce a consolidated effective policy. (Currently alpha -- does not yet account for resource policies.)

Technical Deep Dive

▶ Watch: IAM Lens CLI: simulate, who-can, and principal-can commands (10:00)

The live demo showcased several powerful use cases:

SCP debugging. Kerber simulated creating an access key for a user and found it explicitly denied. Verbose mode revealed the denial came from a specific SCP (identified by ARN) at a specific OU. He then modified the SCP locally to add an exception condition, and the simulation immediately reflected the changed outcome. He also demonstrated the policy validation catching an attempt to use NotResource in an SCP.

Privilege path analysis. Starting from a role called "mega-danger-role" with AdministratorAccess and a trust policy allowing any principal in the org, who-can identified that both the production break-glass role and a product-development role could assume it -- the latter being an unintended trust path. Following the chain further, who-can on the product-development role revealed an IAM user named "jacob-is-cool-with-a-k" with assumption capability.

Resource access enumeration. For an S3 bucket called "area-52," who-can enumerated all principals with access, including those restricted by conditions (e.g., prod-break-glass only has access when the source VPC matches a specific value). Unrecognized accounts and principals were flagged separately, enabling quick identification of external access.

Real-time policy iteration. The web-based IAM Simulate interface re-evaluates all test scenarios on every keystroke as you edit a policy, providing instant feedback on how changes affect request outcomes. Policies and test scenarios can be shared via links for collaborative debugging.

Demo / Proof of Concept

▶ Watch: Live demo: SCP debugging with verbose evaluation chain and policy validation (13:00)

The entire second half of the talk was a live CLI demo. Kerber demonstrated SCP debugging with verbose output, privilege path tracing across an org, resource access enumeration with condition analysis, policy validation catching illegal constructs, and real-time policy editing with instant feedback.

Defensive Implications

▶ Watch: S3 bucket access enumeration with conditional access and external principal f... (17:00)

These tools address a critical gap in AWS security posture management. Organizations should integrate IAM Lens into their policy development workflow, using the simulate command with expectations as automated regression tests for policy changes. The who-can command should be run regularly against sensitive resources (S3 buckets, KMS keys, privileged roles) to identify unintended access paths. The ability to run all analysis entirely offline (after the initial policy download) means these tools can be used in environments with strict data handling requirements.

The principal-can command (once it incorporates resource policies) will enable consolidated effective policy views that are essential for access reviews and audit responses. Even in its current alpha state, it provides a clearer picture of what a principal can do than any native AWS tooling.

Key Takeaways

• IAM is the most critical AWS security control and too complex to reason about manually; dedicated simulation tooling is essential
• IAM Simulate evaluates requests against all policy types with detailed line-by-line explanations and 200+ regression tests
• IAM Collect downloads every policy and setting across an entire AWS organization for offline analysis
• IAM Lens CLI enables simulate (with expectation assertions for CI/CD), who-can (enumerate all access to a resource), and principal-can (consolidated effective policy)
• The tools run entirely offline after initial policy download, support multiple orgs and partitions, and perform policy validation before simulation
• Privilege path analysis from a role backwards through trust chains reveals unintended access paths that are invisible without automated tooling

About the Speaker(s)

David Kerber is an AWS consultant who describes himself as oddly obsessed with IAM. He built an entire website dedicated to IAM understanding and created the IAM Simulate, IAM Collect, and IAM Lens open-source tools. He is also a bread baker who distributes loaves to audience members who ask questions.