Pega tus manifiestos de Kubernetes (o la salida de kubectl get pods,netpol,svc,ns -A -o yaml, o de helm template) y calcula qué pod puede conectarse a cuál según sus NetworkPolicy, con el puerto. Pulsa una celda para ver por qué: qué política aísla a cada lado y qué regla lo deja pasar. Además avisa de lo que no lleva a ninguna parte: Services sin pods, ConfigMaps o Secrets que no están, políticas que no seleccionan nada.
Un pod que ninguna política selecciona NO está aislado: le llega todo. Para que una conexión pase, tienen que permitirla la salida del origen Y la entrada del destino. Sin policyTypes, la política afecta siempre a la entrada y a la salida solo si trae sección egress. Y namespaceSelector con podSelector en el MISMO elemento es «y»; en elementos separados, «o».
Para cada carga, el nivel más alto que cumple (baseline o restricted) y qué le falta para el siguiente, con las reglas del admission controller oficial de Kubernetes 1.37. Si un namespace declara pod-security.kubernetes.io/enforce, avisa de las cargas que ese namespace RECHAZARÍA al crearlas, que es un fallo silencioso: el Deployment se crea y sus pods no. Contrastado con los 4.537 casos de prueba del propio controlador y con su librería sobre más de 700 cargas reales.
Si pegas también tus Role, ClusterRole y bindings, cada carga enseña lo que puede hacer su ServiceAccount de la lista de riesgos de escalada de la guía oficial de Kubernetes (leer secretos, crear pods, exec, nodes/proxy, escalate, bind, impersonate…), en qué ámbito y qué binding lo concede. Y si el token se monta en el pod: sin token, comprometer el pod no da esos permisos. Usa el mismo motor que el Laboratorio de accesos. No evalúa resourceNames: un permiso sobre UN secreto sale como «leer secretos», se sobreestima pero no se esconde.
Comprueba cada objeto contra el esquema OFICIAL de la versión de Kubernetes que elijas (de la 1.33 a la 1.37): campos que no existen, con el que seguramente querías escribir, tipos equivocados (un «80» entre comillas donde va un número), obligatorios que faltan y apiVersion retiradas, con la versión en la que desaparecieron y a cuál migrar. El esquema se descarga solo al validar y solo el de esa versión: unos 9 KB. Contrastado con kubeconform en modo estricto sobre más de mil manifiestos, reales y con errores inyectados.
Sigue la especificación oficial de NetworkPolicy, y su resultado se ha contrastado con netpol-analyzer (np-guard) en más de un centenar de escenarios de su propio repositorio. Lo que NO calcula: las políticas propias de cada CNI (CiliumNetworkPolicy, Calico), AdminNetworkPolicy, ni el tráfico desde el propio nodo, que siempre pasa. Si tu CNI no aplica NetworkPolicy, ninguna de ellas hace nada.