fix(talos): migrate non-standard legacy patch layouts (CNI/OIDC-CA/auth extraArgs)

[devantler]

🤖 Generated by the Daily AI Engineer

Problem

The Talos 1.14 legacy-patch migration introduced in #5771 (PR #5775) correctly handles the standard patch layouts ksail itself generates, but three non-standard / split user-patch layouts are not yet migrated faithfully. These surface on ksail cluster create/update for a pinned Talos 1.14 cluster whose existing patch set was hand-written or split across files. Each is a review finding on pkg/fsutil/configmanager/talos/kubernetes_patches.go deferred from #5775 (the false-positive authorizer finding on that PR was refuted with Talos-source evidence; these three are genuine variant gaps).

Affected audience & impact

Operators upgrading an existing cluster to Talos 1.14 whose current patches are not byte-for-byte the ksail-generated forms. Impact ranges from a broken CNI state to an aborted config load.

The three gaps

1. Non-exact disable-default-CNI patches are not migrated (migrateKubernetesPatchesForContract, the switch content byte-match). A disable-CNI patch that isn't byte-for-byte legacyDisableDefaultCNIPatchYAML (e.g. it carries comments, apiVersion, or other cluster.network edits) falls through to the API-server path and is left as legacy cluster.network.cni.name: none. The generated 1.14 config still emits a KubeFlannelCNIConfig document → a custom-CNI cluster comes up with both Flannel and the requested CNI.

   • Expected: detect cluster.network.cni.name: none structurally (not by exact bytes) and drop the Flannel document while preserving any other cluster.network edits.

2. OIDC oidc-ca-file is only resolved within the current patch (oidcConfig → machineFileContent(values.documents, caPath)). When the API-server patch keeps oidc-ca-file but the matching machine.files entry lives in a separate patch (valid pre-1.14, since all patches applied before kube-apiserver read the file), the lookup reports the CA missing and aborts config loading.

   • Expected: resolve the CA file across the full patch set, not just the patch being migrated.

3. Auth-related kube-apiserver extraArgs are copied whole into KubeAPIServerConfig (multiDocumentAPIServerFieldName passes extraArgs through unchanged). Flags such as authorization-mode / authorization-webhook-* (and possibly anonymous-auth) may need to move to the dedicated authorizer/authentication documents in 1.14. Needs verification of exactly which flags the 1.14 KubeAPIServerConfig rejects, then either targeted migration or a clear migration-time error (mirroring the existing RejectsUnsupportedLegacyOIDCExtraArg pattern) instead of emitting a config Talos rejects at apply time.

Acceptance criteria

