Texto y documentos
Números y cálculo
Datos y formatos
Seguridad
Desarrollo y DevOps
Inteligencia Artificial
Finanzas
Salud y bienestar
Productividad
Juegos y entretenimiento
Multimedia y diseño
Empresa
Guía de uso
Qué es

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.

Las reglas que casi todo el mundo confunde

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».

Pod Security Standards

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.

Qué podría hacer un pod comprometido

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.

Validación contra el esquema

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.

¿Hasta dónde fiarse?

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.

Alcance de red en Kubernetes¿Llega el pod A al B? NetworkPolicy, puertos y referencias rotas
Alcance de red en Kubernetes¿Llega el pod A al B? Según tus NetworkPolicy, con el puerto y el porqué. 100 % en tu navegador
No se envía ni se guarda en ningún sitio: pueden llevar Secrets