kops 1.36.2: update cluster wants to create a new kubernetes-ca Keypair and blanks ConfigServer.CACertificates in nodeup config

[kevin3274]

/kind bug

1. What kops version are you running?

Client version: 1.36.2

Compared against 1.36.1 (same cluster, same state store) as a control — see below.

2. What Kubernetes version are you running?

1.36.3 (unchanged; this report is only about the kOps CLI version).

3. What cloud provider are you using?

AWS (ap-east-2), single control-plane node, Cilium networking, Karpenter enabled.

4. What commands did you run? What is the simplest way to reproduce this issue?

kops update cluster --name <cluster>     # dry-run only, never applied

5. What happened after the commands executed?

kops update cluster (dry-run) proposes to create a new kubernetes-ca Keypair even though a valid one already exists, and — more seriously — blanks out ConfigServer.CACertificates in every generated nodeup config.

Will create resources:
  Keypair/kubernetes-ca
  	Subject             	cn=kubernetes-ca
  	Issuer
  	Type                	ca
  	LegacyFormat        	false

In all four generated artifacts (nodeupconfig-* and nodeupscript-* for the control-plane IG and two Karpenter-managed node IGs), the CA bundle is replaced with an empty string:

  ConfigServer:
-   CACertificates: |
-     -----BEGIN CERTIFICATE-----
-     MIIC+DCCAeCgAwIBAgIMGMGDKGLnT...   (full, valid kubernetes-ca cert)
-     -----END CERTIFICATE-----
+   CACertificates: ""
    servers:
    - https://kops-controller.internal.<cluster>:3988/

If applied, newly launched nodes would have no CA bundle to validate kops-controller against and would fail to bootstrap. I did not apply it.

6. What did you expect to happen?

No keypair creation and no change to ConfigServer.CACertificates — the existing CA is valid and current.

7. Anything else we need to know?

The existing CA is healthy and 1.36.2 itself can read it fine:

$ kops get keypairs kubernetes-ca            # 1.36.2
NAME           ID                            ISSUED      EXPIRES     PRIMARY  HASPRIVATE
kubernetes-ca  76615822939036767148447545..  2026-07-10  2036-07-09  *        *

$ kops get keypairs kubernetes-ca -o yaml    # 1.36.2
- hasPrivateKey: true
  id: "76615822939036767148447545.."
  isCA: true
  isPrimary: true
  issuer: CN=kubernetes-ca
  keyLength: 2048
  name: kubernetes-ca
  notAfter: "2036-07-09T10:12:16Z"
  notBefore: "2026-07-10T10:12:16Z"
  subject: CN=kubernetes-ca

1.36.1 produces byte-identical output for both commands. So the keyset in the state store is readable by 1.36.2 — the problem appears to be in how update cluster builds its task graph / renders the CA into nodeup config, not in the keyset loader.

Control experiment. Same cluster, same state store, same KOPS_STATE_STORE, run back to back; the only variable is the kOps binary:

	1.36.1	1.36.2
dry-run output lines	169	619
Will create: Keypair/kubernetes-ca	0	1
occurrences of CACertificates	0	8 (4 of them blanking it)
NodeupConfigHash changes	0	10

1.36.1 proposes only four addon-manifest updates (certmanager / karpenter / cilium / bootstrap-channel) and never touches the CA.

The NodeupConfigHash and nodeup URL changes in 1.36.2 are expected for a CLI version bump; the CACertificates blanking is not.

I looked through the 1.36.2 release notes and the v1.36.1...v1.36.2 diff and could not find an obviously related change — nothing touches pki/keypair code. (Note the GitHub compare API truncates files at 300, so my view of the diff may be incomplete.) Dependency bumps in that range include golang.org/x/crypto v0.53.0 → v0.54.0.

The cluster's CA was created 2026-07-10 and the keyset was last written 2026-07-12; the state store has pki/private/kubernetes-ca/keyset.yaml and no pki/issued/kubernetes-ca/ directory.

Happy to run any diagnostic command against this cluster to help narrow it down.