Mejores prácticas de seguridad de Kubernetes: endurecimiento desde la compilación hasta el tiempo de ejecución

Kubernetes se entrega con configuraciones predeterminadas permisivas, por lo que la seguridad del clúster es su responsabilidad. Conozca las mejores prácticas de seguridad de Kubernetes en las fases de compilación, implementación y tiempo de ejecución.

¿Qué es la seguridad de Kubernetes?

La seguridad de Kubernetes es el conjunto de controles que se aplican en la compilación, el despliegue y el tiempo de ejecución para proteger un clúster, las cargas de trabajo que ejecuta y la canalización que lo alimenta. Sin ellos, una sola solicitud no autenticada puede tomar el control de todo el clúster. Eso fue IngressNightmare, la falla de gravedad 9.8 divulgada en marzo de 2025 en ingress-nginx, el controlador que se ejecuta en más del 40% de los clústeres de Kubernetes.

Su webhook de admisión estaba en la red de pods sin autenticación, e ingress-nginx lee cada Secret del clúster de forma predeterminada. Alcance la red, aduéñese del clúster. No requirió una cadena de explotación ni una contraseña robada: solo valores predeterminados permisivos haciendo lo que estaban configurados para hacer.

Esa brecha, entre lo que Kubernetes incluye y lo que necesita un clúster de producción, es lo que corrige el endurecimiento. Las mejores prácticas de seguridad de Kubernetes son la forma de cerrarla, fase por fase, desde la imagen que compila hasta la carga de trabajo que ejecuta. Debido a que la orquestación centraliza sus cargas de trabajo, secretos y tráfico este-oeste en un único plano de control, una sola configuración incorrecta puede exponer cada servicio que ejecuta, por lo que ese trabajo recae en usted y no en la plataforma.

¿Por qué es importante la seguridad de Kubernetes?

Kubernetes no se endurece por sí solo. La guía de endurecimiento de Kubernetes de CISA/NSA documenta tres valores predeterminados reveladores en cada clúster nuevo: el inicio de sesión anónimo en el servidor API está habilitado, los Secrets se almacenan sin cifrar en etcd y el registro de auditoría está desactivado. El modelo de responsabilidad compartida pone cuatro controles en sus manos: control de acceso basado en roles (RBAC), política de red, cifrado de secretos y controles de tiempo de ejecución. El proveedor de nube no los configurará por usted, y la distribución tampoco. Debido a que esos controles viven en su configuración y cambian con el tiempo, los equipos verifican cada vez más su estado de forma continua con gestión de la postura de seguridad de Kubernetes en lugar de auditarlos manualmente.

Un atacante que alcance un servidor API no autenticado puede leer cada Secret en etcd, programar un pod en cualquier nodo y moverse entre espacios de nombres mientras el registro de auditoría permanece en silencio, por lo que la primera señal que reciba puede ser la propia brecha, el mismo patrón que siguió IngressNightmare.

Lo que está en juego aumenta con la adopción. La encuesta anual Cloud Native de la Cloud Native Computing Foundation (CNCF) informa que el 82% de los usuarios de contenedores ahora ejecutan Kubernetes en producción, frente al 66% en 2023. A medida que los clústeres se sitúan en la ruta de servicios orientados al cliente, datos regulados y obligaciones de auditoría, un solo control omitido se convierte en exposición a brechas, auditorías fallidas e incidentes notificables por los que su equipo tendrá que responder. Saber qué está en juego solo importa una vez que sabe qué partes del clúster conllevan ese riesgo.

Componentes principales de un clúster de Kubernetes

No puede endurecer lo que no ha inventariado. Cada componente conlleva una exposición de seguridad específica, y comprender esa exposición le indica dónde deben aplicarse sus controles.

Componentes del plano de control:

• Servidor API: Cada comando kubectl que ejecuta, cada webhook de admisión y cada solicitud de token de cuenta de servicio pasa por el servidor API. El acceso no autorizado aquí significa control total del clúster.
• etcd: Almacena todo el estado del clúster, la configuración y los Secrets de los que depende. El acceso de lectura a etcd es funcionalmente equivalente a root en todo el clúster.
• Programador y administrador de controladores: Un programador comprometido puede colocar cargas de trabajo en nodos específicos para explotar recursos locales. La manipulación de controladores puede alterar despliegues, recuentos de réplicas y asignaciones de recursos de forma silenciosa.

Componentes del nodo de trabajo:

• kubelet: El agente en cada nodo que ejecuta especificaciones de pod. Si deja expuesta la API de kubelet, un atacante puede crear contenedores o ejecutar comandos directamente en el nodo.
• kube-proxy: Administra reglas de red para el enrutamiento de servicios. Las reglas de proxy mal configuradas pueden exponer sus servicios internos al tráfico externo.
• Tiempo de ejecución de contenedores: Ejecuta contenedores en el host. Un tiempo de ejecución vulnerable expone cada contenedor que admite y el propio host, como señala NIST SP 800-190.

Pods, contenedores y redes:

• Los pods comparten espacios de nombres de red, por lo que un contenedor comprometido en un pod puede acceder a otros contenedores del mismo pod sin controles de red. Sin objetos NetworkPolicy, sus pods en distintos espacios de nombres se comunican libremente de forma predeterminada. 
• Las imágenes de contenedor y las plantillas de infraestructura como código (IaC) entran en su clúster desde registros externos, y una imagen contaminada incorporada a producción se propaga a cada nodo que la programa. Asignar cada componente a su exposición le indica exactamente dónde se aplican los controles de endurecimiento de esta guía.

Cómo funciona la seguridad de Kubernetes en todo el ciclo de vida desde la compilación hasta el tiempo de ejecución

La seguridad de Kubernetes se implementa mediante un flujo de trabajo continuo, no con una comprobación puntual. Cada fase aplica una categoría distinta de control, y la salida de una fase se convierte en la entrada de la siguiente. Esto es lo que ocurre en cada paso.

1. Tiempo de compilación: Escanea imágenes de contenedor en busca de vulnerabilidades conocidas, valida plantillas de IaC frente a políticas, firma imágenes criptográficamente y genera una lista de materiales de software (SBOM). Estos controles preventivos detienen los problemas en el origen, antes de que cualquier artefacto pueda programarse.
2. Desplegar y configurar: Cuando envía una carga de trabajo, los controladores de admisión la evalúan frente a la política antes de programarla. RBAC determina quién puede crear, modificar o leer recursos, y las políticas de red definen qué pods pueden comunicarse. La imagen que firmó durante la compilación solo está protegida aquí si el control de admisión realmente verifica la firma.
3. Configuración del plano de control y de los nodos: Configura el servidor API, etcd, kubelet y el sistema operativo del nodo para reducir lo que queda expuesto. La autenticación, la autorización y el cifrado establecen el límite de confianza del que depende cada otra fase, por lo que un plano de control débil debilita todo lo que viene después.
4. Tiempo de ejecución: Las herramientas de supervisión observan anomalías de comportamiento, deriva de configuración y patrones de ataque conocidos en sus cargas de trabajo en ejecución, mientras que los perfiles seccomp y AppArmor restringen qué llamadas al sistema pueden realizar sus contenedores. El tiempo de ejecución también es donde detecta las brechas que la compilación y el despliegue pasaron por alto.

Cierra el ciclo cuando los hallazgos del tiempo de ejecución retroalimentan su fase de compilación como imágenes actualizadas, IaC actualizada y política de admisión actualizada. El ciclo de vida solo funciona cuando cada transferencia se mantiene. Esto es lo que cuesta una transferencia fallida.

Impacto de un clúster de Kubernetes comprometido

Cuando su clúster se ve comprometido, las consecuencias van mucho más allá de una sola carga de trabajo.

