You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(pki): refuse to silently reissue or blank an existing kubernetes CA keypair
kops update cluster could propose creating a new kubernetes-ca keypair and
blank ConfigServer.CACertificates in generated nodeup configs even when a
valid CA already existed. If applied, this would break node bootstrap
(empty CA bundle) or, worse, rotate the cluster's CA out from under it.
- CreateKeyset() now re-checks the keystore immediately before minting a
new "ca"-type certificate and refuses if one unexpectedly already
exists there, protecting the dangerous real-apply outcome.
- Keyset gains an IsPlaceholder() helper, and nodeup config rendering
(loadCertificates) now emits an unambiguous placeholder marker instead
of a bare empty string for an unresolved keyset, so a preview can never
look like an existing CA cert was blanked.
Neither change affects a genuinely new cluster's first `update cluster`
dry run, since nothing exists in the keystore to conflict with there.
Fixes#18680
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
// The caller believed this CA needed to be (re)created, but a direct,
278
+
// authoritative lookup right before mutating the keystore shows an
279
+
// existing, valid CA certificate. Silently reissuing it here would
280
+
// rotate the cluster's trust anchor out from under it. This mismatch
281
+
// indicates a task-planning inconsistency (e.g. the keypair task's
282
+
// own Find() did not see this same data) rather than a genuinely
283
+
// missing CA, so refuse instead of proceeding.
284
+
returnnil, fmt.Errorf("refusing to create keypair %q: an existing CA certificate was found in the keystore; this indicates a task-planning inconsistency rather than a genuinely missing CA — aborting to avoid rotating a cluster's trust anchor", name)
0 commit comments