Dashboard

Le dashboard sert à découvrir les clusters auxquels vous avez accès et à récupérer de quoi vous y connecter (jetons, kubeconfig, commandes du plugin kubectl). Il ne remplace pas kubectl : les appels à l'API Kubernetes passent ensuite directement par le proxy.

Vue	Sombre	Clair
Accueil
Clusters
CLI
Connexion à un cluster

Les captures sont régénérées par task ui:screenshots (API simulée, Chromium).

Se connecterCopy Anchor Link

Sur la page d'accueil, Se connecter redirige vers le provider OIDC configuré pour le dashboard. Au retour (/auth/callback), la session est conservée dans le sessionStorage du navigateur : elle est propre à l'onglet et disparaît à sa fermeture.

La liste des clustersCopy Anchor Link

Une fois connecté, la page d'accueil liste les clusters visibles. Un cluster apparaît si :

• son ProxyKubeApi a expose_via_dashboard: true ;
• vous appartenez à son dashboard_group (par défaut dashboard-<namespace>-<nom>).

Si la liste est vide alors que vous attendiez un cluster, c'est l'une de ces deux conditions qui manque : voyez avec l'administrateur.

Les clusters forment un tableau : statut, nom, namespace et SSO. Sélectionner affiche sous le tableau le détail du cluster choisi : son URL via le proxy (https://<dashboard>/clusters/<namespace>/<nom>, copiable) et l'action Se connecter au cluster, la seule action pleine de la page.

Le statut se lit de trois façons à la fois, motif, mot et teinte : il reste lisible en niveaux de gris comme au lecteur d'écran.

Se connecter au cluster est désactivé pour un cluster injoignable ou désactivé.

Accéder à un cluster SSOCopy Anchor Link

Pour un cluster dont auth_config.oidc_provider est activé, Accéder au cluster lance un login OIDC propre à ce cluster (son propre client OIDC), puis revient sur /auth/callback/<namespace>/<nom>. La page affiche alors :

• Cluster : nom, namespace, URL, utilisateur et statut ;
• Tokens : access_token, id_token et, s'il existe, refresh_token, chacun copiable ;
• Configuration Kubernetes, en trois onglets : deux kubeconfigs à télécharger ou copier, puis les commandes du plugin.
  • le kubeconfig simple, qui embarque l'id_token : prêt à l'emploi, mais valable seulement jusqu'à l'expiration du jeton ;
  • le kubeconfig plugin, dont l'utilisateur appelle kubectl proxyauth get-token : le jeton est lu à chaque appel dans le trousseau du plugin. C'est ce qu'écrit aussi kubectl proxyauth login, qui reste la solution recommandée.
• l'onglet Plugin CLI : les étapes pour installer et configurer le plugin kubectl avec ces jetons.

Accéder à un cluster sans SSOCopy Anchor Link

Pour un cluster en mode Kubernetes (jetons ServiceAccount, cloud, etc.), Accéder au cluster ouvre /clusters/<namespace>/<nom>/nosso. ProxyAuthK8S ne délivre pas de jeton pour ces clusters : la page fournit un kubeconfig pointant sur le proxy, avec un YOUR_ACCESS_TOKEN à remplacer par un jeton valide sur le cluster cible (par exemple kubectl create token <serviceaccount> exécuté sur ce cluster).

Un cluster en échange de jeton (TokenExchange) ouvre la même page, mais son kubeconfig n'attend aucun jeton du cluster : il suppose la session SSO du plugin (kubectl proxyauth login --server-url …, puis login <cluster>), et la page le dit.

Avec le plugin, l'équivalent est :

kubectl proxyauth -n <namespace> login <nom> --token <jeton>

La page CLICopy Anchor Link

L'entrée CLI du menu (/cli) rassemble le guide d'installation et d'usage du plugin kubectl proxyauth, également disponible ici : Plugin kubectl.

La page À proposCopy Anchor Link

/about est publique (accessible sans être connecté, c'est la cible du lien de l'accueil). Elle présente le projet et renvoie vers cette documentation, la page du plugin kubectl, la page architecture, la référence interactive de l'API du serveur (/api/docs) et le dépôt GitHub.

Apparence et langueCopy Anchor Link

Le bouton Réglages de l'en-tête ouvre deux choix à trois états :

Le navigateur retient la préférence (localStorage, clés pak.theme et pak.locale), pas la valeur résolue : « Système » suit encore l'appareil si celui-ci change. Le thème est appliqué avant le premier affichage, sans flash. En navigation privée, les réglages valent pour l'onglet.

L'interface suit le design system BatleHub (« The Proof Sheet ») : polices servies par le dashboard lui-même (aucune requête vers un tiers), contraste WCAG 2.2 AA vérifié par axe dans les deux thèmes, navigation complète au clavier avec un anneau de focus ambre, et les messages (copie, erreurs) lus par les lecteurs d'écran. Le détail propre à ProxyAuthK8S est dans apps/front/DESIGN.md.

Déploiement : en-têtes et CSPCopy Anchor Link

L'image du dashboard sert ces en-têtes sur chaque réponse :

• Content-Security-Policy : default-src 'self', un seul script inline autorisé par son hash (le choix du thème), style-src 'self', polices et images locales, frame-ancestors 'none', base-uri 'none' ;
• X-Content-Type-Options: nosniff et Referrer-Policy: no-referrer.

connect-src et frame-src sont construits au démarrage à partir des variables déjà utilisées par l'image : l'origine de PROXYAUTHK8S_FRONT_API_BASE_URL (API) et celle de PROXYAUTHK8S_FRONT_OIDC_ISSUER_URL (IdP, aussi pour le renouvellement silencieux). Le chart Helm les remplit.