• Movimiento lateral y radio de impacto: Sus clústeres ejecutan desde decenas hasta miles de pods que comparten conectividad de red. Un atacante que obtiene acceso a uno de sus pods puede moverse lateralmente entre espacios de nombres y nodos cuando RBAC tiene privilegios excesivos y faltan políticas de red.
• Exposición de secretos: etcd contiene sus claves de API, credenciales de bases de datos, certificados TLS y tokens de servicio. Debido a que los Secrets no están cifrados de forma predeterminada, un atacante con acceso de lectura a etcd puede extraer cada credencial de su clúster.
• Propagación en la cadena de suministro: Una imagen de contenedor contaminada desplegada a través de su canalización de integración continua y entrega continua (CI/CD) llega a cada nodo que la programa. En clústeres que ejecutan cientos de réplicas, una sola imagen comprometida puede ejecutar código malicioso en toda su infraestructura en cuestión de minutos.
• Compromiso de cargas de trabajo y datos: Sus bases de datos de producción, aplicaciones orientadas al cliente y servicios internos se ejecutan lado a lado. Una brecha en una carga de trabajo puede exponer datos sensibles, interrumpir la disponibilidad del servicio o establecer persistencia para futuros ataques.
• Exposición de cumplimiento y normativa: Si sus clústeres procesan datos de pago, historiales médicos o cargas de trabajo gubernamentales, quedan sujetos a los requisitos de PCI DSS, HIPAA, FedRAMP y SOC 2. Un clúster mal configurado que no supere una auditoría puede dar lugar a interrupciones operativas y sanciones financieras.

El endurecimiento reduce el radio de impacto de cualquier compromiso individual, acorta los plazos de respuesta a incidentes y genera la evidencia de auditoría que requiere su programa de cumplimiento. Lograrlo en la práctica es más difícil de lo que parece, por razones específicas de cómo funciona Kubernetes.

Desafíos para proteger Kubernetes

La seguridad de Kubernetes es operativamente difícil, incluso para los miembros más experimentados de su equipo. La naturaleza efímera de la plataforma, su modelo de configuración declarativa y su arquitectura distribuida crean fricción que las herramientas de seguridad estáticas no fueron diseñadas para manejar.

• Cargas de trabajo efímeras y en constante cambio: Los pods se crean, destruyen y reprograman continuamente. Una instantánea de la postura de su clúster a las 9:00 a. m. puede no reflejar su estado a las 9:05 a. m.
• Brechas de visibilidad en contenedores en ejecución: Los contenedores comparten el kernel del host, pero aíslan sus procesos, sistemas de archivos y pilas de red. Las herramientas estándar de supervisión basadas en host a menudo carecen del contexto para distinguir el comportamiento normal del contenedor de la actividad maliciosa.
• Complejidad de configuración y deriva: Un clúster de producción implica cientos de manifiestos YAML, enlaces RBAC y reglas de admisión. La deriva entre lo que declara en Git y lo que se ejecuta en su clúster introduce exposición no rastreada.
• Expansión de múltiples clústeres y múltiples nubes: Si ejecuta clústeres en Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP) y entornos locales, debe aplicar una política coherente en distintos servicios administrados, cada uno con su propio límite de responsabilidad compartida.
• Herramientas fragmentadas: El escaneo de imágenes, la gestión de RBAC, la aplicación de políticas de red, la supervisión en tiempo de ejecución y los informes de cumplimiento suelen requerir herramientas separadas sin un modelo de datos compartido. La correlación de alertas recae en usted.
• Habilidades especializadas y fricción organizativa: Las habilidades especializadas son escasas, y la encuesta CNCF de 2025 encontró que, por primera vez, la principal barrera para la adopción cloud native es organizativa y no técnica: comunicación interna, dinámica de equipo y alineación del liderazgo. Los controles no se aplican porque nadie es responsable de ellos.

Estas limitaciones determinan tanto sus elecciones de herramientas como sus prioridades de contratación, y explican por qué los mismos errores se repiten en los clústeres.

Errores comunes de seguridad en Kubernetes

