Roadmap

CRD & ValidationCopy Anchor Link

Création d'une CRD pour stocker les clusters cibles et validation contre des règles définies.

Authentification OIDCCopy Anchor Link

Authentification des utilisateurs via un provider OIDC pour l'UI avec filtrage du dashboard basé sur les groupes utilisateurs.

Interface utilisateurCopy Anchor Link

• Liste des clusters accessibles par l'utilisateur
• Connexion OIDC vers les clusters et affichage du kubeconfig
• Affichage du kubeconfig pour les providers non-OIDC
• Client API auto-généré depuis la documentation Swagger

Controller KubernetesCopy Anchor Link

• Réconciliation des CRD et mise à jour du statut des clusters
• Gestion des callbacks OIDC
• Haute disponibilité via élection de leader

Backend & ProxyCopy Anchor Link

• API exposée pour l'UI
• Redirection des requêtes vers le bon cluster selon les droits d'accès
• Validation des tokens contre le provider OIDC ou Kubernetes
• Haute disponibilité via stockage d'état dans Redis
• Documentation Swagger auto-générée

CI/CDCopy Anchor Link

• À chaque commit : CodeQL, analyse CVE Rust, Lint front
• Sur TAG (vX.X.X) : Build Docker → GHCR, Helm → GHCR, Draft release GitHub
• Pré-TAG : Format vX.X.X, cog par contributeur humain, changelog obligatoire

DocumentationCopy Anchor Link

Plugin kubectlCopy Anchor Link

Création d'un plugin kubectl (proxyauth) pour faciliter l'utilisation en CLI.

• ✅ Client auto-généré depuis l'OpenAPI spec
• ✅ Installation depuis la release GitHub via mise ; pas de publication sur le Krew Index pour le moment

CI/CDCopy Anchor Link

• ✅ Build du plugin et rendu du manifeste Krew, attachés à la release GitHub lors d'un TAG

Redesign de l'UICopy Anchor Link

Refonte du front sur le design system BatleHub (« The Proof Sheet ») : tokens, polices auto-hébergées, thèmes clair et sombre, i18n en/fr, WCAG 2.2 AA et en-têtes de sécurité (CSP). Voir la RFC 0002.

• ✅ Refonte UI

OutillageCopy Anchor Link

Sortie de NX et passage à un workspace pnpm orchestré par Taskfile (prérequis de la refonte UI). Voir la RFC 0001.

• ✅ Sortie de NX et workspace pnpm

Ports et verbes (breaking)Copy Anchor Link

• ✅ Contournements du filtrage des ports fermés : proxy pods|services/x:port/proxy, nodes/proxy, règles sans allowed_ports (RFC 0003)
• ✅ Règles sensibles au verbe Kubernetes (verbs), lecture seule implicite sous restriction (RFC 0006)
• ✅ Fuzzing des parseurs (workspace fuzz/, job nightly)

Serveur sur axumCopy Anchor Link

• ✅ Migration d'actix-web vers axum (hyper 1), iso-fonctionnelle, tunnel d'upgrade sur hyper::upgrade (RFC 0007) ; reste la recette de 7 jours

Exec, attach et audit (breaking)Copy Anchor Link

• ✅ Trace d'audit : schéma versionné, émission garantie, authentification, jetons OAuth, bannissements, fin de session (RFC 0008)
• ✅ Liste blanche des commandes, conteneurs et flux pour exec/attach, filtre de canaux, audit de session (RFC 0004)

Conditions, Events et codes de raison (RFC 0011)Copy Anchor Link

• ✅ Condition Ready standard (kubectl wait, Argo CD, Flux), colonnes READY et REASON
• ✅ Events Kubernetes à chaque échec et à chaque transition
• ✅ Rythme de reconcile du kit : 5 min, backoff 30 s → 5 min ; métriques de reconcile

Mode Agent (RFC 0012)Copy Anchor Link

• ✅ Un agent installé sur le cluster distant ouvre un tunnel sortant (WebSocket + yamux) vers ProxyAuthK8S : l'apiserver n'a plus à être exposé (guide)
• ✅ TLS de bout en bout entre le proxy et l'apiserver : l'agent ne voit que des octets chiffrés et n'a aucun RBAC
• ✅ Une passerelle d'agents à part (ou dans le pod du proxy) : un redémarrage du proxy ne coupe pas les tunnels
• ✅ Enrôlement par jeton de ServiceAccount projeté (JWKS en ligne, par URL ou depuis un ConfigMap / Secret) ; révocation par epoch
• ✅ Jeton à usage unique (External Secrets + Vault), certificats de votre propre PKI (ExternalCA : cert-manager, Vault PKI), CronJob jwksPublisher
• ✅ Sortie de l'agent par un proxy CONNECT ou SOCKS5 ; tlsMode: passthrough
• ✅ Passerelle prête pour la production : PDB, HPA à réduction lente, métriques Prometheus
• ⏳ Condition AgentConnected (attend un correctif du kit)

