Phase A moved the CFN execution role's boundary-gated IAM statements into
the attached seahaven-cfn-exec-iam-management managed policy, with the
escalation fixed and three Deny backstops, while deliberately leaving the
old inline iam-role-management-boundary-gated policy in place so that
deploy removed nothing. That is now redundant and this removes it.
Effective permissions are unchanged, proven statically before deploying:
of the 6 Allow statements being removed, 5 are byte-identical to the
managed policy's. The only difference is Sid IAMPutPermissionsBoundary,
where the inline copy also listed iam:DeleteRolePermissionsBoundary --
the action DenyBoundaryTampering explicitly denies, so that Allow was
already inert.
Frees the scarce budget: inline usage drops from 10,006 to 8,261 of IAM's
10,240-byte per-role limit, leaving 1,979 bytes of headroom on a role that
previously had 234.
The shared CloudFormation execution role could remove the permissions
boundary from the very roles that boundary was gating. Its
iam-role-management-boundary-gated policy allows
iam:DeleteRolePermissionsBoundary on role/* under a StringEquals
condition on iam:PermissionsBoundary -- and for a delete that condition
key reflects the boundary CURRENTLY attached to the target role, so it
matches exactly the roles the gate protects. Create a boundary-gated
role with an inline *:* policy, strip its boundary, PassRole it to
Lambda, and the result is unbounded admin in the management account.
Confirmed live with simulate-principal-policy, not inferred.
Phase A adds an attached managed policy, seahaven-cfn-exec-iam-management,
carrying the corrected statement set: the boundary-gated Allows without
iam:DeleteRolePermissionsBoundary, plus three Deny backstops --
DenyBoundaryTampering (boundary removal), DenyBoundaryPolicyEdit
(rewriting a seahaven-* policy document) and DenySelfMutation.
DenySelfMutation exists because the first draft of this fix was not
durable: the role holds iam:DetachRolePolicy, iam:DeleteRolePolicy and
iam:DeleteRole on Resource "*" with no condition, so it could detach the
Deny-carrying policy from itself in one call and reinstate the
escalation. It now cannot modify its own role, any githubdeploy-* role,
or any seahaven-* policy. Nothing legitimate needs that: the deploy
substrate's own principals are owned by this stack, which is deployed
manually with administrator credentials rather than through this role.
The change is additive. The old inline policy stays in place, so
CloudFormation removes nothing and there is no window in which the role
lacks its IAM permissions -- an explicit Deny beats an Allow anywhere in
the policy set, so the corrected version governs from the moment this
lands. Phase B removes the redundant inline copy. The split is also
required by size: inline sits at 10,006 of IAM's 10,240-byte per-role
limit, and the Deny statements do not fit there.
Also reconciles drift. The deployed role carries three logs:*MetricFilter
actions added out-of-band on 2026-06-29 and never back-ported.
afterhours-shift-manager creates an AWS::Logs::MetricFilter through this
role, so they are load-bearing; the template now matches the live policy
exactly, which keeps inline at 10,006 and stops a future write-back from
silently stripping them.
Removes the SeahavenSlackBotDeployRole resource block. Step 1 recorded
DeletionPolicy/UpdateReplacePolicy Retain in the deployed template, so
CloudFormation stops managing the resource without issuing DeleteRole
against a role that no longer exists -- confirmed from the change set,
which reports PolicyAction: Retain on a single Remove entry.
seahaven-slack-bot was decommissioned in favour of sh-mcp and the role
was deleted directly in IAM on 2026-07-23. The stack is now consistent
with reality again, and stack updates no longer fail on it.
seahaven-slack-bot was retired in favour of sh-mcp and its deploy role was
deleted directly in IAM on 2026-07-23, leaving the stack holding a
resource that no longer exists. The Outputs section resolved
!GetAtt SeahavenSlackBotDeployRole.Arn as a LIVE IAM read at the end of
every update, so the role's absence failed the whole thing:
Unable to retrieve Arn attribute for AWS::IAM::Role, with error message
The role with name githubdeploy-seahaven-slack-bot cannot be found. (404)
This is latent and invisible: the resource definition is unchanged, so it
produces no change-set entry, and change sets do not preview Outputs
resolution. A clean change set was not evidence the update would succeed.
It surfaced when the Phase A boundary-Deny change failed on it.
Step 1 of two. Removes the Output so updates stop resolving the ghost, and
records DeletionPolicy/UpdateReplacePolicy Retain so that step 2 can drop
the resource without CloudFormation issuing DeleteRole against a role that
is not there. Verified from the change set that this step touches only
DeletionPolicy and UpdateReplacePolicy -- metadata, requiresRecreation
Never -- so no IAM call is made against the missing role.
Nothing imported the Output: it had no ExportName, and no stack imports
any export from this stack.
Step 2 deletes the resource block itself.
payments-dashboard's BoaRawBucket (first bucket in the org with an
explicit BucketEncryption block) failed CREATE: the CFN execution
role lacked s3:PutEncryptionConfiguration. Adds the Get/Put pair to
the shared s3-management statement (bucket-level, existing * scope).
Escalation review: the role holds no kms:* actions anywhere, so the
PutEncryptionConfiguration + PutBucketPolicy combination cannot pivot
to a role-controlled KMS key; SCPs permit the action (the original
denial was identity-policy). GPT-4.1 cross-family review: FIX-level
only, dispositioned above. Stack deployed before merge per README.
Refs: payments-dashboard#76
Post-rename deploy verified green from seahaven-org-baseline (run
29355616637, both account jobs). The freed repo name must not stay
trusted (namespace-reuse window, security review IAC-02).
* Add stacks input to cd-cdk for multi-account apps
cdk deploy was hardcoded to --all, which breaks when one CDK app defines
stacks for two AWS accounts: whichever role the job assumed fails on the
other account's stacks. Callers can now pass per-job stack selectors;
default stays --all so existing callers are unaffected.
* Trust seahaven-org-baseline sub on account-baseline deploy role
Transition pair for the repo rename: OIDC sub claims carry the repo full
name, so the renamed repo cannot assume the role until its sub is
trusted. Old sub is removed after a post-rename deploy verifies green.
* Pass stacks selector via env var, not expression interpolation
Defense-in-depth from the security review: expression interpolation
into run: is pre-shell text substitution, so metacharacters in the
input would execute as script. Env-var expansion never re-parses shell
syntax; word-splitting for multiple selectors is preserved.
The CFN execution role held IAMFullAccess + seven *FullAccess managed
policies, giving it unconstrained AWS admin access. This replaces all
of those with per-service inline statements covering exactly what the
five SAM stacks require during a CloudFormation deploy.
PRIMARY ESCALATION CONTROL: iam:CreateRole, iam:AttachRolePolicy, and
iam:PutRolePolicy are now conditioned on iam:PermissionsBoundary
StringEquals the seahaven-lambda-execution-boundary ARN. Any role the
CFN execution role creates must carry that boundary, capping its
effective permissions at the boundary's ceiling.
SAM RolePath note: AWS::Serverless::Function does not support a custom
RolePath on auto-generated execution roles. Path scoping (e.g.
/cfn-managed/) cannot be used as the escalation guard for SAM auto-roles.
The iam:PermissionsBoundary condition achieves the same security goal.
DEPLOY ORDER DEPENDENCY: the seahaven-lambda-execution-boundary policy
(INFRA-103, PR #45) MUST exist before this stack is deployed. See the
PR description for the mandatory three-step deploy sequence.
Refs: INFRA-97
* Add seahaven-lambda-execution-boundary managed policy
Lambda execution roles auto-generated by SAM have no ceiling today —
a misconfigured Policies block could grant excessive permissions that
persist at runtime. This boundary caps every SAM function execution
role at the union of what the five stacks actually need, so the
effective permissions are always the intersection of the role's own
policies and this document.
The policy is a deliberate superset rather than exact-minimum: being
slightly broad is safer than a boundary that breaks functions at
runtime. Per-service scoping will tighten in follow-up work.
SAM template agents: add
PermissionsBoundary: arn:aws:iam::328440206208:policy/seahaven-lambda-execution-boundary
to Globals.Function in all five stacks after this stack deploys.
Refs: INFRA-103
* Fix boundary gaps found in GPT-4.1 cross-review
Three issues from the mandatory IAM cross-review (BLOCK/FIX):
1. Add KMS statement — PaymentsDashboard DynamoDB table and
payments-dashboard CloudWatch log groups use CMKs. Without
kms:Decrypt + kms:GenerateDataKey in the boundary, those Lambda
calls fail at the KMS layer at runtime. Scoped to account keys only.
2. Add table/*/index/* to DynamoDB resource — dynamodb:Query on a GSI
requires the index ARN; covering only table/* silently denied GSI
queries at the boundary.
3. Fix EC2 ENI statement — remove AssignPrivateIpAddresses /
UnassignPrivateIpAddresses (EFA-only, not part of Lambda ENI
lifecycle); add DescribeSubnets + DescribeSecurityGroups + DescribeVpcs
which are required by the Lambda service during VPC attachment and are
present in AWSLambdaVPCAccessExecutionRole.
4. Add SES configuration-set/* resource — ses:SendRawEmail requires
permission on the configuration set if one is passed at send time.
Refs: INFRA-103
Adds read + (dis)associate wafv2 actions so SAM/CFN deploys can attach the shared
seahaven-app-waf CloudFront WebACL to app distributions (meal-order orders).
Without it, the WebACL association fails 'Unable to verify read permissions on
Web ACL'. IAM cross-reviewed (no BLOCK). Not wafv2:* — scoped to read +
associate. Same manual-changeset deploy path as the H-16 change.
- New githubdeploy-seahaven-account-baseline OIDC role (CDK pattern: assumes
cdk-hnb659fds-*, scoped to the repo's main branch). Wires CD for the shared
account-baseline repo (CloudTrail C-1 + AWS Backup C-7).
- Codify cloudfront:* and ssm:* on github-cfn-execution-role to reconcile
out-of-band drift (audit H-16). These are needed by live SAM deploys
(meal-order CloudFront; afterhours/payments/meal-order SSM params).
Deployed via change set wire-account-baseline-and-h16; stack now IN_SYNC.
IAM cross-review completed (new role confirmed; cfn-exec breadth documented).
Mirrors the existing per-repo deploy roles (StringLike sub claim, scoped to
repo:<org>/apm-wo-analysis:ref:refs/heads/main, sts:AssumeRole on
cdk-hnb659fds-* only). Cross-reviewed (cross_reviewer): additive, no existing
role modified; the one flagged item (StringLike->StringEquals) was a false
positive — all 8 existing roles use StringLike, so this is consistent.
- SQS/EC2/SNS as inline policy (managed policy quota is 10)
- cd-sam.yaml now accepts optional parameter-overrides input for
SAM templates with required parameters
- Add cloudformation:CreateChangeSet on aws:transform/* to the shared
CFN execution role (required for SAM's Serverless transform)
- Remove working-directory from pip install step so it finds
requirements.txt at repo root (not just cdk-dir)
