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:::*- 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:::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 4,060 characters across # 13 statements as of 2026-07-30 (was 2,507 across 11 — TIGHTENING COSTS # CHARACTERS). Measure before widening — # len(json.dumps(doc,separators=(',',':'))) on the synthesized PolicyDocument with # ${AWS::AccountId} resolved. A typical new workload costs ~450 characters, so # roughly five more fit. 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:::*- 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/*) # - ssm:GetParameter (/afterhours-shift-manager/*: channel-id, # slack-bot-token, slack-signing-secret) # - ses:SendEmail (SES identity) # - 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 ONLY (seahaven-payments-csv-*, seahaven-payments-boa-raw-*, # seahaven-payroll-emails-*) — no write intent enumerated # - 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 (afi-backup-monitor/slack-webhook-url AND # the bare, unprefixed afi-api-key — see the SecretsManager statement) # - 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/, and the trailing * also covers the # :log-stream: 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/ (and /aws/lambda//), 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::log-stream:) 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 - 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 / 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 # / 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-*" - !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: SAM auto-names async # DLQs from the function name, so a new payments-* function's DLQ is # covered without a boundary edit. # 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 : / : 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. - 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" # ── 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 # -Role- 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"