feat: Add Path Parameter Support for kubeconfigID Permalinks

[pbochynski]

Description

This PR adds support for a path parameter in kubeconfigID permalinks, allowing users to navigate directly to a specific resource view after loading a kubeconfig.

Problem

Currently, when using kubeconfigID permalinks (e.g., /?kubeconfigID=abc123), users are always redirected to the cluster overview after authentication. There's no way to create a permalink that navigates to a specific resource like pods, deployments, or a specific namespace.

Solution

Added a new path parameter that can be used alongside kubeconfigID to specify the intended navigation path:

/?kubeconfigID=abc123&path=/namespaces/default/pods

The path is stored in sessionStorage during app initialization and used after authentication is complete, ensuring proper navigation timing even with OIDC authentication flows.

Changes

New Files

src/state/intendedPathAtom.ts

• Utility module for storing/retrieving the intended navigation path
• Uses sessionStorage to survive OIDC redirects and page reloads
• Auto-expires after 5 minutes to avoid stale redirects
• Exports: saveIntendedPath, getIntendedPath, clearIntendedPath, initIntendedPathFromUrl

public/kubeconfig/README.md

• Documentation for using local kubeconfig files for development

public/kubeconfig/.gitignore

• Prevents committing sensitive kubeconfig files

Modified Files

src/index.tsx

• Added call to initIntendedPathFromUrl() at app initialization
• Captures the path parameter from URL before React Router processes the route

src/components/Clusters/shared.ts

• Modified addCurrentCluster function to check for intended path
• When intended path exists, navigates to cluster overview first (auth setup happens here)
• Imports getIntendedPath from intendedPathAtom

src/state/useAfterInitHook.ts

• Added intended path handling after auth is ready
• Navigates to the intended path once cluster and auth are both available
• This ensures API calls work correctly (auth headers are set)

Usage

URL Format

/?kubeconfigID=<id>&path=<path>

Examples

URL	Description
/?kubeconfigID=test&path=/namespaces/default/pods	Pods in default namespace
/?kubeconfigID=test&path=/namespaces/kube-system/deployments	Deployments in kube-system
/?kubeconfigID=test&path=/nodes	Cluster nodes
/?kubeconfigID=test&path=/overview	Cluster overview
/?kubeconfigID=test&path=/namespaces/default/pods/my-pod	Specific pod details

Path Format

The path parameter should be the path relative to the cluster root:

• /namespaces/<namespace>/<resource-type> - List resources in a namespace
• /namespaces/<namespace>/<resource-type>/<resource-name> - Specific resource details
• /<cluster-resource-type> - Cluster-scoped resources (e.g., /nodes, /clusterroles)
• /overview - Cluster overview

Local Development Testing

The existing KUBECONFIG_ID feature flag is already configured with kubeconfigUrl: /kubeconfig by default. This means kubeconfig files placed in public/kubeconfig/ are served automatically by Vite.

Setup

1. Copy your kubeconfig file to public/kubeconfig/ without a file extension:

   cp ~/.kube/config public/kubeconfig/test

2. Start the dev server:

   npm start

3. Test the permalink:

   http://localhost:8080/?kubeconfigID=test&path=/namespaces/default/pods
   

Security Note

⚠️ The public/kubeconfig/.gitignore is configured to ignore all kubeconfig files to prevent accidentally committing sensitive credentials.

Production Configuration

In production, configure the KUBECONFIG_ID feature flag in your Busola configuration:

KUBECONFIG_ID:
  isEnabled: true
  config:
    kubeconfigUrl: https://your-kubeconfig-service.example.com/kubeconfig
    showClustersList: false
    defaultKubeconfig: optional-default-id

See Feature Flags Documentation for more details.

Implementation Details

Flow

1. User opens URL: /?kubeconfigID=test&path=/namespaces/default/pods
2. initIntendedPathFromUrl() saves the path to sessionStorage
3. useLoginWithKubeconfigID fetches and loads the kubeconfig
4. addCurrentCluster navigates to cluster overview (auth setup happens)
5. useAfterInitHook waits for auth to be ready
6. Once auth is ready, navigates to the intended path
7. Path is cleared from sessionStorage

Why This Approach?

The navigation to the intended path must happen after authentication is complete. If we navigate immediately when the cluster is added, the API calls to verify the namespace will fail with 400 errors because the auth headers aren't set yet.

By navigating to the cluster overview first and then redirecting to the intended path in useAfterInitHook (which waits for authData to be available), we ensure all API calls work correctly.

Related Issues

• Fixes: Permalinks with kubeconfigID query parameter fail to navigate to the intended resource path on first access #4644