• Gap 1: a variant disable-CNI patch (with extra fields/comments) migrates to a 1.14 config with no KubeFlannelCNIConfig; both-state test. (delivered in fix(talos): migrate configmanager to alpha.2 multi-document config API #5775 @56e1f7925)
• Gap 2: a split OIDC CA layout (CA machine.files in a different patch) migrates without the "CA missing" abort; test. (delivered in fix(talos): migrate configmanager to alpha.2 multi-document config API #5775 @12d894e02)
• Gap 3: verified list of auth extraArgs the 1.14 KubeAPIServerConfig rejects, with either migration or a targeted migration error + test. (delivered in fix(talos): migrate configmanager to alpha.2 multi-document config API #5775 @43a0c4e3)

Size

~S–M per gap (each an independently shippable child). Suggest decomposing into three delivery children off this issue.

Deferred from #5775; findings by the Codex reviewer at head 6eb175ec52.

[coderabbitai]

🔗 Related PRs

#5506 - test(autoscaler): cover the #5219 baseline-propagation routing dispatcher [closed]
#5524 - feat(scaffolder): scaffold a Dev Container on cluster init [closed]
#5525 - fix(autoscaler): grant Deployment/ResourceQuota RBAC unconditionally [closed]
#5533 - feat(workload): add --schema-location for catalog-absent CRDs [closed]
#5541 - feat(validator): warn when a Talos install-image patch duplicates extensions [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Daily AI Engineer

Gap 1 (structural detection of variant disable-default-CNI patches) is delivered in #5775 at 56e1f7925, with a direct unit test and an end-to-end Load test. Gaps 2 (cross-patch OIDC CA) and 3 (auth extraArgs) remain open here.

[devantler]

🤖 Generated by the Daily AI Engineer

Gap 3 — the verified list, from Talos source (the AC's blocking unknown)

Gap 3 said the reject-list "needs verification". Verified against
siderolabs/talos/pkg/machinery@v1.14.0-alpha.2 — config/types/k8s/apiserver.go,
(*KubeAPIServerConfigV1Alpha1).validateArgs():

deniedPrefixes := map[string]string{
    "anonymous-auth":         "use KubeAuthenticationConfig",
    "oidc-":                  "use KubeAuthenticationConfig",
    "authentication-config":  "use KubeAuthenticationConfig",
    "authorization-config":   "use KubeAuthorizationConfig",
    "authorization-mode":     "use KubeAuthorizationConfig",
    "authorization-webhook-": "use KubeAuthorizationConfig",
}

Six prefixes, matched with strings.HasPrefix (so authorization-webhook-* and oidc-* cover
whole families). Any match makes KubeAPIServerConfig fail validation with:

kube-apiserver extra argument %q is not allowed: <use KubeXConfig>

This confirms the gap is real and bounds it exactly — it is six prefixes, not an open question.

Current coverage in kubernetes_patches.go

Denied prefix	Handled today?
oidc-	✅ Yes — oidcConfig pops the known flags into KubeAuthenticationConfig; any leftover oidc-* hard-errors via unsupportedLegacyOIDCExtraArg / errLegacyOIDCUnsupportedExtraArg
anonymous-auth	❌ No
authentication-config	❌ No
authorization-config	❌ No
authorization-mode	❌ No
authorization-webhook-	❌ No

The five unhandled prefixes are copied verbatim into KubeAPIServerConfig.extraArgs by
migrateAPIServerDocument, so a legacy patch carrying e.g.
cluster.apiServer.extraArgs.authorization-mode: Node,RBAC,Webhook produces a config that Talos
rejects at apply time — exactly the failure Gap 3 describes.

(Note: the existing popAuthorizerDocuments migrates the structured cluster.apiServer.authorizationConfig
field — a different surface from these extraArgs, so it does not cover this.)

Proposed shape for the delivery increment

Mirror the proven RejectsUnsupportedLegacyOIDCExtraArg pattern: after migration, check the
remaining extraArgs against the six prefixes and fail at migration time with a targeted error
naming the offending arg and the document to use — rather than emitting a config that only fails
later at apply. Prefer erroring over silent auto-migration for the authorization family: the
authorization-mode → KubeAuthorizationConfig mapping is lossy (ordering/type semantics), and
[[a type-vs-name authorizer assumption already produced one false-positive review finding on #5775]]
— an explicit, actionable error is safer than a guessed translation.

Table test over all six prefixes + a passing control (a benign extraArgs entry survives untouched).

Not yet implemented — this comment discharges the "needs verification" half of the AC so the
delivery increment is mechanical. Gap 2 shipped in 12d894e02.

[devantler]

🤖 Generated by the Daily AI Engineer

Gap 3 delivered in #5775 @43a0c4e3 — all three gaps are now closed.

The "needs verification" question is answered from the Talos source (machinery@v1.14.0-alpha.2, config/types/k8s/apiserver.go → (*KubeAPIServerConfigV1Alpha1).validateArgs). It denies exactly six prefixes via strings.HasPrefix:

Denied prefix	Talos remediation
anonymous-auth	KubeAuthenticationConfig
oidc-	KubeAuthenticationConfig
authentication-config	KubeAuthenticationConfig
authorization-config	KubeAuthorizationConfig
authorization-mode	KubeAuthorizationConfig
authorization-webhook-	KubeAuthorizationConfig

ksail covered only oidc-; the other five were copied verbatim into KubeAPIServerConfig, so the migration reported success and Talos rejected the config later, at apply time.

Resolution: error at migration time rather than auto-migrate. The check mirrors the existing RejectsUnsupportedLegacyOIDCExtraArg pattern and names both the offending argument and the document that replaces it. Auto-migrating the authorization family was deliberately rejected — the mapping is lossy, and a silent translation would change the effective authorizer chain (the same type-vs-name assumption that produced the refuted authorizer finding on #5775).

Verified RED/GREEN: all five new denied-prefix subtests fail with the check removed and pass with it; a near-miss control (authorization-something-else, anonymous) confirms the guard doesn't over-reject arguments Talos still accepts.