adam/seahaven-org-baseline
1
0
Fork 0
mirror of https://github.com/Sea-Haven-Industries/seahaven-org-baseline.git synced 2026-09-30 10:23:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
seahaven-org-baseline/lib/deploy-substrate/deploy-substrate.template.yaml
Adam Moussa 59852eff34
fix(iam): restore four permissions the boundary would have denied at migration 
/sh-security-review (6 detectors + verifier) found four HIGH findings, all the
same defect class: the template's permission-source comment block was used as
the sanctioned scope source, but it is an incomplete and in places invented
secondary record. Each was verified against the real stack template before
fixing. None is live today (prod/dev boundary usage is 0); all four would have
been AccessDenied at first migration, three of them SILENTLY.

- SES configuration-set/seahaven-email-events restored. afterhours-shift-manager
  template.yaml:178-181 grants it with an in-repo comment stating the send is
  denied without it. An earlier revision dropped it after checking whether any
  config set exists in prod/dev today (none do) -- the wrong test. The right
  question is whether an enumerated stack's own IAM policy names it.
- SES identity/seahavenind.com added. meal-order-manager's SenderEmail defaults
  to adam@seahavenind.com (template.yaml:20-22) and email_report sends with it.
  The prior 'unverified identity fails loudly anyway' argument holds only until
  the migration verifies the domain, which the migration procedure requires.
- scheduler:Create/Delete/GetSchedule + iam:PassRole (scheduler.amazonaws.com
  only) added. afterhours template.yaml:110-120 needs both; the block omitted
  them entirely. Failure is silent -- app.py wraps create_schedule in a bare
  except, so the Slack command reports success and no schedule exists.
- secret:afi-slack-webhook-* added. The block named
  'afi-backup-monitor/slack-webhook-url', which does not exist; both afi secret
  ARNs are deploy parameters, so the real names live only in that repo's
  README:48-49 (afi-api-key, afi-slack-webhook).

Also corrected, all comment-only:
- The permission-source block itself, at each of the four points it was wrong,
  with the correction and its evidence recorded inline.
- The false claim that SAM auto-names async DLQs (it does not -- all four
  payments queues are hand-written with explicit QueueNames). Replaced with the
  real invariant: any queue a boundary-carrying function sends to must be
  payments-* or the boundary widens in the same PR; a denied destination write
  is silent.
- SIZE BUDGET: was 13 statements / 4,060 chars, actually 16 / 5,457 after these
  fixes. Headroom is 687 chars, roughly ONE more workload -- not the five the
  header claimed. Flagged per-workload boundaries as the realistic next move.

Verified unchanged: logical id LambdaExecutionBoundary and ManagedPolicyName
seahaven-lambda-execution-boundary, so all eight pinning conditions across both
guardrail policies still resolve.
2026-07-30 18:17:16 -04:00

1481 lines
78 KiB
YAML
Raw Blame History

