s3-estate-calibration-auditor skill

s3-estate-calibration-auditor

Effective-exposure audit skill for an estate of AWS S3 buckets. Takes the config layers for every bucket in the estate (public-access-block.json, bucket-policy.json, bucket-acl.json, and access-points.json where present), resolves each bucket's effective verdict by composing all four layers, then answers one question a per-layer read cannot: across 8-12 buckets that mostly READ as exposed, which one is genuinely live, and is the estate otherwise clean. It returns the live bucket as the headline, ranked by severity, with a fix, then names exactly where the bucket configs stop being able to answer the question.

Effective S3 exposure is a join across four layers that each get read wrong one at a time. A public-looking bucket policy is inert under RestrictPublicBuckets; a cross-account grant survives BPA-all-on; a public-group ACL is dead under IgnorePublicAcls but a cross-account canonical user beside it is not; a clean bucket can still be public through an access point. In an estate, the trap doubles: several buckets carry a Principal '*' policy, an AllUsers ACL, or a wide-open look that is genuinely neutralised, and exactly one bucket carries a real live grant that reads just like its neutralised siblings. This skill composes the layers per bucket instead of clearing each layer in isolation, then calibrates the estate: it does not over-flag the neutralised baits, and it does not miss the buried needle.

When to invoke

access, or "is anything in this account public."

• An agent is asked to review an S3 bucket fleet for public exposure, cross-account

effectively exposed, not just whether a Principal '*' or an AllUsers grant appears somewhere in the configs.

• An estate is being shipped or changed and the question is whether any bucket is

"but BPA is on / it is scoped" needs to be confirmed against the effective verdict rather than taken on trust.

• An estate looks exposed (several Principal '*' policies, AllUsers ACLs) and the claim

closed" needs to be checked against the cross-account grants BPA does not touch.

• An estate looks locked down (BPA all on everywhere) and the claim "the account is

What this skill reads, and what it does not

It reads the static configuration of an estate of buckets: per bucket, any subset of the Block Public Access booleans, the bucket policy, the bucket ACL, and the access points. Those are S3 control-plane reads (get-public-access-block, get-bucket-policy, get-bucket-acl, list-access-points + get-access-point-policy). That is the entire input. The audit is correct and complete for what the bucket configs can tell you, and it is explicit about the rest. Reachability-on-paper is not exposure-in-fact, and every audit ends by naming the joins it cannot make:

public-read grant even when the bucket is private. Join: bucket config to its per-object ACLs.

• It does not see per-object ACLs. An individual object can carry its own

is served publicly through a CloudFront distribution with Origin Access Control. Join: bucket to its CDN distribution.

• It does not see CloudFront / CDN fronting. A bucket can be private while its data

conditional grant only matters in proportion to what the trusted account/role can do and whether it re-shares onward, which lives in that account. Join: this bucket to the identity policies of the principals it trusts.

• It does not contain the privileges of a trusted principal. A cross-account or

access this config Allows. Join: bucket to its VPC-endpoint policies and the org SCPs.

• It does not see VPC-endpoint policies or org SCPs, which can further restrict

which is not in the config.

• A flagged grant's exploitability depends on the data sensitivity of the objects,

A clean (deceptive-clean) estate still gets a boundary section, because a BPA-neutralised estate is not a proven-safe system: turning BPA off would expose the latent statements.

The model

For every bucket in the estate, build the effective verdict by composing four layers. Never read one layer alone. A finding is LIVE only when a real public or cross-account grant survives the layer that would neutralise it:

policy and ACL grants, but do NOT touch cross-account grants.

1. Block Public Access (BPA) -- four booleans that neutralise otherwise-public

other account, or '*' narrowed by a Condition.

1. The bucket policy -- a resource policy whose Principal can be public ('*'), a named

AuthenticatedUsers public groups.

1. The bucket ACL -- legacy grants to canonical users, or to the AllUsers /

independent of (but not exceeding) the bucket.

1. Access points -- each with its OWN BPA and policy, able to expose data

The estate is clean iff no bucket is live. The needle is whichever bucket carries a live finding among many neutralised/scoped lookalikes.