Antipatrones específicos de los operadores crean las exposiciones que los atacantes explotan. Identifique y elimine cada uno de estos en sus clústeres:

• Ejecutar contenedores privilegiados o como root. Los contenedores privilegiados eluden todo el aislamiento del kernel de Linux. Un contenedor que se ejecuta como root con allowPrivilegeEscalation: true puede escapar al host.
• Conceder cluster-admin o RBAC con comodines. Los permisos con comodines (resources: ["*"], verbs: ["*"]) se extienden automáticamente a recursos de API que aún no existen. La documentación de Kubernetes etiqueta este patrón como "DO NOT USE."
• Dejar la red predeterminada de permitir todo. Sin objetos NetworkPolicy, sus pods en distintos espacios de nombres se comunican libremente.
• Almacenar Secrets en manifiestos en texto sin formato. Confirmar credenciales en Git o pasarlas como variables de entorno las expone en volcados por fallos, registros e historial del shell.
• Omitir el escaneo de imágenes e IaC. Desplegar imágenes no escaneadas permite que las vulnerabilidades lleguen a producción sin control.
• Tratar el endurecimiento como una compuerta única. Un clúster endurecido en el arranque deriva a medida que sus equipos agregan cargas de trabajo y modifican configuraciones. Sin aplicación continua, la postura se degrada.
• Ignorar la configuración de nodos y del plano de control. Dejar habilitado el inicio de sesión anónimo en el servidor API, omitir el cifrado de etcd y no incluir el registro de auditoría son estados predeterminados que requieren su corrección explícita.

Cada uno de estos problemas puede corregirse con las prácticas siguientes. Trátelos como una lista de verificación de exposiciones que debe retirar antes de escalar cargas de trabajo adicionales al clúster.

Mejores prácticas de seguridad de Kubernetes

Estas mejores prácticas de seguridad de Kubernetes forman el núcleo operativo del endurecimiento de clústeres de Kubernetes, organizadas según las mismas cuatro fases del ciclo de vida presentadas anteriormente. Recorra cada una en orden, porque cada fase supone que la anterior se mantiene.

Protección de la fase de compilación

1. Escanee imágenes en busca de vulnerabilidades antes de que lleguen a un registro. Integre el escaneo de imágenes de contenedor en sus canalizaciones de CI para que las imágenes vulnerables nunca se conviertan en artefactos desplegables.
2. Use imágenes base mínimas o distroless. Las imágenes distroless contienen solo su aplicación y sus dependencias de tiempo de ejecución, sin shell, gestor de paquetes ni binarios innecesarios. Fije las imágenes a sufijos de versión explícitos (e.g., gcr.io/distroless/static-debian13) y nunca use la latest tag.
3. Firme y verifique imágenes. Use Cosign o Notary para firmar imágenes en CI. Configure controladores de admisión para rechazar imágenes sin firmar o no verificadas en el momento del despliegue.
4. Escanee IaC y manifiestos de Kubernetes. Valide Terraform, gráficos Helm y YAML sin procesar frente a la política de seguridad antes de que lleguen a su clúster.
5. Genere un SBOM para cada imagen a fin de establecer procedencia y respaldar el seguimiento de vulnerabilidades después del despliegue.
6. Mantenga los secretos fuera de las imágenes. Nunca incorpore credenciales, claves de API ni certificados en imágenes de contenedor o Dockerfiles.

Estos controles de la fase de compilación mantienen los artefactos vulnerables y sin firmar fuera de la canalización antes de que nada pueda ejecutarse. Una imagen que los supera sigue siendo segura solo si el clúster la admite correctamente, y ahí es donde toma el relevo la configuración en tiempo de despliegue.

Endurecimiento de la configuración y el despliegue del clúster

Estas mejores prácticas de Kubernetes RBAC y controles de red convierten la política de tiempo de despliegue en barreras de protección aplicadas.

1. Aplique RBAC de privilegio mínimo. Cree Roles con ámbito de espacio de nombres con verbos y nombres de recursos explícitos. Elimine concesiones con comodines. Restrinja cluster-admin al uso de emergencia. Establezca automountServiceAccountToken: false en cuentas de servicio que no necesiten acceso a la API.

