Seguridad Kubernetes: lo que cubre el libro de Lapaz

Seguridad Kubernetes es uno de los temas más complejos del ecosistema cloud nativo, y el libro Learning Kubernetes Security, Second Edition de Raul Lapaz (Packt, junio 2026, 390 páginas) cubre desde admission controllers y runtime protection con Falco hasta supply chain security con Cosign, orientado a equipos DevOps y arquitectos cloud que necesitan hardening real en producción.

Qué es Learning Kubernetes Security: Segunda Edición

Learning Kubernetes Security es un libro técnico de 390 páginas publicado por Packt en junio de 2026, escrito por Raul Lapaz, ingeniero de seguridad especializado en Kubernetes que trabaja en Roche y tiene más de 25 años de experiencia en IT. La primera edición ya existía, pero esta segunda incorpora los cambios de seguridad por defecto que trajo Kubernetes 1.30 y temas que antes eran “nice to have” y hoy son estándar de industria: firma de imágenes, protección en runtime con eBPF, y seguridad en pipelines CI/CD.

El repositorio de GitHub del libro tiene ejemplos prácticos que podés clonar y probar directamente. No es un libro de conceptos abstractos: cada capítulo tiene laboratorios.

¿Para quién es? Para alguien que ya sabe qué es un Pod y un Deployment, pero que nunca configuró una política de red seria, nunca tocó OPA ni Kyverno, y que si le preguntás “¿cómo sabés que nadie corrió un shell dentro de un contenedor en producción?” la respuesta es “bueno… no sé”. Ese es el target.

Temas clave que cubre el libro

El índice cubre bastante terreno. Los ejes principales, según la descripción del propio autor y el repositorio oficial:

• Cambios de seguridad por defecto en Kubernetes 1.30+: qué viene activado out of the box y qué todavía tenés que configurar vos.
• Admission controllers (mutating y validating): el mecanismo de control de acceso granular que la mayoría de los equipos no usa bien.
• Supply chain security: firma de imágenes con Cosign, escaneo con Trivy, verificación de artefactos en el pipeline.
• Runtime protection: Falco y Tetragon usando eBPF para detectar comportamiento anómalo en tiempo real.
• Autenticación y autorización: RBAC, ABAC, OIDC, gestión de service accounts.
• Seguridad en CI/CD y Helm charts: cómo no arruinar todo lo anterior cuando deployás.
• GitOps security: porque si tu repo de GitOps está mal configurado, tenés un problema.
• Observabilidad de seguridad: audit policies, logging, integración con SIEM.
• Threat modeling con MITRE ATT&CK: cómo pensar como un atacante para defender mejor.

Son ocho áreas. Algunas tienen un capítulo, otras varios. El foco está puesto en lo que realmente duele en producción, no en explicar qué es kubectl por décima vez.

Admission Controllers: Control de Acceso Granular

Ponele que tenés RBAC bien configurado y un usuario solo puede crear Pods en su namespace. Perfecto. Pero ese Pod, ¿puede correr como root? ¿Puede montar el filesystem del host? ¿Puede usar privilegios del sistema operativo? RBAC no te cubre eso.

Ahí entran los admission controllers. Son webhooks que el API server llama antes de persistir un objeto. Los mutating admission controllers pueden modificar el objeto (agregar labels, inyectar sidecars, setear defaults de seguridad). Los validating admission controllers simplemente aprueban o rechazan. Si el objeto no cumple la política, el API server devuelve un 403 y chau. Esto se conecta con lo que vimos en los incidentes de disponibilidad.

El libro cubre Kyverno como herramienta principal para escribir estas políticas en YAML nativo de Kubernetes, sin necesidad de aprender Rego (el lenguaje de OPA). Para equipos que ya viven en YAML, Kyverno tiene una curva de adopción notablemente más corta.

Runtime Security: Falco y eBPF para Detección de Amenazas

