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 at parity on # their IAM STATEMENT SETS across the two files and MUST still be changed # together. Parity covers statements, not surrounding comments — a comment # may diverge where it describes boundary content, which now differs # between the files. The only functional 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 per-workload data-plane statement was REMOVED from # LambdaExecutionBoundary in this file, leaving only the fleet-wide floor: # CloudWatchLogsWrite (scoped to /aws/lambda*), CloudWatchLogsDescribe, # XRay and Ec2Eni. The account-wide wildcards mgmt still carries — table/*, # table/*/index/*, secret:*, parameter/*, sqs :*, function:*, ses # identity/* + configuration-set/*, kms key/*, and an s3:::*- # pattern that was a bare name-suffix filter rather than an ownership # check — are simply GONE here rather than re-scoped. # The security win is the deletion: it is what closes the amplifier whereby # a principal able to write an inline policy onto a boundary-carrying role # could read every secret in the account. Per-workload prefixes add no # security — they only keep a workload functional — so they are added by # each migration PR, from that stack's own template, when the stack # actually lands. See the note on the boundary resource for the full # rationale and the six errors that the pre-loaded approach produced. # # 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 691 characters across # 4 statements as of 2026-07-31 — the fleet-wide floor only. 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 twice inside this branch alone). # # Headroom is 5,453 characters, roughly TWELVE workloads at ~450 each. That is a # deliberate outcome, not luck: an earlier revision of this branch pre-loaded # per-workload prefixes for all five mgmt SAM stacks and reached 5,457 characters # with 687 left — about one workload of room — before any stack had actually # migrated. Deferring per-workload scope to each migration PR (see the note on # the boundary itself) removed that pressure entirely. If the budget tightens # again as workloads land, the end-state fix is per-workload boundaries # (seahaven-lambda-execution-boundary-), which also resolves the # shared-ceiling residual — tracked as INFRA-187, do not improvise it. # 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 the FLEET-WIDE FLOOR # ONLY: what every Lambda execution role needs regardless of workload. It # carries NO per-workload data-plane statements — each migrating stack adds its # own, from its own template, in its own PR (see the note on the boundary # resource and the WIDENING PATH below). 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. # # Every "verified " annotation in this file is a POINT-IN-TIME # observation, not live state. Re-validate (usage counts, log-group CMK state, # per-stack permission sources) before citing one as justification for a # future change. # # 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: # 0. PRECONDITION — check the managed-policy VERSION budget BEFORE merging: # max 5 versions, both # accounts are on v1 today. Every widening (PolicyDocument edit) burns # one. Description, ManagedPolicyName and Path are REPLACEMENT # properties per the CFN resource reference — CloudFormation cannot # replace a custom-named policy, so a Description-only edit FAILS the # stack update, and the error's suggested remedy (rename) is exactly # the forbidden rename in the COUPLING note above. Never edit those # three properties. Delete the oldest non-default version if at 5: # aws iam list-policy-versions --policy-arn \ # arn:aws:iam:::policy/seahaven-lambda-execution-boundary # aws iam delete-policy-version --version-id v ... # 1. Derive the workload's needs from ITS OWN TEMPLATE — open the stack's # template.yaml and read the actual IAM policy statements. The # permission-source block below is a STARTING POINT, NOT THE AUTHORITY: # the /sh-security-review pass on 2026-07-30 found SIX places where it was # incomplete or simply invented a resource name, three of which would have # failed silently. Update that block in the same edit with what you find. # 2. Add the workload's statements. Group by service so a second workload can # extend a Resource list rather than duplicate an action list (~250 # characters for zero new actions; an extra ARN costs ~60). Check for the # SILENT classes specifically: a denied SQS destination/DLQ write discards # the async event with no error and no alarm; a denied scheduler call may # sit behind a bare except; a denied KMS decrypt for env-var encryption # fails at cold-start INIT; any CMK-encrypted resource needs the # matching kms:ViaService principal, not just the kms action; and a # function using LoggingConfig with a custom log-group name outside # /aws/lambda* silently loses ALL logs — add a scoped logs statement # for the custom group or keep the default group name. # 3. Measure. See SIZE BUDGET in the header. There is NO escape hatch. # 4. 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. # 5. Merge and let CI deploy deploy-substrate-prod / deploy-substrate-dev to # UPDATE_COMPLETE, THEN deploy the workload stack. # 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 reduced to the fleet-wide floor 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 a # SECONDARY RECORD and a starting point for widening PRs — the authority is # each stack's own template (WIDENING PATH step 1). No Resource pattern in # the floor above derives from this block. # # Permission sources per stack (verified live 2026-07-30; starting point # only — verify every entry against the owning repo before use): # # 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/, 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. # REGION IS PINNED TO us-east-1 DELIBERATELY: every Sea Haven workload # deploys to us-east-1, and this template itself only ever deploys there. # ${AWS::Region} would resolve to the identical string, so it would # document nothing. A future stack in another region carries this # boundary but CANNOT write its logs (the silent class above) — so a # cross-region migration MUST add region-scoped statements in its # widening PR, same as any other data-plane need. - 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) ──────── # Derived from AWSLambdaVPCAccessExecutionRole, NOT an exact match: # DescribeSecurityGroups and DescribeVpcs exceed that managed policy # (kept for CFN/SAM VpcConfig validation; read-only). The four # 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; tracked # as INFRA-200): # 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 SET OF # VPCs that boundary-carrying Lambdas attach to — not a single VPC id; # the list must be extended whenever a workload introduces a new VPC # (tag-based conditions are the alternative if the set churns). No such # VPC exists 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 first 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: "*" # ── NO PER-WORKLOAD DATA-PLANE STATEMENTS — BY DESIGN ─────────────── # The statements above are the FLEET-WIDE FLOOR: what every Lambda # execution role needs regardless of which workload it belongs to. # There are deliberately NO DynamoDB, S3, Secrets Manager, SSM, SQS, # SES, KMS, lambda:InvokeFunction or scheduler statements here. # # WHY (decided 2026-07-30, Adam): # The security win of INFRA-186 comes from DELETION, not enumeration. # Removing the account-wide secret:*, table/*, function:* and sqs:* # wildcards is what closes the amplifier — the ability of a principal # who can write an inline policy onto a boundary-carrying role to read # every secret in the account. Per-workload prefixes add no security; # they exist only to keep a workload FUNCTIONAL once it arrives. # # An earlier revision of this branch PRE-LOADED prefixes for all five # mgmt SAM stacks before any of them had migrated. That required # predicting five stacks' permission needs from the permission-source # comment block above, and the /sh-security-review pass found SIX # errors in the result — three of which would have failed SILENTLY at # first migration (afterhours' SES config-set, its holiday scheduler # behind a bare except, and afi's webhook secret under an invented # name). The block is a secondary record and is not a substitute for # reading the owning repo's template. # # WIDENING IS THE SAFE DIRECTION. Adding a resource to a boundary can # never break a running Lambda; only tightening can. So there is no # cost to deferring per-workload scope to the migration PR that has # the real template open in front of it — and a large cost to # guessing it years ahead of the migration. # # CONSEQUENCE FOR EVERY MIGRATION PR (mandatory, see WIDENING PATH in # the header): a stack landing in prod or dev MUST add its own # data-plane statements here, derived from ITS OWN template, in its # own PR to THIS repo, deployed to UPDATE_COMPLETE before the # workload's first deploy from its own repo (the workload PR and the # widening PR cannot be the same PR — they live in different repos). # Without them its Lambdas get AccessDenied # at first invoke. The permission-source block above is the starting # point, NOT the authority — verify every entry against the stack. # # Prod/dev boundary usage is 0 (verified 2026-07-30), so this floor # currently constrains nothing that exists. Fleet-wide statements that # genuinely cannot be scoped (Logs, X-Ray, ENI) stay above with their # justifications; they are also the SILENT-failure classes, which is # why they belong in the floor rather than in per-workload widenings. # # KMS is absent deliberately: zero boundary-carrying roles exist, so # nothing bounded decrypts anything yet. (Log-group CMKs are the one # KMS case that never hits an execution role — CloudWatch Logs # decrypts via the key policy's grant to the Logs service principal — # so log-group CMK state is not the gate here. seahaven-prod already # hosts the seahaven-dynamodb-cmk table key; the first migrating # stack touching that table must cover it.) A workload bringing a # CMK-encrypted resource adds a KMS statement with the matching # kms:ViaService principal in its own migration PR — a missing # ViaService entry denies, and for env-var encryption it fails at # cold-start INIT. # # The end-state fix for the shared-ceiling residual (one boundary = # every SAM workload reaches every other's data plane once they land) # is per-workload boundaries — tracked as INFRA-187. Do not improvise # it: the load-bearing problem there is that both guardrail policies # pin ONE literal boundary ARN inside StringEquals conditions, and # loosening that to a wildcard weakens the gate. # --------------------------------------------------------------------------- # 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 (in # THIS file the fleet-wide floor plus per-migration widenings; # in mgmt's copy the five SAM stacks' service wildcards). # # 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"