[zjy365]

Summary

Desktop currently blocks kubeconfig access, initialization, and rotation for the User CR named admin. Add the server-only desktop.auth.adminKubeconfigEnabled switch (Helm: desktopConfig.adminKubeconfigEnabled), defaulting to false, so deployments can explicitly opt in. Only the boolean true enables access; missing, unloaded, and invalid configuration keeps the current restriction.

Use one policy for the existing getter/initialization guard and rotation API. Authentication and ordinary users, including ns-admin, retain their existing behavior. Exclude the new field from client configuration and update the YAML defaults, both Helm values files, ConfigMap, and configuration guides. Helm rendering also rejects non-boolean opt-ins.

The switch removes only Desktop's restriction; existing credentials, controller behavior, and RBAC still determine the result. Helm config updates roll the Desktop Pods; direct ConfigMap edits require a restart. Disabling the switch does not revoke kubeconfigs already issued. The frontend rotation visibility switch remains independent.

Validation

Verified in an isolated worktree based on current upstream/main:

• pnpm --filter desktop test:ci: 386 passed, 51 skipped, 2 todo. Includes 51 KC policy/API cases covering enabled/disabled/invalid configuration, initialization, regional/app/global token access, invalid credentials, request overrides, namespace handling, rotation, cluster errors, and client configuration exclusion.
• pnpm exec tsc -p desktop/tsconfig.json --noEmit --incremental false: passed.
• Scoped Next ESLint, Prettier, and git diff --check: passed.
• Helm lint and ConfigMap rendering: base/deployment defaults are false, explicit boolean true is enabled, and string/numeric/null values remain disabled.
• Security, architecture, and four adversarial review passes: no findings.

Kubernetes operations were mocked in tests; no live cluster or credentials were changed.