orchestrator/security-review/iam/aws-posture-readonly-policy.rationale.md

aws-posture-readonly-policy.json — least-privilege rationale

This is the annotated companion to aws-posture-readonly-policy.json. The policy JSON itself is kept strictly valid (no inline Comment keys — IAM rejects those), so all rationale lives here. This policy is the permission set for the aws-posture checker (design D5 / §4): idle / anomalous-spend watch on the Sea Haven AWS account (328440206208, us-east-1).

Cross-review status (2026-06-18): GPT-4.1 IAM cross-review returned APPROVE, no BLOCKs. FIXes applied to the policy as a result:

• Removed ec2:DescribeImages (data minimization — AMIs are not part of the idle-spend signal; orphan EBS snapshots already cover the storage-waste case via ec2:DescribeSnapshots).
• The trust policy (aws-posture-trust-policy.json) gained aws:SourceAccount = 328440206208 as an extra confused-deputy guard alongside the existing aws:SourceArn trust-anchor pin (see that file).

aws-posture itself is built in Phase-3 (this change set) but stays PROVISIONING-GATED — the checker never calls AWS until step-ca + Roles Anywhere (this packet) are stood up. This file + the policy are the IAM cross-review inputs (design §7, B3).

Design principle

The box stays read-only. There is no write action, no iam:* mutating action, no Resource wildcard where AWS supports resource-level scoping. Idle-spend posture is an account-wide, list-oriented read: most of the actions below are AWS APIs that do not support resource-level ARNs at all (Cost Explorer, the CloudWatch metric-data calls, and the EC2/ELB/ RDS Describe* list operations). For those, least-privilege is enforced by the action allow-list (only the specific read verbs), not by narrowing Resource.

Statement-by-statement

Sid	Why aws-posture needs it	Why read-only / why Resource: "*"
CostAndUsageReadOnly	The core idle/anomalous-spend signal (the design flags ≈$330/mo). GetCostAndUsage, forecasts, dimensions, and the native CE anomaly detectors.	Cost Explorer is an account-scoped service; its API has no resource-level ARNs, so Resource:* is the only valid form. Only Get* verbs — no ce:Update*/Create*/Delete*, no budget mutation.
CloudWatchMetricsReadOnly	Correlate spend with utilization (an instance billing but at ~0% CPU is idle). GetMetricData/GetMetricStatistics/ListMetrics; DescribeAlarms* to see whether an idle resource is already alarmed.	These metric-read APIs do not support resource-level permissions. No PutMetricData, no alarm create/modify/delete.
Ec2DescribeReadOnly	The classic idle-spend inventory: stopped instances still paying for EBS, unattached volumes, unassociated Elastic IPs, idle NAT gateways, orphan snapshots. (ec2:DescribeImages was removed in cross-review — AMIs are not an idle-spend signal aws-posture acts on.)	Describe* is read-only; these list calls don't take resource ARNs. No Run*/Start*/Stop*/Terminate*/Modify*/Create*/Delete*.
ElbAndRdsDescribeReadOnly	Idle load balancers (no healthy targets) and idle/oversized RDS are frequent waste. Describe* only.	List APIs without resource-level ARNs. No rds:Modify*/Delete*/Reboot*, no ELB mutation.
LambdaAndStorageInventoryReadOnly	Inventory functions + buckets to correlate against CloudWatch idle metrics.	Deliberately excludes s3:GetObject — the role never reads object data, only ListAllMyBuckets + GetBucketLocation (existence/region). No lambda:InvokeFunction, no Lambda mutation. This is the tightest the inventory can be while still seeing what exists.

What is deliberately NOT here (blast-radius containment)

• No iam:*, sts:AssumeRole onward-chaining, organizations:*, or account:*.
• No s3:GetObject / s3:GetObjectVersion (no data-plane read of any bucket).
• No secretsmanager:GetSecretValue / ssm:GetParameter* (no secret read).
• No kms:Decrypt, no logs:GetLogEvents (no log/data exfil path).
• No write/modify/delete verb in any service.

A leaked session from this role can enumerate and price the account, and nothing more — it cannot read application data, secrets, or change a single resource.

Cross-review NIT answers (2026-06-18)

• ec2:DescribeSnapshots kept (NIT: is it needed?) — yes. Orphan EBS snapshots are a common idle-spend line item (snapshots of long-deleted volumes keep billing); the checker lists them to flag that waste. It returns only account-owned metadata (we query with OwnerIds=["self"]), no snapshot data. ec2:DescribeImages (AMIs) was the over-grant and was removed.
• s3:ListAllMyBuckets kept (NIT: data exposure?) — it returns only bucket names you own, no object data and no bucket contents; s3:GetBucketLocation returns only the region. Both are account-owned inventory queries needed to correlate idle buckets/regions against cost. No s3:GetObject anywhere, so there is no data-plane read path.
• No logs:* (NIT: do we need CloudWatch Logs?) — no. aws-posture reasons over metrics (cloudwatch:GetMetric*) and the cost/inventory describe calls; it never needs log events. Omitting logs:GetLogEvents/logs:FilterLogEvents keeps the role off the log-exfil path.
• aws:RequestedRegion condition (NIT: optional region pin) — SKIPPED, deliberately. The reviewer flagged this as optional. It is NOT applied because Cost Explorer (ce:*) and s3:ListAllMyBuckets are global-endpoint services that resolve to us-east-1 with request contexts where aws:RequestedRegion does not reliably equal us-east-1 — a blanket region condition risks DENYing the core cost signal. Scoping it to a separate statement covering only the regional Describe* calls (ec2/rds/elb/cloudwatch) would add a fourth+ statement for marginal benefit (the action allow-list already bounds blast radius, and the box only ever runs in us-east-1). Per the task's guidance, we prefer SKIP over a region pin that could break the global-service statements.

Comparison to the AWS-managed alternatives

ReadOnlyAccess / ViewOnlyAccess are far broader (they include s3:GetObject, dynamodb:GetItem, secretsmanager list, etc.). This custom policy is intentionally a small fraction of those — only the cost + idle-inventory surface the checker actually queries.