feat(deploy): add standalone dashboard kubeconfig secret generator

[warjiang]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Follow karamda repo, separate kubeconfig for more security, make it easy to audit.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to generate and apply an independent dashboard kubeconfig secret for the Karmada Dashboard, including updates to deployment manifests and Helm templates to utilize this new secret. A review comment was provided highlighting a potential issue with the current sed implementation due to delimiter conflicts with base64-encoded strings and shell expansion fragility, suggesting a more robust approach using single quotes and alternative delimiters.

[warjiang]

/assign @RainbowMango

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from rainbowmango. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[RainbowMango]

/assign

[Copilot]

Pull request overview

Adds support for generating and using a dashboard-specific kubeconfig Secret, to decouple the dashboard’s credentials from the general Karmada kubeconfig and improve auditability.

Changes:

• Add a new script to generate/apply karmada-dashboard-config Secret from dashboard-specific client certs (or generate them if missing).
• Introduce a Secret manifest template (artifacts/deploy/karmada-config-secret.yaml) used by the generator.
• Update dashboard manifests/charts to mount kubeconfig as a file path and (for static artifacts) switch to the new Secret/key layout.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
README.md	Documents the new standalone dashboard kubeconfig Secret generation flow.
hack/README.md	Adds usage docs for the new generator script.
hack/generate-karmada-dashboard-kubeconfig.sh	New script to generate/apply the karmada-dashboard-config Secret.
charts/karmada-dashboard/templates/kubernetes-dashboard-api.yaml	Adjusts kubeconfig mount/arg to use a file path.
charts/karmada-dashboard/templates/karmada-dashboard-init-serviceaccount.yaml	Adjusts kubectl job kubeconfig mount/arg to use a file path.
charts/karmada-dashboard/templates/karmada-dashboard-clean-serviceaccount.yaml	Adjusts kubectl job kubeconfig mount/arg to use a file path.
charts/karmada-dashboard/templates/karmada-dashboard-api.yaml	Adjusts kubeconfig mount/args to use a file path.
artifacts/deploy/karmada-config-secret.yaml	New Secret template containing an embedded kubeconfig (karmada.config).
artifacts/dashboard/kubernetes-dashboard-api.yaml	Switches to karmada-dashboard-config Secret and mounts karmada.config.
artifacts/dashboard/karmada-dashboard-web.yaml	Switches to karmada-dashboard-config Secret and mounts karmada.config.
artifacts/dashboard/karmada-dashboard-api.yaml	Switches to karmada-dashboard-config Secret and mounts karmada.config (and removes host kubeconfig flags).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The sed substitutions use / as the delimiter while replacing placeholders with base64-encoded cert/key strings. Base64 output commonly contains /, which will break the sed expression and can generate an invalid secret manifest. Use a delimiter that cannot appear in base64 (e.g. |) and ensure the replacement string is safely escaped (or switch to a tool like envsubst/perl for placeholder substitution).

Suggested change

	function generate_config_secret() {
	local component=$1
	local ca_crt=$2
	local client_crt=$3
	local client_key=$4
	local temp_path=$5
	cp "${REPO_ROOT}"/artifacts/deploy/karmada-config-secret.yaml "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s/\${component}/${component}/g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s/\${ca_crt}/${ca_crt}/g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s/\${client_crt}/${client_crt}/g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s/\${client_key}/${client_key}/g" "${temp_path}"/${component}-config-secret.yaml
	function escape_sed_replacement() {
	printf '%s' "$1" | sed -e 's/[&|]/\\&/g'
	}
	function generate_config_secret() {
	local component=$1
	local ca_crt=$2
	local client_crt=$3
	local client_key=$4
	local temp_path=$5
	local escaped_component
	local escaped_ca_crt
	local escaped_client_crt
	local escaped_client_key
	escaped_component=$(escape_sed_replacement "${component}")
	escaped_ca_crt=$(escape_sed_replacement "${ca_crt}")
	escaped_client_crt=$(escape_sed_replacement "${client_crt}")
	escaped_client_key=$(escape_sed_replacement "${client_key}")
	cp "${REPO_ROOT}"/artifacts/deploy/karmada-config-secret.yaml "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s|\${component}|${escaped_component}|g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s|\${ca_crt}|${escaped_ca_crt}|g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s|\${client_crt}|${escaped_client_crt}|g" "${temp_path}"/${component}-config-secret.yaml
	sed -i'' -e "s|\${client_key}|${escaped_client_key}|g" "${temp_path}"/${component}-config-secret.yaml

[Copilot]

This error message references cloning the main Karmada repo and running hack/local-up-karmada.sh, which doesn't exist in this repository and isn't necessary for this script. Consider updating it to explain that ${CERT_DIR} must point to the directory containing the Karmada certs (or instruct how to generate them) to avoid misleading users.

Suggested change

	function ensure_karmada_repo_initialized() {
	if [[ -d "${CERT_DIR}" ]]; then
	return
	fi
	echo "ERROR: ${CERT_DIR} does not exist."
	echo "Please clone Karmada first: https://github.com/karmada-io/karmada/"
	echo "Then run: hack/local-up-karmada.sh"
	function ensure_cert_dir_exists() {
	if [[ -d "${CERT_DIR}" ]]; then
	return
	fi
	echo "ERROR: certificate directory does not exist: ${CERT_DIR}"
	echo "CERT_DIR must point to the directory containing the Karmada certificates."
	echo "Set CERT_DIR to your cert directory, or generate the Karmada certs before running this script."

[Copilot]

This step still instructs creating a kubeconfig secret with a kubeconfig key, but the manifests in artifacts/dashboard/* now reference karmada-dashboard-config and mount karmada.config. Update this command (or explicitly document the two mutually exclusive flows) so the default install instructions match the deployed manifests.

[RainbowMango]

What does the patched flow mean?

[warjiang]

patched flow means first steup karmada environment with hack/local-up-karmada.sh, then setup cert for karamda dashboard

[RainbowMango]

Got it. But I never heard of such a term. It doesn't sound easy to understand.

Also, I think it's very common to create and deploy a secret for the Karmada Dashboard on an existing Karmada environment, I don't think we need to give users too many options in the Quick Start section.

[warjiang]

updated, PTAL @RainbowMango