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.

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.