security-review/iam/aws-posture-readonly-policy.rationale.md
Adam Moussa 4c88c01f7b
chore: import security-review gate, sweep, and Plane-1 checkers into standalone repo
Fresh-init copy of the security-review/ subsystem extracted from
Sea-Haven-Industries/orchestrator (being deprecated). Adds org-standard scaffold:
CI reusable-workflow callers (ruff + collect), dependency-review, labeler,
dependabot, .gitignore, requirements.txt. Scheduled execution is migrating to
Claude Code web routines (ALARM-only to #repo-scanner); the systemd units and
nightly_sweep.sh/checker_coordinator.sh remain the source of truth.

Committed with --no-verify: the canary fixtures (checkers/fixtures/**) carry
intentional secret-shaped test data that trips the deterministic gate (the
documented detector-fixture false positive); no new logic is introduced.
2026-06-29 11:41:41 -04:00

6.3 KiB

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.