2. Aplique políticas de red de denegación predeterminada. Aplique una Netwenforce mode with the restrictedorkPolicy default-deny-all, tanto de ingreso como de egreso, a cada espacio de nombres en el arranque. Agregue reglas explícitas de permiso por carga de trabajo, incluida una excepción de egreso DNS en el puerto UDP 53.

3. Aplique el estándar Restricted Pod Security Standard. Use Pod Security Admission en modo enforce con el restricted level para espacios de nombres de producción. Esto bloquea contenedores privilegiados, requiere runAsNonRoot, exige perfiles seccomp y restringe tipos de volumen.

4. Agregue control de admisión con OPA Gatekeeper o Kyverno. Aplique readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, listas de permitidos de registros de imágenes y políticas de eliminación de todas las capacidades. Use primero el modo dryrun para auditar las cargas de trabajo existentes antes de cambiar a deny.

5. Administre Secrets en un almacén externo con cifrado de etcd en reposo. Use el proveedor v2 del servicio de gestión de claves (KMS) para cifrado de sobre, y monte Secrets como volúmenes mediante Secrets Store CSI Driver, que usa tmpfs para que los datos secretos nunca lleguen al disco del nodo. Evite pasar Secrets como variables de entorno.

6. Establezca límites de recursos. Defina solicitudes y límites de CPU y memoria en cada contenedor para evitar el agotamiento de recursos.

Con la política de tiempo de despliegue aplicada, sus cargas de trabajo se ejecutan con privilegio mínimo y redes de denegación predeterminada. La confianza de la que dependen esas barreras sigue residiendo en el plano de control y en los nodos subyacentes, así que endurézcalos a continuación.

Protección del plano de control y de los nodos de trabajo

El plano de control es el único lugar donde una sola configuración débil afecta a todo lo demás. Configure cada uno de estos elementos y luego verifíquelos según una programación, en lugar de hacerlo una sola vez en el arranque.

Paso de endurecimiento	Qué configurar	Fuente
Acceso al servidor API	Exija autenticación sólida y TLS mutuo; mantenga el servidor API fuera de la internet pública.	CIS Benchmark
Autenticación anónima	Establezca --anonymous-auth=false	Guía de CISA/NSA
Registro de auditoría	Habilite registros de auditoría de API, métricas, aplicaciones y seccomp; agréguelos fuera del clúster y genere alertas sobre ellos	Guía de CISA/NSA
etcd	Cifre en reposo, exija TLS mutuo y aíslelo detrás de un firewall al que solo puedan acceder los servidores API	CIS Benchmark
kubelet	Restrinja el acceso a la API, deshabilite puertos de solo lectura y aplique configuraciones a nivel de nodo	CIS Benchmark
Línea base del nodo	Alinee el plano de control, etcd y los nodos con el CIS Kubernetes Benchmark para su versión; escanee con una cadencia continua	CIS Benchmark
Versiones	Aplique parches a Kubernetes, al sistema operativo del nodo y al tiempo de ejecución de contenedores con una cadencia regular	—

Con el plano de control bloqueado y los nodos parcheados, la base se mantiene. Una carga de trabajo activa aún puede desviarse de su estado declarado o ser atacada desde dentro, y los controles de tiempo de ejecución son los que detectan eso.

Seguridad en tiempo de ejecución y detección de amenazas

Una sólida seguridad de Kubernetes en tiempo de ejecución detecta lo que los controles estáticos no pueden.