The methodology, in order

1. Parse all four layers for every bucket

Before any judgment, read each layer for each bucket. Process EVERY bucket in the estate, not the first couple:

all four are False (no BPA). The two that neutralise existing grants are RestrictPublicBuckets / BlockPublicPolicy (for a public policy) and IgnorePublicAcls (for a public-group ACL). BlockPublicAcls only blocks new public ACLs and does not disable an existing one.

• BPA: read the four booleans from public-access-block.json. An absent file means

cannot make a bucket public; classify only the Allow statements. For each Allow, read the Principal (public '', a named AWS account, or '' with a Condition) and the Condition.

• Policy: read each Statement in bucket-policy.json. A Deny grants nothing and

AuthenticatedUsers Group URI is a public-group grant; a CanonicalUser that is not the bucket owner is a cross-account grant; an owner-only ACL produces nothing.

• ACL: read each grant in bucket-acl.json. A Grantee that is the AllUsers or

PublicAccessBlock and Policy; resolve the AP policy exactly like a bucket policy, against the AP's own BPA.

• Access points: read each entry in access-points.json. Each AP has its OWN

Recognise the BPA switches by name, and recognise a narrowing Condition: aws:PrincipalOrgID, aws:PrincipalOrgPaths, aws:PrincipalAccount, aws:PrincipalArn, aws:SourceArn, aws:SourceAccount, aws:SourceVpc, aws:SourceVpce, aws:SourceIp, aws:VpcSourceIp, sts:ExternalId, and the access-point delegation keys s3:DataAccessPointAccount / s3:DataAccessPointArn / s3:AccessPointNetworkOrigin. Any of these on a Principal '*' scopes it to a bounded caller set.

Read each bucket's BPA booleans verbatim — do not let a bucket's name or its grants tell you what they are. Each boolean being true is the safe direction: IgnorePublicAcls: true means an existing public ACL is ignored (dead); RestrictPublicBuckets: true means a public policy is denied. Do not invert it. The dominant miscalibration is asserting a boolean value to fit an expectation: a bucket named exports, public, share, partner, or cdn, or any bucket carrying an AllUsers / AuthenticatedUsers grant, invites the assumption that it must be the exposed one — and that assumption makes you misread its IgnorePublicAcls as false. In these estates the common case is the opposite: a shareable-sounding bucket with an AllUsers grant and IgnorePublicAcls: true, which is neutralised, not live. The presence of a grant is not evidence about the boolean. To keep the transcription faithful: for any bucket carrying an AllUsers / AuthenticatedUsers ACL grant or a Principal '' policy, paste that bucket's entire public-access-block.json as a verbatim JSON block** before you classify it, and read the four booleans out of the pasted block. Pasting the raw object is harder to get wrong than filling a value in from memory, which is where the misread creeps in.

2. Resolve each bucket's effective verdict (the composition)

Compose the layers; do not condemn a bucket on "Principal '*' is present" alone, and do not clear it on "BPA is on" alone. The codes:

narrowing Condition, and BPA is NOT restricting (RestrictPublicBuckets and BlockPublicPolicy both off). Live public exposure: anyone on the internet can perform the granted actions.

• POLICY-PUBLIC (critical, LIVE) -- the bucket policy allows Principal '*' with NO

no Condition and the AP's own BPA is not restricting. Data is reachable publicly through the access point even when the bucket policy and bucket BPA are clean. Auditing only the bucket misses this.

• AP-PUBLIC (critical, LIVE) -- an access point's own policy allows Principal '*' with

NOT public, so BPA does not govern it: a cross-account grant stays fully live even with all four BPA switches on. The classic misread is seeing BPA-all-on and calling the bucket locked down.

• XACCT-POLICY (high, LIVE) -- the bucket policy grants a named other account. This is

bucket owner. IgnorePublicAcls neutralises the public GROUPS, not a named canonical user, so this grant survives BPA-all-on. A TLS-only Deny in the policy does not address it.

• XACCT-ACL (high, LIVE) -- the bucket ACL grants a canonical user that is not the

group and IgnorePublicAcls is OFF. Live public via ACL, independent of the bucket policy.