Versions des agents (RFC 0013)Copy Anchor Link

• ⏳ Protocole négocié entre l'agent et la passerelle, refus explicite d'un protocole inconnu (AgentProtocolUnsupported)
• ⏳ Versions des agents par cluster dans status.agent, avis AgentVersionSkew au-delà d'une mineure de retard
• ⏳ Annonces de l'agent validées avant d'atteindre le statut

Le proxy comme authentificateur de confiance (RFC 0014)Copy Anchor Link

• ✅ upstream_auth.mode: FrontProxy : l'apiserver fait confiance à l'identité que le proxy affirme en en-têtes (guide)
• ✅ upstream_auth.mode: Issuer : le proxy signe un JWT que l'apiserver vérifie par son JWKS (guide)
• ✅ Sonde de confiance de l'amont et claim_mappings

Échange de jeton (RFC 0010)Copy Anchor Link

• ✅ Une connexion SSO au proxy, échangée contre un jeton par cluster (fédération d'IdP)

Tests approfondisCopy Anchor Link

• ✅ Tests back (unitaires, intégration, envtest) avec un seuil de couverture en CI
• ✅ Tests front : accessibilité et end-to-end (RFC 0002)
• ✅ Tests profonds côté Rust : faux Redis en mémoire, garde-fous (routes, variantes, contrat OpenAPI), mutants sur les crates de sécurité, couverture à 88 % pour un plancher de 85 (RFC 0015, .rfc/0015-deep-tests.md, Implemented)
• ✅ Suite heavy (écho amont, version précédente à côté) et charge HTTP k6 (RFC 0016, .rfc/0016-heavy-and-load-tests.md, Implemented)

Redis Cluster HACopy Anchor Link

• ✅ Support du mode cluster Redis pour la haute disponibilité et le stockage d'état (liste d'URLs ou REDIS_CLUSTER=true).

Sécurité renforcéeCopy Anchor Link

• ✅ Application de allowed_resources sur le chemin proxy, y compris par group/version/kind (AllowedCrdConfiguration)
• ✅ Autorisation par cluster (proxy_group)
• ✅ Rate limiting et fail2login, adossés à des compteurs Redis
• ✅ Audit de chaque requête proxifiée
• ✅ mTLS entre le proxy et les clusters cibles
• ✅ Règles d'admission CEL sur la CRD
• ✅ Validation locale des JWT contre les authenticators jwt (validate_against: JwtAuthenticators)
• ✅ Récupération de la configuration OIDC depuis des secrets externes (oidc_provider.config_from)
• ✅ Validation des tokens OIDC renforcée

Bascules de défauts (breaking)Copy Anchor Link

• ⏳ Supprimer l'orthographe dépréciée allowed_ressources une fois les ressources migrées vers allowed_resources
• ⏳ verbs absent vaut lecture seule (get, list, watch) pour tous (RFC 0006)
• ⏳ exec absent : exec interdit sauf règle exec explicite (RFC 0004)

QualitéCopy Anchor Link

• ⏳ Nettoyage de l'historique Git
• ✅ Méthodes d'installation du plugin dans l'UI : l'installation manuelle télécharge l'archive kubectl-proxyauth_<version>_<os>_<arch>.tar.gz de la dernière release, l'onglet Homebrew (tap inexistant) est retiré

CI/CDCopy Anchor Link

• ⏳ Publication automatique de la documentation sur GitHub Pages lors d'un TAG

Support ProxyCopy Anchor Link

Ajout de la possibilité de passer par un proxy (ex: Netbird) pour les connexions aux clusters.

Politique fermée par défautCopy Anchor Link

• Mode default: deny quand allowed_resources est vide (aujourd'hui : tout est autorisé, risque accepté documenté)
• Sujets (users/groups) sur les règles Path, pour qu'une restriction ne vise pas tout le cluster

Login SSO par device codeCopy Anchor Link

Prise en charge de l'OAuth 2.0 Device Authorization Grant (RFC 8628) pour le login SSO du plugin kubectl quand le navigateur n'est pas sur la machine du plugin (workspace Eclipse Che, session SSH, conteneur distant) : l'utilisateur ouvre une URL courte sur n'importe quel appareil et saisit un code, sans redirection vers localhost ni URL à recoller.

Aujourd'hui, ce cas est couvert en collant l'URL de redirection dans le terminal (voir « Navigateur sur une autre machine » dans la page du plugin kubectl) ; le device code en serait la variante la plus confortable.

• IdP : endpoint device_authorization_endpoint annoncé par la discovery (Keycloak, Entra ID, Okta, Dex…) et device grant activé sur le client OIDC de chaque cluster.
• Serveur : démarrage du flux et interrogation du token endpoint (authorization_pending, slow_down, expired_token), le client secret restant côté serveur comme pour l'échange de code actuel, avec le même contrôle proxy_group que /auth/login.
• Plugin : login --device-code, ou automatiquement quand le provider le propose et qu'aucun navigateur local n'est utilisable ; affichage de l'URL de vérification et du code.