1. Supervise el comportamiento en tiempo de ejecución. Despliegue una herramienta de seguridad en tiempo de ejecución nativa para contenedores que observe llamadas al sistema anómalas, ejecución inesperada de procesos, conexiones de red y modificaciones de archivos. NIST SP 800-190 afirma que las herramientas tradicionales de sistema de prevención de intrusiones (IPS) y firewall de aplicaciones web (WAF) no proporcionan una protección adecuada para contenedores.
2. Detecte la deriva de configuración. Compare las cargas de trabajo en ejecución con su estado declarado en Git. Marque los contenedores que se hayan desviado de su imagen o configuración original.
3. Aplique perfiles seccomp y AppArmor o SELinux. Use perfiles seccomp RuntimeDefault como mínimo. Implemente primero perfiles personalizados en un subconjunto de nodos y luego amplíelos a todo el clúster tras la validación.
4. Ejecute sistemas de archivos raíz de solo lectura y elimine capacidades innecesarias. Establezca readOnlyRootFilesystem: true y capabilities: drop: [ALL] en cada contenedor de producción.
5. Aplique runAsNonRoot. Exija runAsNonRoot: true en los contextos de seguridad de los pods. Compile imágenes para ejecutarse como un usuario no root en tiempo de compilación en lugar de depender únicamente de anulaciones en tiempo de despliegue.
6. Habilite respuesta autónoma y registro continuo de auditoría. Correlacione alertas de tiempo de ejecución con registros de auditoría para reconstruir cronologías de ataque. Retroalimente los hallazgos en la política de tiempo de compilación para cerrar el ciclo.

En conjunto, estas cuatro fases producen un clúster endurecido de forma continua. Los puntos de referencia del sector describen cómo se ve una configuración correcta en cada fase, y debe medir su clúster frente a ellos.

Estándares de seguridad y cumplimiento de Kubernetes

Los puntos de referencia reconocidos por la industria operacionalizan las prácticas descritas anteriormente y proporcionan la evidencia de auditoría que requiere su programa de cumplimiento de Kubernetes.

Estándar	Alcance	Relevancia
CIS Kubernetes Benchmark	Plano de control, etcd, nodos de trabajo, políticas	Reconocido por PCI DSS, FedRAMP, SOC 2, FISMA y el NIST National Checklist Program
CISA/NSA Kubernetes Hardening Guidance	Compilación, despliegue, red, RBAC, registro, tiempo de ejecución	Línea base gubernamental autorizada para clústeres federales y de infraestructura crítica
Pod Security Standards	Restricciones de privilegios a nivel de pod en tres niveles	Mecanismo de aplicación integrado de Kubernetes; se asigna directamente a la Tabla I de la guía de CISA/NSA
NIST SP 800-190	Seguridad del ciclo de vida de contenedores	Asigna controles de contenedores a NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4 y otros)

Ahora que Kubernetes es la plataforma de producción predeterminada, los marcos de cumplimiento tratan cada vez más los controles específicos de Kubernetes como un dominio de auditoría diferenciado en lugar de un subconjunto de la seguridad general de la infraestructura. 

Los puntos de referencia específicos de plataforma, como el CIS GKE Benchmark y el CIS OpenShift Benchmark, amplían el punto de referencia general con controles específicos de servicios administrados. Conocer los estándares es la línea base. La pregunta más difícil es hacia dónde se dirige la seguridad de Kubernetes a continuación.

Tendencias futuras en la seguridad de Kubernetes

Los controles que despliega hoy se asientan sobre un terreno cambiante, y tres tendencias están remodelando la forma en que los equipos abordan las mejores prácticas de seguridad de Kubernetes.

1. Las cargas de trabajo de IA desplazan la superficie de ataque. A medida que los clústeres se convierten en el hogar predeterminado de las cargas de trabajo de IA y aprendizaje automático, la programación de GPU, los artefactos de modelos y los grandes conjuntos de datos de entrenamiento se convierten en nuevos objetivos. Proteger la cadena de suministro de datos y modelos se está convirtiendo en parte del endurecimiento del clúster, no en una preocupación aparte.
2. La integridad de la cadena de suministro de software se vuelve obligatoria. La generación de SBOM, los artefactos firmados y la atestación de procedencia están pasando de ser marcadores opcionales de madurez a expectativas básicas en industrias reguladas y adquisiciones gubernamentales.
3. La defensa autónoma en tiempo de ejecución sustituye al triaje manual. El volumen y la velocidad de la actividad del clúster superan la revisión humana. La IA conductual que distingue la actividad normal de la anómala en las cargas de trabajo, y responde sin esperar a un analista, está pasando de ser un diferenciador a ser lo predeterminado.

