Handle scenario where a user would not want the rancher context in a kubeconfig

[richard-cox]

Is your feature request related to a problem? Please describe.
See epic issue

Note - I've requested more information on what the underlying issue to having both rancher and target cluster/s context in a single kubeconfig is a problem

Describe the solution you'd like
We probably need to work through the UX

• should we by default omit it, in which case how can users download a kubeconfig to fetch resources from the local cluster (if they do not visibility on it)
• should we optionally omit it, in which case we need a modal for kubeconfig options (which could also contain things like name, select default conext)

#13193
#13192

[github-actions]

🎯 Agentic Issue Triage

This is a feature request / UX design issue requesting that users have the ability to exclude the Rancher context from generated kubeconfigs. It is part of the broader kubeconfig imperative API work (epic #13193, now closed) targeting milestone v2.16.0.

📋 Issue Summary

When a user downloads or copies a kubeconfig via Rancher, the kubeconfig currently includes both the Rancher context and target cluster context(s). Some users may not want the Rancher context included — e.g., for security reasons, cleanliness, or because they lack visibility on the local cluster. Two UX paths are proposed:

1. Omit by default — but then users who need access to the local cluster must have an alternative path.
2. Optionally omit — via a modal for kubeconfig options (which could also expose other settings like name and default context selection).

🔗 Relevant Context & Related Issues

• Epic (closed): #13193 — Support Features of new KubeConfig Imperative API
• Parent work (closed): #13192 — Use new ext.cattle.io.kubeconfig resource to create KubeConfigs
• Backend API: The ext.cattle.io.kubeconfig resource (POST to /v1/ext.cattle.io.kubeconfig) is likely where context inclusion logic would be controlled via request parameters.
• UX Sidebar: #16841 — Kubeconfig sidebar count is incorrect for non-admin users shows ongoing kubeconfig UX attention.

🧩 Design Considerations

• Default behavior: Should the Rancher context be omitted by default or included? Consider the principle of least privilege — omitting it by default reduces the attack surface.
• Local cluster access: If the Rancher context is omitted by default, users who need local cluster access should have a clear way to re-include it (e.g., a checkbox in the modal).
• Modal for kubeconfig options: A kubeconfig options modal could consolidate multiple settings:
  • Include/exclude rancher context
  • Set a name for the kubeconfig resource
  • Select the default context
  • (Future) multi-cluster selection and stitching
• Permission awareness: If a user doesn't have visibility on the local cluster, they should not see the option or it should be disabled/greyed out.

🛠️ Suggested Sub-Tasks / Checklist

• UX Design: Define whether rancher context is omitted by default or optionally
• Check backend API: Confirm if ext.cattle.io.kubeconfig POST supports a parameter to exclude the rancher/local context (e.g., includeLocalCluster: false)
• UI – Modal: Design and implement a "kubeconfig options" modal (if the optional approach is chosen), covering:
  • Toggle: Include rancher context (yes/no)
  • Input: kubeconfig name
  • Select: default context
• UI – Default path: If omit-by-default is chosen, update the download/copy actions to omit the rancher context without showing a modal
• Permissions handling: Handle the case where the user has no access to the local cluster
• Update unit tests for kubeconfig download/copy model actions
• QA automation update or create tests for the new flows

🔍 Debugging & Investigation Pointers

• Relevant code for kubeconfig actions lives in the cluster model — search for generateKubeconfig or ext.cattle.io.kubeconfig in shell/ and pkg/
• The download/copy kubeconfig actions were updated in Use new ext.cattle.io.kubeconfig resource to create KubeConfigs #13192; reviewing that PR's diff is a good starting point
• The kubeconfig action in the cluster list is likely in shell/models/management.cattle.io.cluster.js or similar
• Search for kubeconfig in shell/components/ for any existing modal or dialog that may be extended

📚 Useful Resources

• Rancher Kubeconfig Imperative API RFD
• [Rancher Docs — Use kubectl and kubeconfig]((ranchermanager.docs.rancher.com/redacted)
• Rancher Backend Epic #48621

Generated by Agentic Triage for issue #17615 · ● 221.5K · ◷

[github-actions]

🤖 Issue grooming questions

Thanks for raising this! The issue references a larger epic and outlines some UX options, but a few details are needed before this can be groomed for development.

Missing: Clear Problem Statement

The description says "See epic issue" without summarizing the problem here. Could you briefly explain:

• What specific problem do users experience when the Rancher context is included in a downloaded kubeconfig? (e.g., credential conflicts, unexpected default context, security concerns?)

Missing: Acceptance Criteria

The current description explores possible solutions but doesn't define what "done" looks like. Please add at least 1–3 testable acceptance criteria, for example:

• Is the goal to provide a UI option to omit the Rancher context when downloading a kubeconfig?
• If a modal/options dialog is the solution, what settings must it expose?
• What is the default behavior — include or omit the Rancher context?

This comment was generated automatically to help gather the information needed to groom this issue.

Generated by Daily Issue Grooming · ● 584.1K · ◷