Separate the seal key from the key that encrypts node volumes

[sethbergman]

Closes #55.

They were one key, and terraform destroy scheduled it.

storage.tf warns that a snapshot is encrypted under the auto-unseal key and that it "must not be scheduled for deletion when a cluster is torn down". The root volume used the same key — so a teardown put it on a seven-day timer, and with it every snapshot ever taken with that key, including from clusters that no longer existed. The document said one thing and the code did the other.

Two keys

key	window	holds
<cluster>-vault-autounseal	30 days	Vault's seal, and the snapshot bucket's SSE
<cluster>-vault-data	7 days	root volumes only

The bucket stays on the seal key deliberately. Reading a snapshot needs this key for the object and this key for the keyring Vault sealed inside it — so exactly one thing has to outlive a teardown. One rule an operator can follow; two is a rule they will half-follow.

teardown-cloud.sh now names both keys and says which one to cancel, since the whole hazard is that they look alike in the console.

The assertions are split by what each layer can answer

terraform test checks configuration — two keys, distinct descriptions, the windows that make the split worth having.

It does not compare arns, because the mock gives every aws_kms_key the same one:

mock_resource "aws_kms_key" {
  defaults = { arn = "arn:aws:kms:...:key/12345678-..." }
}

So != can never hold and == passes trivially. My first version asserted exactly that and failed — tests/README.md warns about it in as many words, and I ignored it.

The arn comparison lives in tests/cloud-apply-emulated instead, where the API mints real ones: the two keys differ, and the root volume is not on the seal key.

Verified

terraform fmt clean, 28 passed / 0 failed in WSL.

Still not settled by any of this

Whether the ASG service-linked role needs explicit key-policy grants once a restrictive policy replaces the default. moto does not enforce IAM, so that half still waits for a real apply — as noted in #55.

🤖 Generated with Claude Code

[sethbergman]

Green, and one commit landed after the description above

27/27, MERGEABLE / CLEAN.

aws_kms_key: expected 1

The first run failed on a resource count in the emulated apply — mine,
written when the profile had one KMS key. Splitting it made two and I did
not update the count with them.

What passed in that same run is the part that matters. The profile
applied end to end with both keys and destroyed cleanly, and both new
assertions held against real arns:

PASS  the AWS profile applies end to end
PASS  the seal key and the volume key are different keys
PASS  the root volume is not encrypted with the seal key
PASS  terraform destroy removes everything it made

Those two are exactly what terraform test structurally cannot check,
since its mock hands every aws_kms_key the same arn. So the split is
verified by the only layer that can verify it.

On the stale count

Second time a hardcoded count in that file has gone out of date after a
deliberate change — the IAM roles did the same when network.tf's
flow-logs role turned out to exist.

Worth keeping rather than loosening. The counts earn their place by
catching a resource appearing or vanishing unnoticed, and the price is
that a deliberate change has to update them. That is the trade working.

What this does not settle

The other half of #55: whether the ASG service-linked role needs explicit
key-policy grants once a restrictive policy replaces the default. moto
does not enforce IAM, so a real apply is the only thing that answers it.
Recorded in the issue rather than closed with the rest.