Proposal: plan-based split certificate Secret layout for karmadactl init

[ranxi2001]

What would you like to be added:

I would like to propose a plan-based certificate Secret layout abstraction for karmadactl init, related to #6051 and #6670, and taking into account the existing implementation attempt in #6788.

The user-facing entry would be an optional layout selector:

• --secret-layout=legacy: keep the current aggregated Secret behavior as the default.
• --secret-layout=split: distribute generated certificate material into component-scoped Secrets, while making workload commands, volumes, mounts, and kubeconfigs consume a declarative certificate plan.

The proposed internal boundary is:

• A certificate layout plan layer that describes identities, Secret names, Secret data keys, kubeconfig contents, component volume mounts, and command-line certificate paths.
• A Kubernetes adapter layer that creates Secrets, generates component kubeconfigs, and translates component plans into Deployment/StatefulSet specs.
• The existing karmadactl init flow selects a layout and passes the plan to deployment generation.

For split mode, the initial scope would be karmadactl init only:

• Split control-plane server/client material into component-scoped Secrets.
• Give scheduler/descheduler their own scheduler-estimator client certificate Secret.
• Keep webhook serving certificates in their own Secret.
• Keep internal etcd server/client certificates separate.
• For external etcd, keep using user-provided CA/client certificate material instead of generating internal etcd server material.
• Keep legacy as the default behavior for backward compatibility.

Non-goals for the first PR:

• No cert-manager CRDs or controller integration.
• No automatic certificate rotation or hot reload behavior.
• No Helm chart or operator changes in the same PR.
• No RBAC/client identity tightening unless maintainers want it included with the layout change.

Design overview:

The diagrams below are for review context. They describe the broader certificate-management direction and the current-vs-future data flow. The first implementation proposed by this issue would only take the karmadactl init layout-plan subset; it would not introduce the CRDs, controllers, or cert-manager integration shown in the longer-term view.

The first diagram shows the long-term certificate management model: policy/plan/inventory APIs, a controller layer, optional cert-manager/CA integration, distribution to member clusters, and observability. For this issue, the relevant part is the layout-plan boundary between certificate generation, Secret distribution, and workload consumption.

The second diagram compares the current built-in certificate flow with the longer-term automated certificate-management direction. For this issue, the relevant change is moving from scattered hard-coded Secret/path handling to a layout plan consumed by the karmadactl init deployment generation code.

I prepared a prototype branch to make the design concrete:

• Branch: https://github.com/ranxi2001/karmada/tree/feature/cert-manager-layout
• Commit: ranxi2001@eb02bde
• Fork push CI: passed for CI Workflow, CLI, Chart, and Operator; FOSSA and image-scanning were skipped.

Local checks run on the prototype:

• golangci-lint run ./pkg/karmadactl/cmdinit/...
• hack/verify-staticcheck.sh
• hack/verify-import-aliases.sh
• go test ./pkg/karmadactl/... -count=1
• hack/verify-command-line-flags.sh
• git diff --check

Why is this needed:

The current karmadactl init certificate handling mixes certificate identity, Secret layout, Secret data keys, volume mounts, kubeconfig generation, and command-line paths across the Kubernetes deployment generation code. This makes the naming convention work in #6051 and the certificate standardization goal in #6670 harder to evolve safely.

A plan-based boundary would keep the default behavior compatible while giving karmadactl init a clearer path to support split certificate distribution. It should also reduce scattered legacy/split conditionals in Deployment and StatefulSet builders.

The main design questions I would like to clarify before opening or continuing an upstream PR are:

1. Is a plan-based certificate layout boundary acceptable for karmadactl init?
2. Should the first implementation target only karmadactl init, or should Helm/operator alignment be designed in the same issue?
3. Should split mode keep a legacy-compatible karmada-cert Secret temporarily for compatibility?
4. Should component client certificate groups/privileges be narrowed in the layout PR, or left for a follow-up?
5. Since feature(karmadactl): support split secret layout in init command #6788 is already open, would maintainers prefer continuing that PR, opening a smaller replacement PR with this abstraction, or first discussing the design under Proposal to Standardize Self-Signed Certificates in Karmada #6670?

@zhzhuang-zju, could you help review whether this direction is reasonable before I proceed with upstream code work?

[ranxi2001]

/kind feature

[zhzhuang-zju]

Thanks @ranxi2001, I have also been considering improvements to the certificate rotation process. I filed issue #7693 as the original issue. Feel free to proceed from there.