Cada tendencia apunta en la misma dirección: más automatización antes en el ciclo de vida y más autonomía en tiempo de ejecución, que es donde las herramientas de plataforma se ganan su lugar.

Fortalezca la seguridad de Kubernetes con SentinelOne

Los controles nativos de Kubernetes que cubre esta guía, RBAC, NetworkPolicy, Pod Security Standards, cifrado de etcd y registro de auditoría, forman la base del endurecimiento del clúster. SentinelOne añade gestión de postura, escaneo de la cadena de suministro, control de admisión de K8s y detección de amenazas en tiempo de ejecución por encima, cada uno asignado a una debilidad que esta guía identifica.

Singularity Cloud Security escanea clústeres de Kubernetes antes de que lleguen a ejecutarse. El escaneo en tiempo de compilación se integra directamente con canalizaciones de CI/CD, sistemas de control de versiones y registros de contenedores. Comprueba vulnerabilidades conocidas y más de 750 tipos de secretos expuestos. El mismo escaneo cubre plantillas de infrastructure-ascode, incluidas Terraform, Helm, CloudFormation y Kubernetes YAML, para detectar infracciones de políticas de forma temprana. Un Kubernetes Admission Controller actúa como guardián final en el servidor API, bloqueando imágenes no autorizadas o conocidas como maliciosas antes de que se desplieguen.

Kubernetes Security Posture Management (KSPM) cierra las brechas de visibilidad en todo el clúster. Construye un inventario unificado entre clústeres, nodos, espacios de nombres y despliegues, y luego muestra accesos demasiado permisivos y configuraciones de riesgo. Luego, el Offensive Security Engine™ simula ataques del mundo real y confirma mediante Verified Exploit Paths™ qué configuraciones incorrectas pueden alcanzar realmente los atacantes. Los equipos de seguridad priorizan lo explotable en lugar de clasificar cada hallazgo. El mismo motor de reglas impulsa el Admission Controller, por lo que la política se mantiene coherente desde la postura hasta el despliegue.

En tiempo de ejecución, Singularity Cloud Workload Security, basado en extended Berkeley Packet Filter (eBPF), detecta comportamiento anómalo a velocidad de máquina. Las respuestas automatizadas eliminan procesos maliciosos y ponen en cuarentena archivos infectados sin esperar a un analista. Graph Explorer visualiza las relaciones en toda la superficie de ataque de Kubernetes, para que los equipos vean exactamente qué está expuesto. Cuando la detección en tiempo de ejecución marca una imagen maliciosa, ese hallazgo se retroalimenta automáticamente al Admission Controller. La imagen queda entonces bloqueada para cualquier despliegue futuro, convirtiendo una detección en una política duradera. Purple AI aporta búsqueda de amenazas en lenguaje natural y resúmenes de eventos a su telemetría de cargas de trabajo en la nube en un único lago de datos, para que los analistas consulten en lenguaje natural en lugar de alternar entre herramientas.

Vea dónde están expuestos sus clústeres en producción. Solicite una demostración de SentinelOne para recorrer la gestión de postura de Kubernetes y la detección de amenazas en tiempo de ejecución en su propio entorno.

Realizar un recorrido

Protección de cargas de trabajo en la nube impulsada por IA (CWPP) para servidores, máquinas virtuales y contenedores, que detecta y detiene amenazas en tiempo de ejecución en tiempo real.

Conclusiones clave

Kubernetes se entrega con valores predeterminados permisivos que dejan la seguridad del clúster en sus manos. Las mejores prácticas de seguridad de Kubernetes de esta guía abarcan cuatro fases: escaneo y firma de imágenes en la compilación, RBAC y NetworkPolicy en el despliegue, cifrado de etcd y registro de auditoría en el plano de control, y supervisión del comportamiento en tiempo de ejecución. 

