Guide d'utilisation
Ce que c'est
Colle tes manifestes Kubernetes (ou la sortie de kubectl get pods,netpol,svc,ns -A -o yaml, ou de helm template) et il calcule quel pod peut se connecter à quel autre selon leurs NetworkPolicies, avec le port. Clique sur une cellule pour voir pourquoi : quelle politique isole chaque côté et quelle règle laisse passer. Il signale aussi ce qui ne mène nulle part : Services sans pods, ConfigMaps ou Secrets absents, politiques qui ne sélectionnent rien.
Les règles que presque tout le monde confond
Un pod que n'importe aucune politique n'a sélectionné N'est PAS isolé : tout l'atteint. Pour qu'une connexion passe, il faut que la sortie (egress) de la source ET l'entrée (ingress) de la destination l'autorisent toutes les deux. Sans policyTypes, la politique affecte toujours l'ingress, et l'egress seulement si elle a une section egress. Et namespaceSelector avec podSelector dans le MÊME élément, c'est un « et » ; dans des éléments séparés, un « ou ».
Pod Security Standards
Pour chaque charge, le niveau le plus élevé qu'elle atteint (baseline ou restricted) et ce qui lui manque pour le suivant, selon les règles de l'admission controller officiel de Kubernetes 1.37. Si un namespace déclare pod-security.kubernetes.io/enforce, il signale les charges que ce namespace REJETTERAIT à leur création, ce qui est un échec silencieux : le Deployment est créé, ses pods non. Comparé aux 4 537 cas de test du contrôleur lui-même et à sa bibliothèque sur plus de 700 charges réelles.
Ce qu'un pod compromis pourrait faire
Si tu colles aussi tes Role, ClusterRole et bindings, chaque charge affiche ce que son ServiceAccount peut faire d'après la liste des risques d'escalade du guide officiel de Kubernetes (lire des secrets, créer des pods, exec, nodes/proxy, escalate, bind, impersonate…), dans quelle portée et quel binding l'accorde. Et si le token est monté dans le pod : sans token, compromettre le pod ne donne pas ces permissions. Utilise le même moteur que le Labo d'accès. Il n'évalue pas resourceNames : une permission sur UN secret apparaît comme « lire des secrets », on surestime mais on ne cache rien.
Validation par rapport au schéma
Vérifie chaque objet par rapport au schéma OFFICIEL de la version de Kubernetes que tu choisis (de la 1.33 à la 1.37) : champs qui n'existent pas, avec celui que tu voulais probablement écrire, types erronés (un « 80 » entre guillemets là où doit aller un nombre), champs obligatoires manquants et apiVersion retirées, avec la version où elles ont disparu et vers laquelle migrer. Le schéma n'est téléchargé qu'au moment de la validation et seulement celui de cette version : environ 9 Ko. Comparé à kubeconform en mode strict sur plus de mille manifestes, réels et avec des erreurs injectées.
Jusqu'où peut-on lui faire confiance ?
Il suit la spécification officielle de NetworkPolicy, et son résultat a été comparé à netpol-analyzer (np-guard) sur plus d'une centaine de scénarios de son propre dépôt. Ce qu'il NE calcule PAS : les politiques propres à chaque CNI (CiliumNetworkPolicy, Calico), AdminNetworkPolicy, ni le trafic depuis le nœud lui-même, qui passe toujours. Si ton CNI n'applique pas NetworkPolicy, aucune d'elles ne fait rien.
