¿Cuáles son los fundamentos de la seguridad en Kubernetes (RBAC y políticas de red)?

Kubernetes viene abierto por defecto — permisos amplios y red plana — así que la seguridad es algo que debes añadir. Los dos controles fundamentales son el RBAC y las políticas de red, y una buena respuesta explica tanto el mecanismo como el comportamiento por defecto que pilla a la gente.

RBAC: quién puede tocar la API

Todo en Kubernetes pasa por el servidor de API, así que controlar el acceso a la API es primordial.

• Roles / ClusterRoles definen un conjunto de verbos permitidos (get, list, create, delete) sobre recursos (pods, secrets). Los Roles están limitados a un namespace; los ClusterRoles abarcan todo el clúster.
• RoleBindings / ClusterRoleBindings adjuntan esos roles a sujetos — usuarios, grupos o cuentas de servicio.
• Privilegio mínimo: evita vincular cualquier cosa a cluster-admin, evita verbos/recursos con comodín, y da a la cuenta de servicio de cada carga de trabajo solo lo que necesita. Un pod que puede leer todos los secrets es una ruta de escalada seria si se ve comprometido.

Políticas de red: quién puede hablar con quién

Por defecto, cualquier pod puede alcanzar cualquier otro pod — red plana, que permite todo. Un pod comprometido puede escanear y pivotar con libertad.

• Aplica una política default-deny en un namespace, y luego añade reglas ingress/egress explícitas que permitan solo los flujos que tu aplicación realmente necesita (p. ej. frontend a backend en un puerto).
• Advertencia crítica: las políticas de red las aplica el plugin CNI. Si tu CNI no las soporta (o asumes que un default no-op lo hace), la política no hace nada en silencio — una razón común de que una regla "deny" parezca ignorada.

Qué buscan los entrevistadores

Separar el RBAC (autorización de API) de las políticas de red (segmentación de tráfico), conocer ambos comportamientos por defecto (RBAC amplio, red que permite todo), y la dependencia del CNI que hace que las políticas de red no surtan efecto sin soporte.