Políticas de red y secretos en Kubernetes

En Kubernetes, un pod no está aislado hasta que alguna NetworkPolicy lo selecciona: mientras ninguna lo haga, acepta y envía conexiones a cualquier sitio del clúster. La política de entrada «negar todo» es corta: selecciona todos los pods del namespace (podSelector: {}), declara el tipo Ingress y no lista ninguna regla; a partir de ella, solo pasa lo que otras políticas permitan de forma explícita.

Hay una condición: las políticas las hace cumplir el complemento de red del clúster. Si el complemento no las implementa, crear una NetworkPolicy no tiene ningún efecto.

Un clúster con políticas en unos namespaces y ninguna en otros tiene la peor combinación: da sensación de segmentación y deja zonas totalmente abiertas. Se detecta mirando la lista namespace por namespace, no el total. Abre politicas-red.txt.

Revisar los manifiestos no basta: hay que comprobar que algo los ejecute. El inventario de clústeres dice, para cada uno, qué complemento de red tiene y si hay motor de políticas. Un clúster sin motor de políticas puede tener NetworkPolicy escritas en el repositorio y estar tan abierto como si no existieran.

Un Secret guarda sus valores codificados en base64, que es solo un formato: cualquiera con permiso de lectura lo decodifica en un segundo. Además, por defecto Kubernetes guarda los Secrets sin cifrar en su almacén (etcd); quien llegue a ese almacén o a una copia de seguridad los lee. La protección real son tres cosas juntas: cifrar los Secrets en reposo, dar acceso por RBAC con mínimo privilegio y, mejor, que los valores vengan de un gestor de secretos externo.

El Secret bd-pagos es correcto en forma: los despliegues lo referencian con secretKeyRef y el valor no aparece en su manifiesto. Un despliegue distinto lleva la contraseña escrita directamente en el manifiesto, y como los manifiestos viven en un repositorio, esa contraseña vive en el historial de versiones para siempre.

Revisa uso-de-secretos.txt y localiza la variable con el valor a la vista.