Skip to content

Add --kubeconfig-dir flag for multi-kubeconfig support#35

Merged
nadaverell merged 1 commit into
mainfrom
feature/multi-kubeconfig
Jan 30, 2026
Merged

Add --kubeconfig-dir flag for multi-kubeconfig support#35
nadaverell merged 1 commit into
mainfrom
feature/multi-kubeconfig

Conversation

@nadaverell
Copy link
Copy Markdown
Contributor

Summary

Adds --kubeconfig-dir flag to support loading multiple kubeconfig files from directories. This enables easier migration from Lens, which stores configs as separate files rather than in a single merged kubeconfig.

Usage:

# Single directory
radar --kubeconfig-dir ~/.kube/configs/

# Multiple directories
radar --kubeconfig-dir ~/.kube/lens/,~/.kube/rancher/

Key behaviors:

  • Scans directories for valid kubeconfig files
  • Skips hidden files (.foo) and invalid files
  • Merges configs using kubectl's standard Precedence mechanism
  • All contexts from all files appear in the context switcher
  • Context switching works seamlessly across files

Closes #30

Adds support for loading kubeconfigs from directories, enabling easier
migration from Lens which stores configs as separate files.

- New --kubeconfig-dir flag accepts comma-separated directory paths
- Scans directories for valid kubeconfig files (skips hidden/invalid)
- Merges all discovered configs using kubectl's standard mechanism
- Mutually exclusive with --kubeconfig flag
- Context switching works across contexts from different files

Closes #30
@nadaverell nadaverell requested a review from hisco as a code owner January 30, 2026 14:12
@nadaverell nadaverell merged commit e0725fa into main Jan 30, 2026
2 checks passed
@Cenness
Copy link
Copy Markdown

Cenness commented Jan 30, 2026

Did you test it? It crashes immediately on dir with invalid config

apiVersion: v1
kind: Config
clusters:
  - name: dr-prod-cluster
    cluster:
      server: https://10.0.0.0:6443
      certificate-authority-data: ""
users:
  - name: user
    user:
      client-certificate-data: ""
      client-key-data: ""
contexts: []
preferences: {}
current-context: cluster

@nadaverell
Copy link
Copy Markdown
Contributor Author

Did you test it? It crashes immediately on dir with invalid config

apiVersion: v1
kind: Config
clusters:
  - name: dr-prod-cluster
    cluster:
      server: https://10.0.0.0:6443
      certificate-authority-data: ""
users:
  - name: user
    user:
      client-certificate-data: ""
      client-key-data: ""
contexts: []
preferences: {}
current-context: cluster

Actually did test on invalid config. Maybe invalid in a different way. Let me take another look.

@nadaverell nadaverell deleted the feature/multi-kubeconfig branch February 6, 2026 13:06
nadaverell added a commit that referenced this pull request May 18, 2026
Cross-group kind collisions (e.g. core/Service vs serving.knative.dev/Service
sharing namespace + name) previously caused audit/issue summaries
to silently inherit findings from the wrong resource. The fetch and
relationship paths in T6 were already group-aware; the summary
lookups were not.

pkg/audit:
- Finding and ResourceGroup gain a Group field (omitempty on the wire).
- ResourceKey signature changes to (group, kind, ns, name) — encoded
  "group|Kind|ns|name" with "|" delimiter matching the issue-source
  key in internal/summarycontext.
- Exported GroupForBuiltinKind(kind) — single source of truth for the
  built-in (Kind→Group) map. buildResults populates Finding.Group via
  this helper so the 20 per-check emission sites stay terse.

internal/server:
- buildAIResourceContext threads canonicalGroup from obj GVK through
  to both computeIssueSummaryForResource and computeAuditSummaryForResource.
- Audit lookup uses the new group-aware ResourceKey.
- Issue summary adds a strict row.Group == group check inside the
  match loop. The previous kind-only filter could silently pull in
  a colliding core kind's issues for a CRD lookup.
- UI audit drill-down (handleResourceAudit) explicitly passes group=""
  since the URL doesn't carry group today — comment points to #35
  for the CRD-aware drill-down work.

internal/issues:
- Centralised Group resolution via resolveGroup(group, kind): use the
  explicit group if set, else fall back to audit.GroupForBuiltinKind.
- Applied at fromProblem (legacy k8s.DetectProblems sites still emit
  Group="" for built-in workloads), fromAudit (passes through
  audit.Finding.Group which buildResults populates), fromWarningEvent
  (split apiVersion → group, with "v1"-shape → core).

Pin tests:
- TestResourceKey_GroupAware: distinct keys across groups.
- TestIndexByResource_NoCrossGroupCollision: lookup per-group returns
  only its own findings.
- TestGroupForBuiltinKind: the table.

Closes #35.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multi kubeconfig

2 participants