La configuración estática te protege de lo que sabés que puede pasar. Runtime security te protege de lo que no sabés.

Falco usa eBPF para interceptar syscalls en el kernel del host. Cuando un proceso dentro de un contenedor intenta abrir una shell interactiva, escribir en /etc/passwd, o hacer una conexión saliente a una IP desconocida, Falco lo ve y puede alertar o bloquear. Todo esto sin modificar el contenedor ni instalar agentes dentro de cada imagen.

Un ejemplo concreto que el libro trabaja: privilege escalation. Si un proceso pasa de UID 1000 a UID 0 dentro de un contenedor (algo que no debería pasar nunca), Falco lo detecta en microsegundos. Sin Falco, ese evento quedaba invisible en tus logs de aplicación.

Tetragon, del proyecto Cilium, va un paso más allá usando eBPF para enforcement (no solo detección), pero requiere más configuración. El libro explica cuándo usar cada uno.

Supply Chain Security: De la Imagen al Clúster

Las imágenes de contenedor con vulnerabilidades conocidas son el vector de entrada más frecuente en clústeres Kubernetes comprometidos. El libro trata este problema con tres capas.

Primero, escaneo antes del deploy: Trivy analiza la imagen buscando CVEs conocidos en los paquetes del SO y dependencias de la aplicación. Esto va en el pipeline de CI, antes de que la imagen llegue al registry.

Segundo, firma y verificación con Cosign: la imagen firmada tiene una firma criptográfica que el clúster puede verificar antes de correrla. Si la imagen fue modificada después de ser firmada (o si alguien sustituyó la imagen en el registry), la verificación falla. Para más detalles técnicos, mirá en nuestro artículo sobre containerización.

Tercero, admission controllers que rechazan imágenes sin firma válida. El círculo se cierra: no podés deployar algo que no pasó por tu pipeline y fue firmado por tu sistema de CI.

¿Alguien verificó que esto funciona en la práctica ante un ataque real de supply chain? Los casos documentados de ataques a registries públicos (como el de Docker Hub en 2023 con imágenes troyanizadas) muestran que la mayoría de los equipos todavía no tiene ninguna de estas tres capas implementadas.

RBAC y Gestión de Identidades: Principio de Menor Privilegio

El error más frecuente que veo en clústeres de producción: service accounts bindeadas a cluster-admin. Normalmente pasa porque alguien necesitaba que algo funcionara rápido, le dio todos los permisos, y nadie lo volvió a tocar.

RBAC (Role-Based Access Control) es el mecanismo de autorización por defecto desde Kubernetes 1.8. La diferencia con ABAC (Attribute-Based Access Control, el anterior) es que RBAC usa Roles y ClusterRoles definidos como objetos de Kubernetes, auditables en git y aplicables con kubectl. ABAC requería reiniciar el API server para aplicar cambios.

La práctica que el libro recomienda: cada workload tiene su propio ServiceAccount con exactamente los permisos que necesita. Nada más. Si tu aplicación solo lee ConfigMaps de su propio namespace, ese ServiceAccount no necesita poder leer Secrets ni de lejos.

OIDC entra cuando querés federar la autenticación con un proveedor externo (Azure AD, Google Workspace, Okta). En vez de crear usuarios locales de Kubernetes, el clúster confía en tokens emitidos por el IDP. Para equipos medianos para arriba, esto simplifica bastante la gestión de accesos.

Secretos, Certificados y Criptografía

Los Secrets de Kubernetes, por defecto, solo están codificados en base64 en etcd. Base64 no es encriptación. Si alguien tiene acceso al etcd, tiene acceso a todos tus secrets en texto plano. Lo explicamos a fondo en automatizar despliegues de manera segura.

El libro cubre dos enfoques para esto. El primero es la encriptación en reposo de etcd: configurás el API server con un EncryptionConfiguration que especifica qué recursos encriptar y con qué proveedor (AES-CBC, AES-GCM, o un KMS externo). El segundo es usar external secret managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) con el External Secrets Operator, que sincroniza los secrets del vault externo a objetos de Kubernetes.