AWSTemplateFormatVersion: "2010-09-09"
Description: >-
Per-account GitHub Actions deploy substrate for Sea Haven Industries:
the shared account-level resources every SAM deploy pipeline needs
(GitHub OIDC provider, Lambda execution permissions boundary, and the
shared CloudFormation execution role). Per-repo githubdeploy-* roles
are NOT here — they are provisioned per repo at migration/onboarding
time in the target account.
# PROVENANCE / DRIFT WARNING
# The Resources below are a VERBATIM extraction of the substrate section
# (OIDC provider + LambdaExecutionBoundary + SamCfnExecutionRole) of
# Sea-Haven-Industries/.github/oidc-deploy-roles.yaml at commit 786dcfe8,
# which remains the deployed source of truth for the management account
# (328440206208) until that account's stacks finish migrating out. If a
# substrate resource must change while both copies are live, change BOTH
# files in the same piece of work. Documented deltas from the source:
# - unused GitHubOrg parameter dropped (only serves the per-repo roles
# left behind),
# - DependsOn: LambdaExecutionBoundary added to SamCfnExecutionRole (the
# role only names the boundary ARN inside Condition strings, so CFN
# infers no edge; first-create needs the boundary to exist first — moot
# for mgmt where both resources already exist, so mgmt's copy is
# deliberately unchanged),
# - DeletionPolicy/UpdateReplacePolicy Retain on the OIDC provider,
# - the boundary-gated IAM block moved from an INLINE role policy into an
# attached managed policy (SamCfnIamManagementPolicy). Forced by IAM's
# 10,240-byte per-role inline limit: mgmt's inline set is ~10.1 KB, i.e.
# ~94 bytes from the cap, so the added Deny statements did not fit and the
# first deploy failed with ServiceLimitExceeded (2026-07-27). Effective
# permissions are unchanged — verified by comparing the full 27-statement
# set before and after the move (identical), since identity policies are
# unioned and an explicit Deny still wins. mgmt received this same
# restructure in Phase B (.github PR #98), so this is no longer a
# divergence,
# - SECURITY FIX (now in BOTH copies): iam:DeleteRolePermissionsBoundary
# removed from Sid IAMPutPermissionsBoundary and explicit Deny statements
# (DenyBoundaryTampering / DenyBoundaryPolicyEdit / DenySelfMutation)
# added. The mgmt copy was remediated 2026-07-27 (.github PRs #95 Phase A
# + #98 Phase B); DenySelfMutation and the widened policy/seahaven-*
# DenyBoundaryPolicyEdit scope were then ported back here, so the two
# copies' GUARDRAIL statement sets were reconciled as of that date.
# SamCfnIamManagementPolicy and SamCfnExecutionRole remain byte-identical
# across the two files and MUST still be changed together; the only delta
# between them is the DependsOn line above, which is ordering, not
# permission. LambdaExecutionBoundary is NO LONGER byte-identical — see
# DELIBERATE DIVERGENCE below.
#
# DELIBERATE DIVERGENCE — LambdaExecutionBoundary (INFRA-186, 2026-07-30)
# The parity rule above is SCOPED, not global. LambdaExecutionBoundary in THIS
# file is DELIBERATELY STRICTER than the mgmt copy in
# Sea-Haven-Industries/.github/oidc-deploy-roles.yaml. Do not "reconcile" the two
# by copying mgmt's statements back over these, or vice versa; the divergence is
# load-bearing. A future mechanical drift check WILL read it as drift — it is not.
#
# 1. WHAT DIVERGED. Every scopable Resource pattern in LambdaExecutionBoundary
# was re-scoped from account-wide wildcards (table/*, table/*/index/*,
# secret:*, parameter/*, sqs :*, function:*, ses identity/* +
# configuration-set/*, and an s3:::*-<accountid> pattern that was a bare
# name-suffix filter rather than an ownership check) to per-workload
# prefixes drawn from the permission-source block above. The three genuinely
# unscopable statements (CloudWatchLogsDescribe, XRay, Ec2Eni) keep
# Resource "*" with written justification on each. CloudWatch Logs was split
# into a scoped write half and a wildcard describe half. KMS keeps key/* and
# is scoped by a kms:ViaService condition instead, because key ARNs carry
# UUID key ids that cannot be prefix-scoped.
#
# 2. WHY MGMT'S RATIONALE IS LEGITIMATE THERE. The superset framing this file
# used to carry ("being slightly broad is the correct trade-off; a boundary
# that is too tight will break Lambda functions at runtime AFTER deploy") is
# a real constraint in the management account: 328440206208 has 26 LIVE
# roles carrying seahaven-lambda-execution-boundary, across all five SAM
# stacks. Tightening there is a production change to running workloads with
# a silent, deploy-time-invisible failure mode.
#
# 3. WHY IT DOES NOT TRANSFER HERE. This file deploys ONLY to seahaven-prod
# (011934824531) and seahaven-dev (710827005802), where
# PermissionsBoundaryUsageCount is 0 and 0 respectively (aws iam get-policy,
# verified 2026-07-30; corroborated by list-roles returning no role carrying
# any permissions boundary in either account). No live Lambda can break, so
# the risk that justifies mgmt's breadth is absent — while the exposure is
# strictly WORSE here than in mgmt, because prod is multi-tenant: the old
# wildcards reached proposal-system's, procurement-ingest's and
# workorder-ingest's CDK-owned tables, buckets, secrets and queues, the org's
# own Config and VPC-flow-log buckets, and — via function:* — CDK Lambdas
# that carry no boundary at all.
#
# 4. RECONCILIATION OBLIGATION, RESTATED. For LambdaExecutionBoundary the two
# copies are now INTENTIONALLY DIFFERENT and must NOT be synchronised:
# - A change to the per-workload Resource patterns in THIS file does NOT
# propagate to mgmt.
# - A change to mgmt's boundary does NOT propagate here.
# - Any change to the ACTION lists, or any new statement, is a substrate
# semantic change and DOES still require the same review in both copies.
# For SamCfnIamManagementPolicy and SamCfnExecutionRole the original rule is
# unchanged: change BOTH files in the same piece of work.
#
# KNOWN OPEN ITEM (deferred, not closed by INFRA-186): mgmt 328440206208 still
# carries the account-wide patterns. Tightening it needs its own validated
# rollout — enumerate what the 26 live roles actually call, stage it, and be
# ready to roll back — and is explicitly OUT OF SCOPE of INFRA-186. Until that
# lands, the two copies stay divergent and that is the intended state.
#
# COUPLING: the boundary's ManagedPolicyName and ARN are UNCHANGED and must stay
# unchanged. Four Conditions in SamCfnIamManagementPolicy below, and four more in
# HcptfIamManagementPolicy in lib/terraform-substrate/terraform-substrate.template.yaml,
# pin arn:aws:iam::<account>:policy/seahaven-lambda-execution-boundary by literal
# string inside StringEquals iam:PermissionsBoundary. A rename fails SILENTLY — an
# IAM condition naming a non-existent policy simply never matches, so the
# escalation control would evaporate rather than error — and would additionally
# force a CloudFormation REPLACEMENT that any role carrying the boundary would
# block. INFRA-186 is a CONTENT-ONLY change for exactly this reason;
# terraform-substrate.template.yaml already records that expectation and is
# correctly left untouched.
#
# SIZE BUDGET: an attached managed policy document is capped at 6,144 characters
# (whitespace excluded). LambdaExecutionBoundary measures 5,457 characters across
# 16 statements as of 2026-07-30 (was 2,507 across 11 before this scoping pass —
# TIGHTENING COSTS CHARACTERS, and the review corrections cost more). Measure
# before widening — len(json.dumps(doc,separators=(',',':'))) on the synthesized
# PolicyDocument with ${AWS::AccountId} resolved, and UPDATE THESE TWO NUMBERS in
# the same edit (they went stale once already inside a single branch).
#
# ⚠ HEADROOM IS 687 CHARACTERS — roughly ONE more workload at ~450 each, NOT the
# "five" an earlier revision of this header claimed. The next stack to migrate is
# likely to exhaust it. Read the note below before assuming there is room: the
# realistic next move is per-workload boundaries
# (seahaven-lambda-execution-boundary-<workload>), which is also the durable fix
# for the shared-ceiling residual documented in the SCOPING RULE.
# CRITICAL: unlike the 2026-07-27 inline-limit incident,
# there is NO restructure available when this cap is reached — a role has exactly
# ONE permissions boundary, so statements cannot be spilled into a second attached
# managed policy. At the cap the only levers are prefix consolidation and dropping
# unused actions.
#
# This template is deployed via lib/deploy-substrate-stack.ts
# (cloudformation-include) as stack seahaven-deploy-substrate, once per member
# account that hosts SAM workloads (currently seahaven-prod 011934824531 and
# seahaven-dev 710827005802 via bin/app.ts instances deploy-substrate-prod /
# deploy-substrate-dev; NEVER mgmt — 328440206208 is served by the .github copy
# named above until its stacks migrate out).
Parameters:
CreateOIDCProvider:
Type: String
Default: "false"
AllowedValues: ["true", "false"]
Description: Set to true only if the GitHub OIDC provider does not already exist in this account
Conditions:
ShouldCreateOIDCProvider: !Equals [!Ref CreateOIDCProvider, "true"]
Resources:
# ---------------------------------------------------------------------------
# OIDC Provider (conditional — most accounts already have it; seahaven-prod
# and seahaven-dev both do, from their githubdeploy-* role provisioning)
# ---------------------------------------------------------------------------
GitHubOIDCProvider:
Type: AWS::IAM::OIDCProvider
Condition: ShouldCreateOIDCProvider
Properties:
Url: https://token.actions.githubusercontent.com
ClientIdList:
- sts.amazonaws.com
ThumbprintList:
- 6938fd4d98bab03faadb97b34396831e3780aea1
# An account has exactly ONE provider per URL and every githubdeploy-* role
# trusts it. Retain so that flipping createOidcProvider back to false (or
# deleting this stack) can never delete the account's federation anchor and
# break every deploy into it.
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
# ---------------------------------------------------------------------------
# Lambda execution permissions boundary (INFRA-103, re-scoped by INFRA-186)
#
# This managed policy is the CEILING for every Lambda execution role that the
# five SAM stacks auto-generate via AWS::Serverless::Function. Applying it as
# PermissionsBoundary on those roles means the effective permissions are the
# intersection of the role's own policies and this boundary, so a misconfigured
# SAM role can never exceed what is listed here.
#
# SCOPING RULE (INFRA-186, 2026-07-30). This boundary is a CLOSED ENUMERATION
# of per-workload resource prefixes. It was previously a deliberate SUPERSET
# with account-wide wildcards (table/*, secret:*, sqs :*, function:*,
# parameter/*, and an s3:::*-<accountid> pattern that was a name-suffix filter,
# not an ownership check). That trade-off was made when the only account
# carrying this policy hosted nothing but the five SAM stacks. It does not
# survive multi-tenancy: seahaven-prod now hosts CDK-owned tenants
# (proposal-system, procurement-ingest, workorder-ingest) whose tables, buckets,
# secrets and queues those wildcards reached, and whose Lambdas carry NO
# permissions boundary at all — making function:* a boundary-escape primitive.
#
# Tightening here carries ZERO runtime risk and was sequenced deliberately:
# PermissionsBoundaryUsageCount is 0 in BOTH accounts this template deploys to
# (seahaven-prod 011934824531 and seahaven-dev 710827005802, verified
# 2026-07-30), so no live Lambda can break. A boundary that is slightly TOO
# TIGHT is recoverable here — the migrating stack widens it in its own PR before
# its first deploy — whereas leaving it loose perpetuates the exposure. Prefer
# tighter; the widening path is below.
#
# A resource pattern that genuinely CANNOT be scoped keeps its wildcard WITH a
# written justification on the statement: CloudWatchLogsDescribe, XRay and
# Ec2Eni name runtime-created resources or use actions AWS authorises against
# "*" regardless of the ARN supplied. Do not "tighten" those.
#
# WIDENING PATH — read this before migrating a stack into prod or dev.
# The boundary is never widened by the person who hits the AccessDenied. It is
# widened by the migrating stack's owner, in THIS repo, BEFORE the workload's
# first deploy into the target account:
# 1. Add the workload's prefixes to the relevant per-service Resource lists
# above — never add a new per-workload statement (a duplicated action list
# costs ~250 characters for zero new actions; an extra ARN costs ~60).
# Add its entry to the permission-source block below in the same edit: that
# block is the sanctioned scope source, and a prefix added without one will
# be "reconciled" away later.
# 2. Measure. See SIZE BUDGET in the header. There is NO escape hatch.
# 3. Both review gates run and neither discharges the other: the GPT-4.1
# cross-family review against the real diff, and /sh-security-review
# (IaC/IAM is on the mandatory surface). CLI down = review outstanding.
# 4. Merge and let CI deploy deploy-substrate-prod / deploy-substrate-dev to
# UPDATE_COMPLETE, THEN deploy the workload stack.
# 5. Check the managed-policy VERSION budget first: max 5 versions, both
# accounts are on v1 today. Every widening — and every Description-only
# edit — burns one. Delete the oldest non-default version if at 5.
# ORDERING IS NOT ENFORCED BY CLOUDFORMATION AND THIS IS THE MOST IMPORTANT
# SENTENCE HERE: the workload's deploy SUCCEEDS even against a stale boundary,
# because seahaven-cfn-exec-iam-management's gate checks that the boundary ARN
# is attached, never its contents. The failure surfaces later, at first invoke,
# as AccessDenied. A stale boundary is a silent deploy-time pass and a loud
# production failure.
#
# CONSIDERED AND REJECTED: a Deny statement reserving the seahaven-* namespace.
# With the Allow set now enumerated per workload it is fully redundant (verified
# 2026-07-30: seahaven-prod-config-* and seahaven-prod-vpc-flow-logs-* are
# already denied by the Allow set alone), and a Deny inside a BOUNDARY is the
# hardest failure mode in the estate to debug — it beats every Allow in every
# policy with no synth-time signal. Revisit only if a widening ever has to
# re-broaden a per-service Resource list back toward a wildcard.
#
# NOTE ON WHAT THESE PREFIXES ARE. All five stacks below currently live in the
# MANAGEMENT account and none of their resources exists in seahaven-prod or
# seahaven-dev yet. These are MIGRATION-CANDIDATE prefixes for the accounts this
# template deploys to, not an inventory of what is deployed there. They are the
# sanctioned scope source because they are the enumerated permission sources of
# the stacks this boundary exists to cap.
#
# Permission sources per stack (verified live 2026-07-30; this block is the
# sanctioned source for every Resource pattern above — keep it accurate):
#
# afterhours-shift-manager (functions: afterhours-*, 6 live)
# - DynamoDB CRUD (afterhours-shifts table)
# - secretsmanager:GetSecretValue (afterhours-shift-manager/*)
# - ses:SendEmail on the identity AND on
# configuration-set/seahaven-email-events (template.yaml:178-181 — the
# send is DENIED without the config-set ARN when the identity has a
# default configuration set)
# - scheduler:CreateSchedule/DeleteSchedule/GetSchedule on
# schedule/default/holiday-* + iam:PassRole to scheduler.amazonaws.com
# (template.yaml:110-120). CORRECTED 2026-07-30: this block previously
# omitted both, and the omission is SILENT at runtime (bare except).
# - NO ssm. CORRECTED 2026-07-30: this block previously credited
# ssm:GetParameter to this stack; `grep -c 'ssm:' template.yaml` = 0.
# Its slack tokens come from Secrets Manager and the channel id from a
# CloudFormation parameter.
# - lambda:InvokeFunction (ReleaseNotifyInvokeRole,
# HolidaySchedulerExecutionRole — these two carry the boundary and need
# ONLY this action)
# - CloudWatch Logs (all functions)
# - UNRESOLVED: /3cx-scheduler/* ownership (this stack vs. the retired
# standalone 3CX scheduler). Deliberately NOT granted. Resolve at migration.
#
# payments-dashboard (functions: payments-*)
# - DynamoDB CRUD / Read (PaymentsDashboard table — legacy PascalCase)
# - S3 GetObject on seahaven-payments-csv-* and seahaven-payroll-emails-*;
# GetObject + PutObject on seahaven-payments-boa-raw-*
# (template.yaml:272 and 1097-1099, fetchBoaTransactions raw archive).
# CORRECTED 2026-07-30: this block previously said "GetObject ONLY —
# no write intent enumerated", which was false and would have denied
# the raw-archive write at migration.
# - secretsmanager:GetSecretValue (payments-dashboard/*)
# - sqs Send/Receive/Delete etc. (payments-payroll-batch + DLQs)
# - lambda:InvokeFunction (ExpenseReceiver -> ExpenseProcessor)
# - ec2 ENI lifecycle (VPC-attached functions)
# - KMS via dynamodb (table CMK) — no SSM, no SES
# - CloudWatch Logs
#
# meal-order-manager (functions: meal-order-manager-*, 7 live)
# - DynamoDB CRUD / Read (meal-order-manager-orders table)
# - S3 CRUD (meal-order-manager-reports-*, meal-order-manager-form-*)
# - secretsmanager:GetSecretValue (meal-order-manager/*)
# - ssm:GetParameter (/meal-order-manager/*)
# - lambda:InvokeFunction (submit-order -> slack-notifier,
# close-form -> aggregate-orders, plus AdminAuthorizerInvokeRole)
# - ses:SendRawEmail
# - CloudWatch Logs
#
# front-integrations (functions: front-*)
# - DynamoDB CRUD (front-sla-alerts table)
# - secretsmanager:GetSecretValue (front-integrations/*)
# - CloudWatch Logs
# - no S3 / SQS / SSM / SES / KMS / VPC
#
# afi-backup-monitor (functions: afi-*)
# - secretsmanager:GetSecretValue on TWO bare, unprefixed secrets:
# afi-api-key and afi-slack-webhook. CORRECTED 2026-07-30: this block
# previously named "afi-backup-monitor/slack-webhook-url", which does
# not exist. Both ARNs are deploy PARAMETERS in that stack
# (AfiApiKeySecretArn / SlackWebhookSecretArn), so no name is
# discoverable from its template — the names are in its README:48-49.
# - CloudWatch Logs
# - nothing else
#
# ---------------------------------------------------------------------------
LambdaExecutionBoundary:
Type: AWS::IAM::ManagedPolicy
Properties:
ManagedPolicyName: seahaven-lambda-execution-boundary
Description: >-
Permissions boundary ceiling for all SAM-managed Lambda execution roles.
Applied via PermissionsBoundary on every Globals.Function in the five
SAM stacks (INFRA-103). Effective permissions are the intersection of
this policy and the role's own inline policies.
PolicyDocument:
Version: "2012-10-17"
Statement:
# ── CloudWatch Logs — write (every Lambda) ──────────────────────────
# Scoped to the Lambda log-group namespace. Every SAM function's group
# is /aws/lambda/<function>, and the trailing * also covers the
# :log-stream:<name> suffix PutLogEvents authorises against, so one ARN
# serves CreateLogGroup, CreateLogStream, PutLogEvents and
# DescribeLogStreams. The * is deliberately NOT after a trailing slash:
# /aws/lambda* also matches the /aws/lambda-insights groups the Lambda
# Insights extension writes to, which /aws/lambda/* would have denied.
# VERIFICATION PROVENANCE, stated precisely (2026-07-30). What
# iam simulate-custom-policy DOES confirm: this pattern allows
# logs:CreateLogGroup / logs:PutLogEvents on the bare group ARN
# log-group:/aws/lambda/<fn> (and /aws/lambda/<a>/<b>), and DENIES
# log-group:seahaven-prod-vpc-flow-logs — the latter re-checked against
# an Allow */* positive control, which allows it, so the deny is real
# policy behaviour and not a simulator artifact.
# What the simulator CANNOT evaluate, so do NOT claim it was verified:
# log-stream-qualified ARNs (log-group:<g>:log-stream:<s>) and the bare
# /aws/lambda-insights group both return implicitDeny EVEN UNDER an
# Allow */* policy. That is a simulator resource-parsing limitation, not
# a denial. Coverage of those two rests on documented IAM wildcard
# semantics — "*" matches any sequence of characters including ":" and
# "/" — which is why the * is deliberately NOT placed after a trailing
# slash. If this ever needs true end-to-end proof, it must come from a
# real invoke in dev, not from the simulator.
#
# NOT scoped per workload, deliberately. A per-stack prefix
# (/aws/lambda/payments-* etc.) was considered and rejected: a Lambda
# denied PutLogEvents does not fail — it keeps running and silently
# produces no logs. Log denial is the one failure class in this policy
# that is NOT loud, so it must not depend on function-name discipline.
# ACCEPTED RESIDUAL RISK: a SAM Lambda can write into another tenant's
# /aws/lambda/* group (log poisoning). No read action is granted here, so
# this is not an exfiltration path. Tighten only once every
# boundary-carrying function is confirmed to set an explicit FunctionName.
- Sid: CloudWatchLogsWrite
Effect: Allow
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
- logs:DescribeLogStreams
Resource:
- !Sub "arn:aws:logs:us-east-1:${AWS::AccountId}:log-group:/aws/lambda*"
# ── CloudWatch Logs — describe (UNSCOPABLE, kept "*" deliberately) ──
# logs:DescribeLogGroups is a COLLECTION action: AWS authorises it
# against "*" regardless of any resource ARN supplied. Scoping it would
# produce a policy that reads tighter and denies at runtime, so it is
# split into its own statement and keeps the wildcard. Read-only
# metadata; it cannot mutate anything or return log content.
- Sid: CloudWatchLogsDescribe
Effect: Allow
Action:
- logs:DescribeLogGroups
Resource: "*"
# ── X-Ray tracing (UNSCOPABLE, kept "*" deliberately) ───────────────
# xray:PutTraceSegments / PutTelemetryRecords support no resource-level
# permissions — X-Ray exposes no ARN for them, which is why the AWS
# managed AWSXRayDaemonWriteAccess also uses "*". Any ARN written here
# would be inert and would falsely imply a control exists. Write-only
# into this account's own trace store; no cross-tenant read is
# expressible with this action set.
- Sid: XRay
Effect: Allow
Action:
- xray:PutTraceSegments
- xray:PutTelemetryRecords
Resource: "*"
# ── VPC / ENI management (UNSCOPABLE, kept "*" deliberately) ────────
# Matches AWSLambdaVPCAccessExecutionRole exactly, and for the same
# reasons. The three ec2:Describe* actions do not support resource-level
# permissions AT ALL — an ARN in Resource is ignored and the call is
# authorised against "*" — so narrowing them is cosmetic. The ENI in
# CreateNetworkInterface / DeleteNetworkInterface is created by the
# Lambda service at attach time with an id that cannot exist when this
# policy is written. Nothing here is scopable by resource name.
# AssignPrivateIpAddresses / UnassignPrivateIpAddresses are for EFA and
# secondary IPs — not part of the Lambda ENI lifecycle — omitted.
#
# KNOWN OPEN ITEM (pre-existing, NOT introduced by INFRA-186):
# ec2:DeleteNetworkInterface on "*" lets a bounded Lambda delete any ENI
# in the account, including NAT / VPC-endpoint / RDS ENIs — a
# denial-of-service primitive inherited from the AWS managed policy. The
# durable fix is a Condition on ec2:Subnet / ec2:Vpc naming the VPC the
# Lambda fleet attaches to. That VPC does not exist in seahaven-prod or
# seahaven-dev today (payments-dashboard's 10.20.0.0/16 VPC is in mgmt),
# so writing the condition now would encode an mgmt resource into a
# prod/dev template. Whoever brings the VPC across in payments-dashboard's
# migration PR adds the condition in the same PR.
- Sid: Ec2Eni
Effect: Allow
Action:
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
- ec2:DescribeSubnets
- ec2:DescribeSecurityGroups
- ec2:DescribeVpcs
Resource: "*"
# ── DynamoDB — one prefix per enumerated workload ───────────────────
# Replaces table/* + table/*/index/*, which reached every table in the
# account. A trailing * on each workload prefix covers the base table
# AND its /index/* GSI ARNs in a single entry (IAM wildcards match "/"),
# verified 2026-07-30 with iam simulate-custom-policy against
# table/afterhours-shifts/index/gsi1 — so the separate table/*/index/*
# line is deleted, not replaced. Prod's CDK-owned tables (WorkOrders,
# WorkOrderComments, purchase-orders, verified-sites, pending-site-review)
# match none of these prefixes, which is the point.
# PaymentsDashboard is a legacy PascalCase table exempt from renaming
# under handbook naming-conventions.md; the kebab-case prefix is listed
# alongside it so a future rename cannot silently lock the stack out.
# Table names are NOT stack names (afterhours-shifts, front-sla-alerts) —
# scoping naively off stack name would deny at runtime.
- Sid: DynamoDB
Effect: Allow
Action:
- dynamodb:GetItem
- dynamodb:PutItem
- dynamodb:UpdateItem
- dynamodb:DeleteItem
- dynamodb:Query
- dynamodb:Scan
- dynamodb:BatchGetItem
- dynamodb:BatchWriteItem
- dynamodb:DescribeTable
- dynamodb:ConditionCheckItem
Resource:
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/afterhours-*"
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/front-*"
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/meal-order-manager-*"
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/PaymentsDashboard*"
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/payments-dashboard-*"
# ── S3 — write access (meal-order-manager only) ─────────────────────
# THE LARGEST SECURITY WIN IN INFRA-186. The removed
# arn:aws:s3:::*-${AWS::AccountId} was not a per-workload scope at all:
# S3 ARNs carry no account field, so it was a bare NAME-SUFFIX FILTER
# matching every bucket in the account whose name ends in the account id.
# In seahaven-prod today that was 8 of 9 buckets — all four
# proposal-system-*, both ingest-email buckets, AND the org's own
# seahaven-prod-config-* and seahaven-prod-vpc-flow-logs-* — with
# PutObject and DeleteObject. That is anti-forensics capability over the
# org's own security telemetry, handed to the SAM fleet's ceiling.
# Verified 2026-07-30 with iam simulate-custom-policy: the patterns below
# deny seahaven-prod-config-*, seahaven-prod-vpc-flow-logs-* and
# proposal-system-uploads-*, and allow meal-order-manager-reports-*.
# The four meal-order-manager-*-${AWS::AccountId} entries previously
# listed here were strictly redundant — every one ends in -<accountid> and
# was already matched by the wildcard above them; their comment claiming a
# "non-AccountId suffix pattern" was contradicted by the ARNs beneath it.
# Split by DIRECTION of access: meal-order-manager is the only stack the
# permission-source block gives write intent to (ReportsBucket /
# FormBucket CRUD). Both the bucket and object ARN forms are listed in
# each statement because s3:ListBucket authorises against the bucket ARN
# and s3:GetObject against the object ARN.
- Sid: S3WorkloadReadWrite
Effect: Allow
Action:
- s3:GetObject
- s3:PutObject
- s3:DeleteObject
- s3:ListBucket
- s3:GetBucketLocation
- s3:GetObjectVersion
- s3:GetObjectTagging
- s3:PutObjectTagging
Resource:
- !Sub "arn:aws:s3:::meal-order-manager-*-${AWS::AccountId}"
- !Sub "arn:aws:s3:::meal-order-manager-*-${AWS::AccountId}/*"
# ── S3 — payments-dashboard ─────────────────────────────────────────
# Split by direction, but note the source of truth: the template
# comment above enumerates "S3 GetObject" for payments-dashboard, and
# that enumeration is INCOMPLETE. Verified against the real stack
# 2026-07-30 — payments-dashboard/template.yaml grants s3:PutObject on
# BoaRawBucket (lines 272 and 1098-1099), so the fetchBoaTransactions
# path writes raw BoA payloads. A read-only grant here would deny that
# write at migration time. Write is therefore allowed on the boa-raw
# bucket ONLY; payroll-emails and payments-csv stay read-only, so a
# compromised payments function still cannot delete payroll evidence.
# Buckets carry the org-wide seahaven- prefix rather than a payments-
# one, which is why bucket names cannot be derived from stack names.
- Sid: S3PaymentsBoaRawWrite
Effect: Allow
Action:
- s3:GetObject
- s3:PutObject
- s3:GetObjectVersion
- s3:ListBucket
- s3:GetBucketLocation
Resource:
- !Sub "arn:aws:s3:::seahaven-payments-boa-raw-${AWS::AccountId}"
- !Sub "arn:aws:s3:::seahaven-payments-boa-raw-${AWS::AccountId}/*"
- Sid: S3WorkloadReadOnly
Effect: Allow
Action:
- s3:GetObject
- s3:GetObjectVersion
- s3:ListBucket
- s3:GetBucketLocation
Resource:
- !Sub "arn:aws:s3:::seahaven-payments-csv-${AWS::AccountId}"
- !Sub "arn:aws:s3:::seahaven-payments-csv-${AWS::AccountId}/*"
- !Sub "arn:aws:s3:::seahaven-payroll-emails-${AWS::AccountId}"
- !Sub "arn:aws:s3:::seahaven-payroll-emails-${AWS::AccountId}/*"
# ── Secrets Manager — one <stack>/ prefix per workload ──────────────
# Replaces secret:*, which in seahaven-prod today reads
# proposal-system/db-credentials, proposal-system/bedrock-user,
# procurement-ingest/web-ui-auth-token and workorder-ingest/shoc-webhook-hmac
# — the last of which is an HMAC SIGNING key, so the wildcard was a
# webhook-forgery primitive against the SHOC integration.
# The trailing * after each / is MANDATORY, not decorative: Secrets
# Manager appends a random 6-character suffix to every ARN, so an
# exact-name ARN never matches. Verified 2026-07-30 with
# iam simulate-custom-policy against a suffixed ARN.
# afi-api-key is a bare, unprefixed, account-root secret that predates the
# <stack>/<name> convention (afi-backup-monitor's OTHER secret,
# afi-backup-monitor/slack-webhook-url, is correctly prefixed). It is
# listed explicitly because omitting it would encode a KNOWN-WRONG scope
# that fails silently months from now at migration. MIGRATION OBLIGATION:
# afi-backup-monitor's migration PR renames it to
# afi-backup-monitor/api-key and deletes this line.
# secretsmanager:ListSecrets and BatchGetSecretValue are deliberately
# ABSENT and must stay absent — AWS authorises both against "*" regardless
# of any resource list, so adding either would silently reinstate
# account-wide read. (Precedent: BatchGetSecretValue synthed clean, passed
# review, then AccessDenied in production and crash-looped open-swe.)
- Sid: SecretsManager
Effect: Allow
Action:
- secretsmanager:GetSecretValue
- secretsmanager:DescribeSecret
Resource:
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:afterhours-shift-manager/*"
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:afi-backup-monitor/*"
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:afi-api-key-*"
# CORRECTION (2026-07-30 review): the permission-source block
# named this secret "afi-backup-monitor/slack-webhook-url", which
# does not exist. afi-backup-monitor/template.yaml takes both
# secret ARNs as deploy PARAMETERS, so no name is discoverable
# from the template; the real names are in that repo's README
# (afi-api-key and afi-slack-webhook, both bare/unprefixed). Same
# rename-at-migration obligation as afi-api-key applies.
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:afi-slack-webhook-*"
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:front-integrations/*"
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:meal-order-manager/*"
- !Sub "arn:aws:secretsmanager:us-east-1:${AWS::AccountId}:secret:payments-dashboard/*"
# ── SSM Parameter Store (meal-order-manager, afterhours) ────────────
# Replaces parameter/*, which in seahaven-prod reads
# /procurement-api/custom-domain/certificate-arn and
# /seahaven/dynamodb/cmk-arn. These are exactly the two hierarchies the
# statement's own heading already claimed to serve.
# The bare-path entries alongside the /* entries are REQUIRED, not
# duplicates: ssm:GetParametersByPath authorises against the PATH ARN,
# not the leaf, so a /*-only grant can deny the recursive read.
# Note the ARN form drops the parameter's leading slash.
# /3cx-scheduler/* is deliberately EXCLUDED: ownership between
# afterhours-shift-manager and the retired standalone 3CX ring-group
# scheduler is unresolved, and inventing a scope is not permitted.
# Resolve at afterhours' migration and widen then if it is genuinely ours.
- Sid: SSMParameterRead
Effect: Allow
Action:
- ssm:GetParameter
- ssm:GetParameters
- ssm:GetParametersByPath
Resource:
- !Sub "arn:aws:ssm:us-east-1:${AWS::AccountId}:parameter/afterhours-shift-manager"
- !Sub "arn:aws:ssm:us-east-1:${AWS::AccountId}:parameter/afterhours-shift-manager/*"
- !Sub "arn:aws:ssm:us-east-1:${AWS::AccountId}:parameter/meal-order-manager"
- !Sub "arn:aws:ssm:us-east-1:${AWS::AccountId}:parameter/meal-order-manager/*"
# ── SQS (payments-dashboard batch queues + async DLQs) ──────────────
# payments-dashboard is the only enumerated stack with a queue
# dependency, and all of its live queues are payments-prefixed. Replacing
# :* costs four characters and removes sqs:ReceiveMessage /
# sqs:DeleteMessage on proposal-system-jobs, workorder-shoc-emitter-failures
# and workorder-shoc-emitter-rejected, where the wildcard was a silent
# message-drain (data-loss) primitive against another tenant's pipeline.
# Verified denied 2026-07-30 with iam simulate-custom-policy.
# A prefix rather than four literals is deliberate, BUT the original
# justification for it was wrong and is corrected here: SAM does NOT
# auto-create or auto-name async DLQs — all four payments queues are
# hand-written AWS::SQS::Queue resources with explicit QueueNames, and
# OnFailure destinations take an explicit ARN. The real invariant is
# therefore a naming rule, not a framework behaviour: ANY queue a
# boundary-carrying function sends to — including async OnFailure
# destinations and DeadLetterQueue targets — must be named payments-*,
# or the boundary must be widened in the SAME PR. A denied destination
# write is SILENT: the async event is discarded with no caller to
# error, no Errors datapoint and no DLQ contents.
# sqs:ListQueues is absent and must stay absent (authorised against "*").
- Sid: SQS
Effect: Allow
Action:
- sqs:SendMessage
- sqs:ReceiveMessage
- sqs:DeleteMessage
- sqs:GetQueueAttributes
- sqs:GetQueueUrl
- sqs:ChangeMessageVisibility
Resource:
- !Sub "arn:aws:sqs:us-east-1:${AWS::AccountId}:payments-*"
# ── Lambda invocation — HIGHEST-LEVERAGE FIX IN THIS CHANGE ─────────
# function:* was a BOUNDARY-ESCAPE primitive, not merely lateral
# movement: an invoked function executes under ITS OWN execution role,
# and every non-SAM function in seahaven-prod (proposal-system-*,
# procurement-api, workorder-*, po-*) is CDK-deployed and carries NO
# permissions boundary at all. A bounded SAM Lambda could therefore reach,
# by proxy, capability this ceiling exists to deny. Verified 2026-07-30
# with iam simulate-custom-policy: proposal-system-api is now denied,
# payments-expenseProcessor still allowed.
# Scoped to the three workloads with enumerated inter-function calls:
# payments-dashboard (ExpenseReceiver -> ExpenseProcessor),
# meal-order-manager (submit-order -> slack-notifier, close-form ->
# aggregate-orders, plus AdminAuthorizerInvokeRole), and
# afterhours-shift-manager, whose boundary-carrying ReleaseNotifyInvokeRole
# and HolidaySchedulerExecutionRole exist solely to invoke.
# front-integrations and afi-backup-monitor have no enumerated invoke need
# and are deliberately absent. Prefixes (not literal function ARNs) are
# used because they also match the :<alias> / :<version> qualified form.
- Sid: LambdaInvoke
Effect: Allow
Action:
- lambda:InvokeFunction
Resource:
- !Sub "arn:aws:lambda:us-east-1:${AWS::AccountId}:function:afterhours-*"
- !Sub "arn:aws:lambda:us-east-1:${AWS::AccountId}:function:meal-order-manager-*"
- !Sub "arn:aws:lambda:us-east-1:${AWS::AccountId}:function:payments-*"
# ── SES — pinned to account inventory, NOT per-workload scoping ─────
# Labelled honestly: an SES identity is a shared DOMAIN, so no
# per-workload prefix exists to scope to. These are seahaven-prod's two
# verified identities (re-verified live 2026-07-30); seahaven-dev has
# none, so both entries are simply inert there. The win is bounded but
# real: identity/* would let the SAM fleet send as ANY identity ever added
# to the account, including a customer or partner domain, from a
# legitimately-authenticated sender. This cannot break anything that would
# otherwise work — sending from an unverified identity fails with
# MessageRejected regardless of IAM — so the failure mode is LOUD.
# configuration-set/* is DROPPED: zero configuration sets exist in prod or
# dev and no enumerated stack uses one.
# MIGRATION-BLOCKING QUESTION: mgmt additionally has seahavenind.com,
# apfacilities.org, adam@seahaven.com and payroll@seahaven.com verified;
# prod does NOT. Each migrating stack must confirm its actual Source
# address, verify that domain in the target account, and add the identity
# ARN here in the same PR.
# A ses:FromAddress condition would be stronger but is not available: the
# permission-source block names payroll@seahavenind.com, which is not a
# verified identity in prod — writing that condition would invent a scope.
# CORRECTION (2026-07-30 review): an earlier revision DROPPED
# configuration-set/* on the reasoning that zero configuration sets
# exist in prod or dev today. That test was the wrong one. SES
# authorizes SendEmail against the CONFIGURATION-SET resource in
# addition to the identity whenever the identity has a default
# configuration set, and afterhours-shift-manager/template.yaml:178-181
# grants exactly that ARN with an in-repo comment recording that
# omitting it DENIES the send. The correct question is not "does the
# resource exist in the target account yet" but "does an enumerated
# stack's own IAM policy name it". seahavenind.com is listed because
# meal-order-manager's SenderEmail parameter defaults to
# adam@seahavenind.com (meal-order-manager/template.yaml:20-22) and its
# email_report handler sends with that Source; the earlier "sending
# from an unverified identity fails loudly anyway" argument only holds
# until the migration verifies the domain, which the migration
# procedure itself requires.
- Sid: SES
Effect: Allow
Action:
- ses:SendEmail
- ses:SendRawEmail
Resource:
- !Sub "arn:aws:ses:us-east-1:${AWS::AccountId}:identity/int.seahaven.com"
- !Sub "arn:aws:ses:us-east-1:${AWS::AccountId}:identity/seahaven.com"
- !Sub "arn:aws:ses:us-east-1:${AWS::AccountId}:identity/seahavenind.com"
- !Sub "arn:aws:ses:us-east-1:${AWS::AccountId}:configuration-set/seahaven-email-events"
# ── EventBridge Scheduler (afterhours-shift-manager holiday routing) ─
# Omitted from the permission-source block entirely, which the block's
# "verified live" header did not catch. afterhours-shift-manager
# template.yaml:110-120 grants these three scheduler actions plus
# iam:PassRole on its holiday-scheduler execution role. Without them
# the failure is SILENT: src/slack-bot/app.py wraps create_schedule in
# a bare `except Exception`, so the Slack command returns success, the
# holiday record is written with no schedule, and no alarm fires.
- Sid: EventBridgeScheduler
Effect: Allow
Action:
- scheduler:CreateSchedule
- scheduler:DeleteSchedule
- scheduler:GetSchedule
Resource:
- !Sub "arn:aws:scheduler:us-east-1:${AWS::AccountId}:schedule/default/holiday-*"
# PassRole is confined to the scheduler service principal, so this
# cannot be used to hand a role to Lambda or any other service.
- Sid: SchedulerPassRole
Effect: Allow
Action:
- iam:PassRole
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/afterhours-shift-manager-*"
Condition:
StringEquals:
"iam:PassedToService": "scheduler.amazonaws.com"
# ── KMS — key/* RETAINED, scoped by condition instead ───────────────
# KMS is the one high-value data plane that CANNOT be scoped by resource
# name: key ARNs carry UUID key ids, not workload names, and alias ARNs
# are not valid in a Resource for these actions (alias scoping needs a
# kms:RequestAlias condition). The two key ids named in this statement's
# previous comment (key/0b660af3, key/b748750c) are MGMT keys that do not
# exist in seahaven-prod or seahaven-dev; hardcoding them — or prod's
# three live CMKs — would encode one account's inventory into a template
# shared by two, and would break on any key replacement.
# So Resource stays key/* and the scope is derived from kms:ViaService:
# the fleet may use a CMK ONLY as part of a request one of these services
# makes on its behalf. Decrypting a DynamoDB item or an S3 object still
# works; a direct kms:Decrypt on arbitrary ciphertext lifted from anywhere
# in the account is denied — the actual escalation path key/* opened.
# Because those services are themselves prefix-scoped above, the effective
# KMS scope INHERITS the per-workload scoping for free, with no key ids
# and no per-account parameterisation.
# logs.us-east-1.amazonaws.com is included as belt-and-braces: CloudWatch
# Logs is believed to decrypt log-group CMKs under its own service grant
# rather than the execution role's credentials, which would make this entry
# a no-op — but a KMS denial on the logging path would be SILENT, and the
# entry cannot grant anything meaningful on its own, so the insurance is
# bought deliberately.
# If a specific key must ever be named, use a kms:RequestAlias condition —
# never a literal key id.
- Sid: KMS
Effect: Allow
Action:
- kms:Decrypt
- kms:GenerateDataKey
- kms:DescribeKey
Resource:
- !Sub "arn:aws:kms:us-east-1:${AWS::AccountId}:key/*"
Condition:
StringEquals:
kms:ViaService:
- dynamodb.us-east-1.amazonaws.com
- logs.us-east-1.amazonaws.com
- s3.us-east-1.amazonaws.com
- secretsmanager.us-east-1.amazonaws.com
# REQUIRED for parity with SSMParameterRead above: a
# SecureString parameter decrypts via the SSM service
# principal, so omitting this denies reads that this same
# policy grants — a self-inconsistency caught by the
# 2026-07-30 review. Any ssm:GetParameter* grant in this
# boundary must keep this entry.
- ssm.us-east-1.amazonaws.com
- sqs.us-east-1.amazonaws.com
# ---------------------------------------------------------------------------
# Shared CloudFormation execution role (SAM stacks) — INFRA-97 scoped
#
# Replaces the previous blanket managed-policy set (IAMFullAccess +
# *FullAccess) with per-service inline statements that cover exactly
# what the five SAM stacks need during a CloudFormation deploy/update.
#
# PRIMARY ESCALATION CONTROL
# iam:CreateRole and iam:AttachRolePolicy / iam:PutRolePolicy are
# conditioned on iam:PermissionsBoundary StringEquals the boundary ARN
# (seahaven-lambda-execution-boundary, created in INFRA-103). That
# condition is what prevents the CFN execution role from minting an
# unconstrained admin role.
#
# SAM RolePath deviation note
# The original cross-review suggestion mentioned scoping IAM role
# creation to a specific path (/cfn-managed/). AWS::Serverless::Function
# does NOT support a custom RolePath on auto-generated execution roles —
# the PermissionsBoundary property is supported, but the role always lands
# at path /. Relying on a path condition (iam:ResourceTag or path-prefix)
# would therefore exclude the SAM auto-roles and break every deploy.
# The iam:PermissionsBoundary condition achieves the same security goal
# without requiring a path. For any explicit AWS::IAM::Role resources
# in SAM templates (e.g. AdminAuthorizerInvokeRole in meal-order-manager)
# where we can control the path, path scoping can be added in a follow-up.
#
# DEPLOY ORDER DEPENDENCY
# This role references the boundary ARN only as literal !Sub strings inside
# Condition values, so CloudFormation infers NO creation edge from the
# references alone. The explicit DependsOn below is what guarantees the
# boundary exists before the role on first create (IAM would otherwise
# accept the role, leaving a window where the role exists unbounded-gated
# against a not-yet-existing boundary policy).
# ---------------------------------------------------------------------------
SamCfnExecutionRole:
Type: AWS::IAM::Role
DependsOn: LambdaExecutionBoundary
Properties:
RoleName: github-cfn-execution-role
ManagedPolicyArns:
- !Ref SamCfnIamManagementPolicy
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: cloudformation.amazonaws.com
Action: sts:AssumeRole
Policies:
# ── CloudFormation transforms (SAM macro) ─────────────────────────
- PolicyName: cloudformation-transforms
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: AllowSAMTransform
Effect: Allow
Action:
- cloudformation:CreateChangeSet
Resource:
- arn:aws:cloudformation:us-east-1:aws:transform/*
# ── Lambda management ─────────────────────────────────────────────
# Covers function create/update/delete, aliases, event source
# mappings, and Lambda layers — all needed for SAM deploys.
- PolicyName: lambda-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: LambdaFunctions
Effect: Allow
Action:
- lambda:AddPermission
- lambda:CreateFunction
- lambda:DeleteFunction
- lambda:GetFunction
- lambda:GetFunctionConfiguration
- lambda:ListFunctions
- lambda:RemovePermission
- lambda:UpdateFunctionCode
- lambda:UpdateFunctionConfiguration
- lambda:UpdateFunctionEventInvokeConfig
- lambda:PutFunctionEventInvokeConfig
- lambda:DeleteFunctionEventInvokeConfig
- lambda:GetFunctionEventInvokeConfig
- lambda:ListTags
- lambda:TagResource
- lambda:UntagResource
- lambda:GetPolicy
- lambda:ListVersionsByFunction
- lambda:PublishVersion
- lambda:CreateAlias
- lambda:DeleteAlias
- lambda:UpdateAlias
- lambda:GetAlias
Resource:
- !Sub "arn:aws:lambda:us-east-1:${AWS::AccountId}:function:*"
- Sid: LambdaLayers
Effect: Allow
Action:
- lambda:PublishLayerVersion
- lambda:DeleteLayerVersion
- lambda:GetLayerVersion
- lambda:ListLayerVersions
- lambda:ListLayers
- lambda:AddLayerVersionPermission
- lambda:RemoveLayerVersionPermission
Resource:
- !Sub "arn:aws:lambda:us-east-1:${AWS::AccountId}:layer:*"
- Sid: LambdaEventSourceMappings
Effect: Allow
Action:
- lambda:CreateEventSourceMapping
- lambda:DeleteEventSourceMapping
- lambda:GetEventSourceMapping
- lambda:ListEventSourceMappings
- lambda:UpdateEventSourceMapping
Resource: "*"
# ── API Gateway (HTTP APIs + REST APIs) ───────────────────────────
- PolicyName: apigateway-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: ApiGateway
Effect: Allow
Action:
- apigateway:GET
- apigateway:POST
- apigateway:PUT
- apigateway:PATCH
- apigateway:DELETE
Resource:
- "arn:aws:apigateway:us-east-1::*"
# ── DynamoDB ──────────────────────────────────────────────────────
- PolicyName: dynamodb-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: DynamoDBTables
Effect: Allow
Action:
- dynamodb:CreateTable
- dynamodb:DeleteTable
- dynamodb:DescribeTable
- dynamodb:UpdateTable
- dynamodb:ListTables
- dynamodb:TagResource
- dynamodb:UntagResource
- dynamodb:DescribeTimeToLive
- dynamodb:UpdateTimeToLive
- dynamodb:DescribeContinuousBackups
- dynamodb:UpdateContinuousBackups
Resource:
- !Sub "arn:aws:dynamodb:us-east-1:${AWS::AccountId}:table/*"
# ── S3 ────────────────────────────────────────────────────────────
# Covers bucket create/configure + object operations for SAM
# artifact buckets and application buckets.
- PolicyName: s3-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: S3BucketOps
Effect: Allow
Action:
- s3:CreateBucket
- s3:DeleteBucket
- s3:GetBucketLocation
- s3:GetBucketPolicy
- s3:PutBucketPolicy
- s3:DeleteBucketPolicy
- s3:GetBucketTagging
- s3:PutBucketTagging
- s3:GetBucketVersioning
- s3:PutBucketVersioning
- s3:GetLifecycleConfiguration
- s3:PutLifecycleConfiguration
- s3:GetBucketPublicAccessBlock
- s3:PutBucketPublicAccessBlock
# Explicit BucketEncryption blocks (first: payments-dashboard
# BoaRawBucket, 2026-07-22) need the encryption config pair.
- s3:GetEncryptionConfiguration
- s3:PutEncryptionConfiguration
- s3:GetBucketNotification
- s3:PutBucketNotification
- s3:GetBucketWebsite
- s3:PutBucketWebsite
- s3:DeleteBucketWebsite
- s3:GetBucketAcl
- s3:PutBucketAcl
Resource:
- "arn:aws:s3:::*"
- Sid: S3ObjectOps
Effect: Allow
Action:
- s3:GetObject
- s3:PutObject
- s3:DeleteObject
- s3:ListBucket
- s3:ListBucketVersions
- s3:GetObjectVersion
Resource:
- "arn:aws:s3:::*"
- "arn:aws:s3:::*/*"
# ── CloudWatch Logs ───────────────────────────────────────────────
- PolicyName: cloudwatch-logs-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: CWLogs
Effect: Allow
Action:
- logs:CreateLogGroup
- logs:DeleteLogGroup
- logs:DescribeLogGroups
- logs:PutRetentionPolicy
- logs:DeleteRetentionPolicy
- logs:ListTagsLogGroup
- logs:TagLogGroup
- logs:UntagLogGroup
- logs:ListTagsForResource
- logs:TagResource
- logs:UntagResource
- logs:CreateLogDelivery
- logs:GetLogDelivery
- logs:UpdateLogDelivery
- logs:DeleteLogDelivery
- logs:ListLogDeliveries
- logs:PutResourcePolicy
- logs:DescribeResourcePolicies
- logs:PutDestination
- logs:DeleteDestination
- logs:DescribeDestinations
- logs:AssociateKmsKey
- logs:DisassociateKmsKey
# Ported from the mgmt copy (Phase A): afterhours-shift-manager
# creates an AWS::Logs::MetricFilter through this role, so a
# SAM stack migrating here fails mid-deploy without these.
- logs:PutMetricFilter
- logs:DeleteMetricFilter
- logs:DescribeMetricFilters
Resource: "*"
# ── EventBridge / CloudWatch Events (scheduled Lambdas) ───────────
- PolicyName: eventbridge-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: EventBridge
Effect: Allow
Action:
- events:DeleteRule
- events:DescribeRule
- events:EnableRule
- events:DisableRule
- events:ListRules
- events:ListTargetsByRule
- events:PutRule
- events:PutTargets
- events:RemoveTargets
- events:TagResource
- events:UntagResource
- events:ListTagsForResource
- events:PutPermission
- events:RemovePermission
Resource: "*"
# ── SES (afterhours weekly-post, meal-order email-report) ─────────
- PolicyName: ses-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: SESRules
Effect: Allow
Action:
- ses:CreateReceiptRule
- ses:DeleteReceiptRule
- ses:DescribeReceiptRule
- ses:UpdateReceiptRule
- ses:CreateReceiptRuleSet
- ses:DescribeActiveReceiptRuleSet
- ses:DescribeReceiptRuleSet
- ses:SetActiveReceiptRuleSet
- ses:ReorderReceiptRuleSet
- ses:GetIdentityVerificationAttributes
- ses:ListIdentities
Resource: "*"
# ── SQS (payments-dashboard queues + DLQs) ────────────────────────
- PolicyName: sqs-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: SQSQueues
Effect: Allow
Action:
- sqs:CreateQueue
- sqs:DeleteQueue
- sqs:GetQueueAttributes
- sqs:SetQueueAttributes
- sqs:GetQueueUrl
- sqs:ListQueues
- sqs:TagQueue
- sqs:UntagQueue
- sqs:ListQueueTags
- sqs:AddPermission
- sqs:RemovePermission
Resource:
- !Sub "arn:aws:sqs:us-east-1:${AWS::AccountId}:*"
# ── SNS (validation / alarm notifications) ────────────────────────
- PolicyName: sns-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: SNS
Effect: Allow
Action:
- sns:CreateTopic
- sns:DeleteTopic
- sns:GetTopicAttributes
- sns:SetTopicAttributes
- sns:Subscribe
- sns:Unsubscribe
- sns:ListSubscriptionsByTopic
- sns:ListTopics
- sns:TagResource
- sns:UntagResource
Resource:
- !Sub "arn:aws:sns:us-east-1:${AWS::AccountId}:*"
# ── CloudWatch Alarms ─────────────────────────────────────────────
- PolicyName: cloudwatch-alarms-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: CWAlarms
Effect: Allow
Action:
- cloudwatch:PutMetricAlarm
- cloudwatch:DeleteAlarms
- cloudwatch:DescribeAlarms
- cloudwatch:EnableAlarmActions
- cloudwatch:DisableAlarmActions
- cloudwatch:ListTagsForResource
- cloudwatch:TagResource
- cloudwatch:UntagResource
Resource: "*"
# ── EC2 / VPC / NAT / EIP / Security Groups ───────────────────────
# payments-dashboard deploys a VPC, NAT gateway, EIP, route tables,
# subnets, security groups, and gateway VPC endpoints.
- PolicyName: ec2-vpc-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: EC2VPC
Effect: Allow
Action:
- ec2:AllocateAddress
- ec2:AssociateRouteTable
- ec2:AttachInternetGateway
- ec2:AuthorizeSecurityGroupEgress
- ec2:AuthorizeSecurityGroupIngress
- ec2:CreateInternetGateway
- ec2:CreateNatGateway
- ec2:CreateRoute
- ec2:CreateRouteTable
- ec2:CreateSecurityGroup
- ec2:CreateSubnet
- ec2:CreateVpc
- ec2:CreateVpcEndpoint
- ec2:CreateTags
- ec2:DeleteInternetGateway
- ec2:DeleteNatGateway
- ec2:DeleteRoute
- ec2:DeleteRouteTable
- ec2:DeleteSecurityGroup
- ec2:DeleteSubnet
- ec2:DeleteVpc
- ec2:DeleteVpcEndpoints
- ec2:DescribeAddresses
- ec2:DescribeAvailabilityZones
- ec2:DescribeInternetGateways
- ec2:DescribeNatGateways
- ec2:DescribeRouteTables
- ec2:DescribeSecurityGroups
- ec2:DescribeSubnets
- ec2:DescribeVpcEndpoints
- ec2:DescribeVpcs
- ec2:DescribePrefixLists
- ec2:DetachInternetGateway
- ec2:DisassociateAddress
- ec2:DisassociateRouteTable
- ec2:ModifySubnetAttribute
- ec2:ModifyVpcAttribute
- ec2:ModifyVpcEndpoint
- ec2:ReleaseAddress
- ec2:RevokeSecurityGroupEgress
- ec2:RevokeSecurityGroupIngress
- ec2:UpdateSecurityGroupRuleDescriptionsEgress
- ec2:UpdateSecurityGroupRuleDescriptionsIngress
Resource: "*"
# ── CloudFront + OAC (meal-order-manager form distribution) ───────
- PolicyName: cloudfront-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: CloudFront
Effect: Allow
Action:
- cloudfront:CreateDistribution
- cloudfront:DeleteDistribution
- cloudfront:GetDistribution
- cloudfront:GetDistributionConfig
- cloudfront:UpdateDistribution
- cloudfront:TagResource
- cloudfront:UntagResource
- cloudfront:ListTagsForResource
- cloudfront:CreateOriginAccessControl
- cloudfront:DeleteOriginAccessControl
- cloudfront:GetOriginAccessControl
- cloudfront:GetOriginAccessControlConfig
- cloudfront:UpdateOriginAccessControl
- cloudfront:ListOriginAccessControls
- cloudfront:CreateInvalidation
- cloudfront:GetInvalidation
Resource: "*"
# ── SSM Parameter Store (meal-order-manager, afterhours) ──────────
# Write is needed because meal-order-manager creates
# /meal-order-manager/slack-channel-id via AWS::SSM::Parameter.
- PolicyName: ssm-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: SSMParameters
Effect: Allow
Action:
- ssm:GetParameter
- ssm:GetParameters
- ssm:GetParametersByPath
- ssm:PutParameter
- ssm:DeleteParameter
- ssm:DeleteParameters
- ssm:DescribeParameters
- ssm:AddTagsToResource
- ssm:RemoveTagsFromResource
- ssm:ListTagsForResource
Resource:
- !Sub "arn:aws:ssm:us-east-1:${AWS::AccountId}:parameter/*"
# WAF association needs SSM parameter read at deploy time
# (/seahaven/waf/app-web-acl-arn value lookup)
- Sid: SSMParameterDescribe
Effect: Allow
Action:
- ssm:DescribeParameters
Resource: "*"
# ── WAF (meal-order-manager CloudFront WebACL association) ────────
- PolicyName: waf-management
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: WAF
Effect: Allow
Action:
- wafv2:GetWebACL
- wafv2:GetWebACLForResource
- wafv2:ListWebACLs
- wafv2:AssociateWebACL
- wafv2:DisassociateWebACL
- wafv2:ListResourcesForWebACL
Resource: "*"
# ---------------------------------------------------------------------------
# IAM role lifecycle - BOUNDARY-GATED (attached managed policy)
#
# Lives in a MANAGED policy, not inline on the role, because the role's
# inline policies total ~10.1 KB against IAM's hard 10,240-byte per-role
# inline limit - adding the Deny statements below inline exceeds it and
# fails the deploy (ServiceLimitExceeded, hit live 2026-07-27). Attached
# managed policies have their own separate 6,144-byte budget, so moving this
# block out both fits the Denies and leaves ~1.9 KB of inline headroom for
# future statements. Identity policies are unioned and an explicit Deny still
# wins, so effective permissions are unchanged by the relocation.
#
# This is the PRIMARY escalation control for INFRA-97.
#
# iam:CreateRole / iam:AttachRolePolicy / iam:PutRolePolicy are
# conditioned on iam:PermissionsBoundary StringEquals the
# seahaven-lambda-execution-boundary ARN. That condition means
# any role this execution role creates must have the boundary
# applied, so it can never exceed what the boundary allows
# (which is scoped to the services the five stacks actually use).
#
# iam:PassRole is also included here so CloudFormation can pass
# the auto-generated Lambda execution role to the Lambda service.
#
# Why not path-scoped (e.g. iam:ResourceTag / path /cfn-managed/)?
# SAM's AWS::Serverless::Function auto-generates execution roles at
# path / — there is no supported way to set a custom RolePath on
# SAM auto-roles. A path condition would therefore exclude the
# SAM auto-roles and break every deploy. The PermissionsBoundary
# condition achieves the same security goal without a path requirement.
# ---------------------------------------------------------------------------
SamCfnIamManagementPolicy:
Type: AWS::IAM::ManagedPolicy
Properties:
# Fixed name: changing it makes CloudFormation create a replacement policy
# and detach this one, which briefly drops the role's IAM permissions
# mid-update. Treat a rename as a coordinated migration, not an edit. This
# is the role's FIRST attached managed policy (per-role quota is 10).
ManagedPolicyName: seahaven-cfn-exec-iam-management
Description: >-
Boundary-gated IAM role lifecycle for github-cfn-execution-role, plus the
explicit Deny backstops that keep the permissions boundary from being
detached or rewritten. Separated from the role's inline policies to stay
under IAM's 10,240-byte inline limit.
PolicyDocument:
Version: "2012-10-17"
Statement:
# Create role — MUST attach boundary
- Sid: IAMCreateRoleWithBoundary
Effect: Allow
Action:
- iam:CreateRole
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
Condition:
StringEquals:
"iam:PermissionsBoundary": !Sub "arn:aws:iam::${AWS::AccountId}:policy/seahaven-lambda-execution-boundary"
# Attach managed policies — MUST have boundary already on role
- Sid: IAMAttachPolicyWithBoundary
Effect: Allow
Action:
- iam:AttachRolePolicy
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
Condition:
StringEquals:
"iam:PermissionsBoundary": !Sub "arn:aws:iam::${AWS::AccountId}:policy/seahaven-lambda-execution-boundary"
# Put inline policy — MUST have boundary already on role
- Sid: IAMPutRolePolicyWithBoundary
Effect: Allow
Action:
- iam:PutRolePolicy
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
Condition:
StringEquals:
"iam:PermissionsBoundary": !Sub "arn:aws:iam::${AWS::AccountId}:policy/seahaven-lambda-execution-boundary"
# Boundary management — SET the boundary only. DELETE is NOT
# granted: for a delete, the iam:PermissionsBoundary condition key
# reflects the boundary CURRENTLY attached to the target role, so
# a StringEquals condition on the boundary ARN MATCHES exactly the
# roles the gate protects. Granting delete under that condition
# lets this role create a boundary-gated role with an inline *:*
# policy, strip the boundary, and pass the now-unbounded role to
# Lambda — defeating the primary escalation control. Verified live
# against the mgmt copy 2026-07-27 (simulate-principal-policy:
# iam:DeleteRolePermissionsBoundary = allowed). SAM never needs
# the delete: it only SETS the boundary on roles it creates, and
# stack teardown calls DeleteRole, not DeleteRolePermissionsBoundary.
- Sid: IAMPutPermissionsBoundary
Effect: Allow
Action:
- iam:PutRolePermissionsBoundary
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
Condition:
StringEquals:
"iam:PermissionsBoundary": !Sub "arn:aws:iam::${AWS::AccountId}:policy/seahaven-lambda-execution-boundary"
# Explicit Deny backstop (AWS's documented NoBoundaryPolicyEdit /
# NoBoundaryDelete delegation pattern). A Deny is required, not
# merely omitting the Allow: without it, any future Allow added to
# this role — or a broader managed policy attached to it — silently
# reopens the escalation. Covers both removing a boundary from a
# role and rewriting the boundary POLICY DOCUMENT itself (the
# latter is only implicitly denied today).
- Sid: DenyBoundaryTampering
Effect: Deny
Action:
- iam:DeleteRolePermissionsBoundary
- iam:DeleteUserPermissionsBoundary
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
- !Sub "arn:aws:iam::${AWS::AccountId}:user/*"
# Scoped to the whole seahaven-* policy family, not just the boundary:
# this policy carries the Deny statements, so it is now a
# higher-value target than the boundary it protects. Safe to scope
# broadly — the role holds no iam:CreatePolicy anywhere and no SAM
# stack manages a managed policy through it (both verified
# 2026-07-27), so nothing legitimate writes policy versions here.
- Sid: DenyBoundaryPolicyEdit
Effect: Deny
Action:
- iam:CreatePolicyVersion
- iam:SetDefaultPolicyVersion
- iam:DeletePolicyVersion
- iam:DeletePolicy
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:policy/seahaven-*"
# Self-protection. Without this the whole control is one API call
# from being undone: IAMRoleReadAndDelete below grants
# iam:DetachRolePolicy on Resource "*" with no condition, so this
# role could detach the very policy carrying these Denies from
# itself and reinstate the escalation. Verified live 2026-07-27:
# simulate-principal-policy returned "allowed" for DetachRolePolicy,
# DeleteRolePolicy and DeleteRole against this role's own ARN and
# against githubdeploy-* roles.
#
# Also closes a denial-of-service and a self-elevation precondition:
# iam:PutRolePermissionsBoundary is condition-pinned to the Lambda
# boundary ARN but NOT scoped by target, so this role could apply
# that runtime boundary to itself or to a githubdeploy-* role —
# bricking the pipelines, unrecoverable without an admin because
# removing a boundary is denied above, and making the otherwise-inert
# AttachRolePolicy/PutRolePolicy self-elevation conditions start
# matching.
#
# Costs nothing operationally: this role is only ever passed to
# CloudFormation for SAM application stacks. The substrate's own
# roles are managed by THIS stack (deployed through the CDK
# bootstrap execution role), and per-repo githubdeploy-* roles are
# provisioned at onboarding time outside any stack this role
# executes — so CloudFormation never exercises these actions
# against them as this role. SAM-generated roles are named
# <stack>-<Function>Role-<hash> and are unaffected.
- Sid: DenySelfMutation
Effect: Deny
Action:
- iam:AttachRolePolicy
- iam:DeleteRole
- iam:DeleteRolePolicy
- iam:DeleteRolePermissionsBoundary
- iam:DetachRolePolicy
- iam:PutRolePolicy
- iam:PutRolePermissionsBoundary
- iam:UpdateAssumeRolePolicy
- iam:UpdateRole
- iam:UpdateRoleDescription
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/github-cfn-execution-role"
- !Sub "arn:aws:iam::${AWS::AccountId}:role/githubdeploy-*"
# Read / tag / delete role and policy — no boundary condition needed
- Sid: IAMRoleReadAndDelete
Effect: Allow
Action:
- iam:DeleteRole
- iam:DeleteRolePolicy
- iam:DetachRolePolicy
- iam:GetRole
- iam:GetRolePolicy
- iam:ListAttachedRolePolicies
- iam:ListRolePolicies
- iam:ListRoles
- iam:TagRole
- iam:UntagRole
- iam:UpdateRole
- iam:UpdateRoleDescription
- iam:UpdateAssumeRolePolicy
- iam:GetPolicy
- iam:GetPolicyVersion
- iam:ListPolicies
- iam:ListPolicyVersions
Resource: "*"
# PassRole — CloudFormation passes the Lambda execution role
# to the Lambda service. Scoped to SAM-generated role pattern.
- Sid: IAMPassRole
Effect: Allow
Action:
- iam:PassRole
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:role/*"
Condition:
StringEquals:
"iam:PassedToService": "lambda.amazonaws.com"
Reference in a new issue View git blame Copy permalink