security-review/iam/CROSS-REVIEW-PACKET.md

# Cross-review packet — R720 aws-posture IAM (step-ca → Roles Anywhere → read-only AWS role)

> **GPT-4.1 cross-review 2026-06-18: APPROVE, no BLOCKs; FIXes applied**
> (`aws:SourceAccount` added to the trust policy; `ec2:DescribeImages` removed from the
> permission policy). NIT answers recorded in `aws-posture-readonly-policy.rationale.md`:
> snapshots = account-owned idle-spend signal (kept); `s3:ListAllMyBuckets` = names-only
> inventory, no object data (kept); no `logs:*` needed; `aws:RequestedRegion` deliberately
> SKIPPED (global-endpoint `ce:*`/`s3:ListAllMyBuckets` could be DENYed by a blanket region pin).

**Audience:** the mandatory GPT-4.1 IAM cross-review + Adam.
**Status:** these are AUTHORED FILES, nothing is applied to AWS. The review has now PASSED
(APPROVE, no BLOCKs), which unblocks **building** aws-posture (done in this Phase-3 change set,
PROVISIONING-GATED — the checker makes no AWS call until step-ca + Roles Anywhere are stood up).
Approving this packet unblocks provisioning; it does not itself change AWS.

**Account:** 328440206208 · **Region:** us-east-1 · **Box:** the always-on R720 secrev VM
(single-user, unattended, currently holds a long-lived read-only GitHub PAT).

## Why this exists

aws-posture (design D5 / §4) is a weekly idle/anomalous-spend watch (the design flags ≈$330/mo
of waste). It must read Cost Explorer + utilization metrics + an idle-resource inventory from
the account. The decision (D5): **the box stays read-only, and it authenticates to AWS via IAM
Roles Anywhere using short-lived leaf certs issued by a new internal step-ca — NO long-lived
AWS access key on the box.** The short-lived self-expiring leaf is strictly stronger than the
box's existing long-lived PAT.

## Files in this packet