El TLS entre componentes del clúster también tiene su sección. Kubernetes genera sus propios certificados durante el bootstrap (con kubeadm), pero esos certificados tienen vencimiento. Si no tenés un proceso de rotación automática, en algún momento el clúster va a fallar silenciosamente o va a dejar de aceptar conexiones. (Sí, pasa. Y generalmente pasa en el peor momento.)

Comparativa de herramientas de seguridad cubiertas

Aplicabilidad para Equipos en Latinoamérica

El libro está disponible en inglés en Packt, O’Reilly, Amazon y VitalSource. No hay versión en español por ahora.

Para equipos que corren Kubernetes en AWS, Azure o GCP desde Argentina o el resto de Latinoamérica, el contenido es directamente aplicable. Los proveedores de cloud tienen sus propias capas de seguridad encima (IAM roles para pods en EKS, Workload Identity en GKE), pero los conceptos de admission controllers, Falco y supply chain security son agnósticos al cloud.

Si tu equipo está preparando la certificación CKS (Certified Kubernetes Security Specialist), el libro cubre prácticamente todo el temario. La CKS es la certificación más técnica del ecosistema Kubernetes y requiere la CKA como prerequisito.

Para infraestructura on-premise, si la empresa tiene sus propios servidores o usa un proveedor local, el endurecimiento del clúster es más importante todavía porque no hay capas de seguridad gestionadas del cloud provider. En esos casos, cada componente que el libro describe se convierte en responsabilidad del equipo interno. Si además necesitás hosting confiable para exponer servicios web que interactúan con tu infraestructura Kubernetes, donweb.com tiene opciones de cloud y VPS para esa capa.

Errores Comunes de Seguridad en Kubernetes

Correr contenedores como root sin necesidad

La mayoría de las imágenes en Docker Hub corren como root por defecto. No porque sea necesario: es porque es lo más fácil al escribir el Dockerfile. En producción, correr como root dentro del contenedor significa que si hay una vulnerabilidad de escape de contenedor, el atacante llega al host con privilegios. La corrección es sencilla: securityContext.runAsNonRoot: true en el spec del Pod, y construir la imagen con un usuario sin privilegios.

No tener NetworkPolicies configuradas

Por defecto, todos los Pods en un clúster Kubernetes pueden comunicarse entre sí, en cualquier dirección. Si tu base de datos y tu frontend están en el mismo clúster sin NetworkPolicies, un atacante que comprometa el frontend tiene acceso directo a la base de datos. Definir NetworkPolicies de deny-all por defecto y luego abrir solo el tráfico necesario es un cambio que lleva menos de una hora y reduce drásticamente la superficie de ataque lateral.

Ignorar los audit logs del API server

El API server de Kubernetes puede registrar todas las operaciones que se hacen sobre el clúster: quién creó qué, quién borró qué, quién intentó acceder a qué y falló. Por defecto, este logging está desactivado o configurado en nivel mínimo. Sin audit logs, si alguien accede ilegítimamente al clúster, no hay forma de saber qué hicieron ni cuándo. Configurar una audit policy básica y enviar los logs a un SIEM es algo que el libro cubre en detalle. En auditoría de seguridad en producción profundizamos sobre esto.

Usar la misma service account para todo

Si todos tus workloads usan la default service account (o una service account compartida con permisos amplios), cualquier compromiso de cualquier Pod puede escalar al resto del clúster. El principio de menor privilegio aplicado a service accounts significa crear una por workload y darle exactamente los permisos que necesita para funcionar, verificados en la práctica y no estimados.

Preguntas Frecuentes

¿Qué es el libro Learning Kubernetes Security y qué cubre?