Alinee su configuración con el CIS Benchmark y la guía de CISA/NSA, elimine los errores comunes identificados anteriormente y cierre el ciclo retroalimentando los hallazgos del tiempo de ejecución en la política de tiempo de compilación. Cuando lo logre, dejará de adivinar. Podrá señalar cualquier espacio de nombres en cualquier día y mostrar qué se aplica, qué derivó y qué hizo al respecto.

Preguntas frecuentes

¿Qué configuraciones de Kubernetes son inseguras de forma predeterminada?

Tres configuraciones se entregan de forma insegura en cada nuevo clúster de Kubernetes. La guía Kubernetes Hardening Guidance v1.2 de CISA/NSA las documenta: el inicio de sesión anónimo en el servidor API está habilitado, los Secrets se almacenan sin cifrar en etcd y el registro de auditoría está deshabilitado. 

La comunicación entre pods no está restringida sin objetos NetworkPolicy. Debe endurecer estas configuraciones usted mismo. Ni el proveedor de nube ni la distribución de Kubernetes aplican estos controles por usted bajo el modelo de responsabilidad compartida.

¿Cuál es la diferencia entre la seguridad de Kubernetes y la seguridad de contenedores?

La seguridad de contenedores y la seguridad de Kubernetes operan en diferentes capas de la misma pila. La seguridad de contenedores se centra en la imagen y la instancia del contenedor: análisis de vulnerabilidades, aislamiento en tiempo de ejecución, eliminación de capacidades y protección del kernel del host. 

La seguridad de Kubernetes abarca tanto los contenedores individuales como el clúster que los rodea, añadiendo RBAC, control de admisión, políticas de red, etcd y registros de auditoría de la orquestación. La seguridad de contenedores encaja dentro de la disciplina más amplia de la seguridad de Kubernetes.

¿Cómo se relacionan los Pod Security Standards con las Pod Security Policies obsoletas?

Las Pod Security Policies (PSP) quedaron obsoletas en Kubernetes v1.21 y se eliminaron en v1.25. Los Pod Security Standards (PSS) definen tres niveles de políticas (Privileged, Baseline, Restricted) y son aplicados por Pod Security Admission (PSA), un controlador de admisión integrado que aplica políticas a nivel de espacio de nombres mediante etiquetas. 

PSA pasó a estable en v1.25. Si su clúster ejecuta v1.25 o una versión posterior y no ha configurado PSA, está operando sin la capa de aplicación a nivel de pod.

¿Qué puntos de referencia de cumplimiento se aplican a los clústeres de Kubernetes?

Cuatro marcos principales de cumplimiento se aplican a los clústeres de Kubernetes. El CIS Kubernetes Benchmark es reconocido por PCI DSS, FedRAMP, SOC 2 y FISMA. La guía CISA/NSA Kubernetes Hardening Guidance sirve como línea base gubernamental. 

NIST SP 800-190 asigna los controles de contenedores a las familias de controles de NIST SP 800-53 Rev 5. Los Pod Security Standards proporcionan el mecanismo de aplicación integrado que se asigna directamente a la guía de CISA/NSA.

¿Los servicios administrados como EKS, AKS y GKE gestionan la seguridad del clúster por usted?

Los servicios de Kubernetes administrados gestionan la disponibilidad del plano de control, la aplicación de parches y parte de la seguridad de la infraestructura. Usted sigue siendo responsable de las políticas de RBAC, los objetos NetworkPolicy, Pod Security Admission, el cifrado de Secrets y la supervisión del entorno de ejecución. 

Se aplica el modelo de responsabilidad compartida: el proveedor protege la infraestructura del plano de control, y usted protege las cargas de trabajo, la configuración y los controles de acceso. Los CIS Benchmarks específicos de cada plataforma documentan los controles adicionales que debe aplicar en cada servicio administrado.