devantler-tech / devantler-tech/ksail
Move kubeadm Hetzner signing PKI out of provider user-data
- Dominant language
- Go
- Stars
- 165
- Forks
- 12
- Avg merge
- 4h 23m
- Merged PRs (30d)
- 358
Description
> 🤖 Generated by the Agentic Engineer
## Evidence and impact
The supported kubeadm Hetzner bootstrap still places cluster-signing private material in provider-readable initialization data. The HA hotfix removes extra copies, but the initial control plane keeps this exposure so existing single-control-plane users remain affected.
## Hypothesis
Generating or transferring the private material through a channel outside provider user-data will preserve the current one-command workflow while removing provider-side key retention and safely re-enable additional control planes.
## Acceptance criteria
- No cluster-signing private key material appears in rendered provider user-data for initial or joining nodes.
- Single-control-plane creation remains one command with no new manual step.
- HA stays refused until the safe transfer path has behavioral tests in both supported and refused states.
- End-to-end proof observes a real cluster bootstrap and verifies provider-visible data contains no signing keys.
## Security floor and DevEx
The provider can no longer retain cluster-signing keys. The everyday create path remains as easy as today.
---
## Delivery status (2026-08-22)
All four sub-issues are closed (#6548, #6608, #6611, #6626), so the write-path guards, the
allowlist rewrite and the node-side verifier have all landed. The first three acceptance criteria
are met.
**The remaining criterion is the end-to-end proof**, and it has no path to run today:
**Blocker:** devantler-tech/ksail#5515 | upstream | last-verified 2026-09-14: still blocking — the Hetzner credential half of #6361 is resolved (HCLOUD_TOKEN rotated 2026-09-13; #7018/#7023 merged, weekly schedule restored), but that schedule runs Talos only, so a real kubeadm (Vanilla) × Hetzner bootstrap still has no lane; #5515 adds it and is now startable.
`System Test - Hetzner` has no successful run on record (six consecutive scheduled failures
2026-05-31 → 2026-07-05), and its `schedule` trigger was removed on 2026-07-09; rotating the
credential is maintainer authority.
`#6627` deliberately shipped the verifier so this proof would have something to call — the
capability exists, only the environment to run it in does not. Nothing else about this issue is
blocked, so it should be skipped under actionability clause (b) rather than restarted, and closed
once a green Hetzner system-test run exercises the verifier against a real bootstrap.
Contributor guide
Assessment
This issue has not been assessed yet.