Deliver Kubernetes Credentials to Wirelet Container

Summary

Following the proposal to deploy Wirelet inside a switch through the Switch object, we need a way to provide Wirelet with Kubernetes API credentials during ZTP provisioning.

Wirelet needs a kubeconfig, token, or equivalent credential inside the SONiC OS so it can register and reconcile Wire resources against the Kubernetes API.

Basic example

One possible API direction is to reuse the new Pod-style volumes and volumeMounts model:

apiVersion: sonic.networking.metal.ironcore.dev/v1alpha1
kind: Switch
metadata:
  name: leaf-1
spec:
  volumes:
  - name: wire-control-kubeconfig
    secret:
      secretName: wire-control-kubeconfig

  containers:
  - name: wirelet
    image: ghcr.io/giluerre/wirelet-sonic:latest
    env:
    - name: KUBECONFIG
      value: /var/run/wire/kubeconfig
    volumeMounts:
    - name: wire-control-kubeconfig
      mountPath: /var/run/wire
      readOnly: true

The generated ZTP script would materialize the Secret on the switch and bind-mount it read-only into the requested container.

Another possible approach

Operator-level shared kubeconfig

Mount one restricted control-cluster kubeconfig into sonic-operator. A container explicitly opts in, and the generated ZTP script writes and mounts that credential on the switch.

This is simple for the initial lab setup, but creates a shared identity across switches.

Motivation

The motivation of this issue is to agree on the preferred credential-delivery model and define a minimal, generic API that does not make the Switch CR aware of Wirelet specifically.