Learning Kubernetes Security, Second Edition es un libro técnico de 390 páginas publicado por Packt en junio de 2026, escrito por Raul Lapaz. Cubre seguridad en Kubernetes 1.30+, incluyendo admission controllers, runtime protection con Falco y eBPF, supply chain security con Cosign y Trivy, RBAC con OIDC, secretos cifrados en etcd, y threat modeling con MITRE ATT&CK. Está dirigido a DevOps engineers y arquitectos cloud con conocimientos básicos de Kubernetes.

¿Cuáles son las mejores prácticas de seguridad en Kubernetes?

Las prácticas fundamentales son: correr contenedores como usuario no root, configurar NetworkPolicies de deny-all por defecto, usar admission controllers para enforcement de políticas, escanear imágenes antes del deploy, firmar imágenes con Cosign, configurar RBAC con principio de menor privilegio (una service account por workload), y activar audit logging del API server. Según la documentación oficial de Kubernetes, la seguridad se piensa en cuatro capas: cloud/co-located infrastructure, cluster, container, y code.

¿Cómo implementar seguridad en un clúster Kubernetes de producción?

El orden práctico es: primero configurar RBAC y eliminar permisos excesivos en service accounts, después implementar NetworkPolicies, luego agregar admission controllers con Kyverno para políticas de seguridad de Pods, incorporar Falco para detección en runtime, y finalmente integrar escaneo y firma de imágenes en el pipeline CI/CD. No es un proceso de un día: cada capa puede introducirse gradualmente sin interrumpir el clúster existente.

¿Qué herramientas usar para asegurar Kubernetes?

Para admission control: Kyverno (políticas en YAML) u OPA/Gatekeeper (políticas en Rego). Para runtime security: Falco (detección) o Tetragon (enforcement). Para supply chain: Trivy (escaneo de vulnerabilidades) y Cosign (firma de imágenes). Para secrets: External Secrets Operator integrado con HashiCorp Vault o el secret manager del cloud provider. Para auditoría: herramientas como kube-bench verifican el clúster contra el benchmark CIS Kubernetes.

¿Cuáles son los errores más comunes de seguridad en Kubernetes?

Los más frecuentes son: contenedores corriendo como root, service accounts con permisos de cluster-admin, ausencia de NetworkPolicies (todos los Pods se comunican entre sí por defecto), secrets en base64 sin encriptación en etcd, imágenes sin escaneo de vulnerabilidades en el pipeline, y falta de audit logging. Según el análisis de Wiz, las misconfiguraciones en RBAC y la exposición de la API de Kubernetes son los vectores de ataque más explotados.

Conclusión

Learning Kubernetes Security, Segunda Edición no es el primer libro sobre el tema, pero la combinación de cobertura actualizada a Kubernetes 1.30+, el enfoque práctico con laboratorios en GitHub, y el hecho de que esté escrito por alguien que trabaja con esto en una empresa grande de verdad (no en un startup de cinco personas), lo pone en un lugar distinto.

Si corrés Kubernetes en producción y tu respuesta honesta a “¿cómo tenés configurada la seguridad del clúster?” es “más o menos bien, creo”, este libro es para vos. Si estás preparando la CKS, también. Si ya tenés todo esto implementado y lo revisás trimestralmente, probablemente encuentres más valor en papers específicos de Falco o Tetragon que en un libro introductorio-intermedio.

La seguridad de Kubernetes dejó de ser opcional hace rato. La pregunta ahora no es si hacerlo, sino por dónde arrancar. El libro da una respuesta razonablemente buena a eso.

Fuentes

• Packt Publishing – Learning Kubernetes Security, Second Edition (página oficial del libro)
• GitHub – Repositorio oficial con ejemplos prácticos del libro
• Kubernetes.io – Visión general de seguridad en Kubernetes (documentación oficial)
• Wiz Academy – Problemas comunes de seguridad en Kubernetes
• Raul Lapaz – Artículo del autor sobre el libro en Medium