fix(infra): stop a flagless plan from deleting the executor KMS key - #68
Merged
Merged
Conversation
executor_kms_enabled and executor_kms_signing defaulted to false while the live stack has both true -- they were passed as -var during the rollout in #62-#64 and persisted nowhere. Any plan in infra/aws that omitted them proposed: aws_kms_key.executor[0] will be destroyed aws_kms_alias.executor[0] will be destroyed aws_iam_role_policy.executor_kms_sign[0] will be destroyed aws_ecs_task_definition.execution must be replaced Plan: 3 to add, 1 to change, 4 to destroy. That schedules the settlement key for deletion and drops EXECUTOR_KMS_KEY_ID from execution-service. Since #64 deleted the stored PRIVATE_KEY there is no second signing path, so the replacement task would carry no key at all and fail its config schema at boot. Two changes, because either alone leaves a gap: - the defaults are true, so a plan with no flags is a no-op - both KMS keys carry lifecycle.prevent_destroy, so an explicit -var executor_kms_enabled=false errors instead of destroying Verified against the live state: a plan with no KMS flags reports "No changes"; the same plan with executor_kms_enabled=false now fails with "Instance cannot be destroyed" rather than producing an appliable plan. Also adds aws_kms_key.rebalance (alias numo-exchange-rebalance), applied 2026-09-17 and deriving to 0x1661AA54fA390cd916722F971e4A9Fe4c01889fB, which signs USDC->cNGN swaps on the HyperFX IntentGateway for the cNGN rebalance. Deliberately not the executor key: a compromise there costs the float, not the venue's settlement authority. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
executor_kms_enabledandexecutor_kms_signingdefault tofalse, but the live stack has bothtrue— they were passed as-varflags during the executor rollout (#62–#64) and written down nowhere. Everyterraform planininfra/awsthat omitted them proposed destroying the key the venue settles with.Found while planning an unrelated change. Nothing was applied; plans are read-only and this was caught by reading the destroy list, not by any failure.
Since #64 deleted the stored
PRIVATE_KEY,signing = falseis not a fallback — the task gets neitherEXECUTOR_KMS_KEY_IDnorPRIVATE_KEYand refuses to boot. So the setting is dead, not merely wrong.Fix
Both halves, because either alone leaves a gap:
truelifecycle.prevent_destroyon both KMS keys-var executor_kms_enabled=falseerrors instead of destroyingThe local
counts.auto.tfvarsworkaround is removed — it is gitignored, so it never survived a fresh clone or a second machine, which is what made this worth fixing in the repo.Verification
Against live state, with images pinned to what is running:
No changes. Your infrastructure matches the configuration.executor_kms_enabled=false→Error: Instance cannot be destroyedAlso
Adds
aws_kms_key.rebalance(aliasnumo-exchange-rebalance), applied 2026-09-17, deriving to0x1661AA54fA390cd916722F971e4A9Fe4c01889fB. It signs USDC→cNGN swaps on the HyperFX IntentGateway for the cNGN rebalance loop, and is deliberately not the executor key — a compromise there costs the float, not the venue's settlement authority. It holds nothing yet.🤖 Generated with Claude Code