| File | What it is |
|---|---|
| `aws-posture-readonly-policy.json` | The least-privilege **permission policy** (valid IAM JSON, applyable as-is). |
| `aws-posture-readonly-policy.rationale.md` | Statement-by-statement least-privilege rationale (IAM JSON can't hold comments). |
| `aws-posture-trust-policy.json` | The role's **trust policy** — who may assume it (Roles Anywhere + pinned cert CN/issuer + pinned trust-anchor ARN). |
| `roles-anywhere-config.json` | The Roles Anywhere **trust anchor + profile** config (pins the step-ca root; 1h session cap). |
| `step-ca-config-sketch.md` | The internal **CA** config + the systemd-timer **auto-renewal** approach. |
| `CROSS-REVIEW-PACKET.md` | This document. |

## Trust model, end to end

```
step-ca ROOT cert (CN="Sea Haven Internal CA - R720 Roles Anywhere")
  │  pinned as the Roles Anywhere trust anchor (roles-anywhere-config.json)
  ▼
step-ca issues a SHORT-LIVED leaf  (CN="r720-aws-posture", ~24h, auto-renewed hourly by systemd timer)
  │  stored mode-600 on the box; private key never leaves the box; no AWS key on disk
  ▼
box calls AWS via aws_signing_helper credential-process, signing with the leaf
  ▼
IAM Roles Anywhere trust anchor  (r720-aws-posture-step-ca)
  │  validates: leaf chains to the pinned root? yes -> emit session tags
  │             aws:PrincipalTag/x509Subject/CN = "r720-aws-posture"
  │             aws:PrincipalTag/x509Issuer/CN  = "Sea Haven Internal CA - R720 Roles Anywhere"
  ▼
Roles Anywhere profile  (r720-aws-posture-readonly, durationSeconds=3600)
  │  binds ONLY the one role
  ▼
sts:AssumeRole on  role/r720-aws-posture-readonly
  │  trust policy (aws-posture-trust-policy.json) requires ALL of:
  │    (1) Principal = rolesanywhere.amazonaws.com   (came via Roles Anywhere)
  │    (2) aws:SourceArn = THIS trust anchor          (not some other anchor)
  │    (2b) aws:SourceAccount = 328440206208          (confused-deputy guard, added in cross-review)
  │    (3) x509Subject/CN = "r720-aws-posture" AND x509Issuer/CN = the internal CA
  ▼
1-hour STS session, permissions = aws-posture-readonly-policy.json (read-only cost + idle inventory)
  ▼
read-only AWS APIs: ce:Get*, cloudwatch:GetMetric*/DescribeAlarms, ec2/elb/rds:Describe*,
                    lambda:List/GetFunctionConfiguration, s3:ListAllMyBuckets/GetBucketLocation
```

Three independent conditions must ALL hold to assume the role: via Roles Anywhere, from THIS
anchor (in THIS account, via the `aws:SourceAccount` guard added in cross-review), presenting a
leaf with the pinned subject CN + issuer CN. Any one missing → AssumeRole denied.

## Least-privilege rationale (summary; full table in the rationale .md)

- **Read-only only.** No write/modify/delete verb in any service. No `iam:*` mutation, no
  privilege-escalation path, no `sts` onward-chaining.
- **`Resource: "*"` only where AWS gives no choice.** Cost Explorer, the CloudWatch metric-data
  calls, and the EC2/ELB/RDS `Describe*` list operations do not support resource-level ARNs;
  least-privilege there is the **action allow-list**, not the resource. There are no wildcard
  *actions* (`ce:*`, `ec2:*`) anywhere — every action is an explicit read verb.
- **No data-plane reads.** Deliberately excludes `s3:GetObject`, `secretsmanager:GetSecretValue`,
  `ssm:GetParameter*`, `kms:Decrypt`, `logs:GetLogEvents`. The role enumerates and prices the
  account; it cannot read application data, secrets, or logs.
- **Tighter than the AWS-managed `ReadOnlyAccess`/`ViewOnlyAccess`** (those include object reads,
  table reads, etc.) — this is the small cost+inventory subset aws-posture actually queries.

## Blast radius if the leaf (or its private key) is compromised

- **Ceiling = read-only enumeration + pricing of account 328440206208 for ≤1 hour per session**
  (STS `durationSeconds=3600`), and only while a valid unexpired leaf exists (~24h leaf life).
- **Cannot:** read S3 object data, read secrets/SSM params, read CloudWatch *logs*, modify or
  delete any resource, touch IAM, assume any other role, or act in any other account/region
  scope beyond what read-only describe calls expose.
- **Containment levers, fastest first:**
  1. **Disable the Roles Anywhere profile or trust anchor** (`enabled:false`) → immediately stops
     all new credential vending, regardless of leaf validity. (seconds)
  2. **Detach/empty the role's permission policy** → any still-live session loses all access at
     the next AWS authz check. (seconds)
  3. **Revoke at the CA / rotate the leaf** → step-ca stops renewing; the leaf self-expires within
     its ≤24h window even with no action.
- The self-expiring leaf means even a "do nothing" outcome bounds exposure to the leaf lifetime —
  unlike the box's current long-lived PAT, which would persist until manually rotated.

## Rollback (EXERCISED, not just written — design §7 "exercised, not merely written")

Teardown order is the reverse of provisioning; each step is independently sufficient to cut
access. Tested via a simulated teardown/re-provision against throwaway names (see "Exercise"
below) before this packet is accepted.

```bash
ACC=328440206208 ; REG=us-east-1
TA_ID=REPLACE_TRUST_ANCHOR_ID ; PROF_ID=REPLACE_PROFILE_ID
ROLE=r720-aws-posture-readonly ; POLICY=r720-aws-posture-readonly

# 1) Stop credential vending FIRST (fastest cut): disable then delete the profile + trust anchor.
aws rolesanywhere disable-profile      --profile-id "$PROF_ID" --region "$REG"
aws rolesanywhere disable-trust-anchor --trust-anchor-id "$TA_ID" --region "$REG"
aws rolesanywhere delete-profile       --profile-id "$PROF_ID" --region "$REG"
aws rolesanywhere delete-trust-anchor  --trust-anchor-id "$TA_ID" --region "$REG"

# 2) Remove the role + its permission policy.
POLICY_ARN="arn:aws:iam::$ACC:policy/$POLICY"
aws iam detach-role-policy --role-name "$ROLE" --policy-arn "$POLICY_ARN"
aws iam delete-role        --role-name "$ROLE"
aws iam delete-policy      --policy-arn "$POLICY_ARN"

# 3) Remove the internal CA + the leaf on the box (no AWS state involved).
sudo systemctl disable --now aws-posture-cert-renew.timer step-ca.service
sudo rm -f /etc/aws-posture/leaf.crt /etc/aws-posture/leaf.key
sudo rm -rf /etc/step-ca           # destroys root/intermediate/keys -> no further leaves issuable
# (optional) remove the [profile r720-aws-posture] block from ~/.aws/config
```

**Re-provision** = re-run `step ca init` (step-ca-config-sketch.md) → re-create role + policy +
trust anchor + profile → drop in the new trust-anchor/profile ARNs. A revert point (VM snapshot
per `feedback_ec2_replacement_snapshot`) is taken before provisioning so the whole change is one
snapshot-restore away from gone.

### Exercise log (to be completed before acceptance)

> Run the provision → assume-once (confirm read-only works, confirm a write is denied) → run the
> rollback above against throwaway-suffixed names → confirm AssumeRole now fails and the CA is
> gone. Paste the transcript here. Until this is filled in, the rollback is "written, not
> exercised" and the phase is NOT accepted (design §7).

## Specific things for the cross-reviewer to scrutinize (with resolutions)

1. **Trust-policy condition completeness.** Are `aws:PrincipalTag/x509Subject/CN` +
   `aws:PrincipalTag/x509Issuer/CN` + `ArnEquals aws:SourceArn` (the trust anchor) sufficient
   to prevent any other cert (or another trust anchor in the account) from assuming the role?
   Is there a confused-deputy gap I should also pin (e.g. should I add `aws:SourceAccount`)?
   → **RESOLVED (FIX applied):** added `aws:SourceAccount = 328440206208` to the StringEquals
   condition. The trust now pins anchor (SourceArn) **and** account (SourceAccount) plus the
   cert CN/issuer — closing the confused-deputy gap the reviewer raised.
2. **`Resource: "*"` statements.** Confirm each is an API that genuinely has no resource-level
   support, and that no statement could be tightened with a condition (e.g. `aws:RequestedRegion`
   = us-east-1) without breaking the checker.
   → **RESOLVED (NIT, SKIPPED with rationale):** every `Resource:"*"` statement is an
   API family without resource-level ARNs (ce, the cloudwatch metric-data calls, ec2/elb/rds
   `Describe*`). `aws:RequestedRegion` is **NOT** applied — `ce:*` and `s3:ListAllMyBuckets` are
   global-endpoint services that a blanket region condition could DENY. Full reasoning in
   `aws-posture-readonly-policy.rationale.md` ("Cross-review NIT answers").
3. **Action allow-list.** Anything in here that is NOT needed for idle/anomalous-spend (i.e.
   over-grant), or any read verb that leaks data we don't want (the intent is pricing + inventory,
   no object/secret/log data).
   → **RESOLVED (FIX applied):** removed `ec2:DescribeImages` (AMIs are not an idle-spend signal).
   `ec2:DescribeSnapshots` kept (orphan-snapshot waste, account-owned metadata only);
   `s3:ListAllMyBuckets` kept (bucket *names* only, no `s3:GetObject`); no `logs:*` granted.
4. **Session duration vs leaf lifetime.** 1h STS session + ~24h leaf — acceptable blast window?
   → Accepted as-is (no change requested).
5. **Rollback ordering.** Is disabling the profile/anchor first the correct fastest-cut order,
   and does step 2/3 leave any orphaned grant?
   → Accepted as-is (no change requested).

## Process note

Per global instructions this IAM change ALSO requires the GPT-4.1 cross-family review run via
`python3 ~/Documents/repositories/seahaven/security-review/cross_review.py "<task>"` (it is an IAM
role/policy + trust-anchor change). This packet is the input to that review; aws-posture is not
built until the review is recorded.