Los permisos del pipeline y la red del chart

La cuenta de servicio con que el pipeline despliega puede hacer en el clúster lo que su rol permita: si tiene cluster-admin, una credencial del pipeline filtrada equivale a un administrador del clúster. El mínimo privilegio pide un Role limitado al namespace destino, con los verbos justos sobre los recursos que el chart crea: Deployments, Services, ConfigMaps. Lo que el chart no crea, la cuenta no debería poder tocar, y los Secrets, los roles y los nodos quedan fuera.

Los enlaces (ClusterRoleBinding) se leen por rol y por sujeto. Dos cosas bastan para detectar los excesivos: qué rol dan y a quién. Un enlace de cluster-admin a un grupo de personas administradoras es esperable; a una cuenta de servicio de un pipeline, no. Abre ci/enlaces-de-rol.txt.

Una NetworkPolicy solo existe si el chart la crea, y los charts suelen protegerla con una condición: «si el valor está activo, créala». Un valor por defecto apagado deja a cada entorno nuevo sin ninguna política hasta que alguien lo recuerde. Mira red/networkpolicy.yaml y red/values.yaml.

Mientras ninguna política de red selecciona un pod, este acepta conexiones de cualquier otro pod del clúster. La cifra que importa es cuántos namespaces no tienen ninguna política, y no cuántas políticas hay en total. Abre red/politicas-red.txt.

El patrón estándar son dos pasos: una política que niega toda la entrada al namespace (selecciona todos los pods y no lista ninguna regla) y, encima, políticas que permiten solo los caminos necesarios, por ejemplo el tráfico que viene del ingress hacia la API. Como el interruptor es del chart, el valor por defecto debe ser activarlas, para que un entorno nuevo nazca cerrado.