Las ciberamenazas están en constante evolución, y los actores maliciosos necesitan más tiempo para prepararse ante ellas. Optimizar la seguridad de Kubernetes es fundamental para mejorar la postura de seguridad en la nube de una empresa. Los administradores de Kubernetes deben comprender cómo funciona la infraestructura para incorporar medidas de seguridad eficaces.
La Lista de Verificación de Seguridad de Kubernetes para 2026 puede clasificarse en tres categorías principales:
- Clusters
- Pods
- Contenedores
.jpg)
La Lista de Verificación de Seguridad de Kubernetes debe simplificarse y se debe abordar la complejidad operativa. Cuando las organizaciones priorizan las medidas de seguridad y remedian amenazas, automáticamente mejoran la reputación empresarial. Las empresas generan confianza entre los clientes y establecen credibilidad. También reduce los gastos operativos al prepararse para problemas futuros que puedan surgir con el aumento de amenazas. Profundicemos en ello.
Lista de Verificación de Seguridad de Kubernetes con Múltiples Componentes
La Lista de Verificación de Seguridad de Kubernetes tiene múltiples componentes,
- Auditoría y registro
- Seguridad de red
- Autenticación y autorización
- Gestión de secretos
- Control de admisión
- Límites de seguridad de Kubernetes
- Políticas de seguridad de Kubernetes
- Seguridad de Kubelet
- Valores predeterminados ‘abiertos’
Según el informe de adopción, seguridad y tendencias de mercado de Kubernetes 2024, las organizaciones han documentado numerosos impactos adversos (incluyendo pérdidas de ingresos y multas) debido a la negligencia en la seguridad de contenedores de Kubernetes. Los equipos de DevSecOps han declarado que las vulnerabilidades y las configuraciones incorrectas son las principales preocupaciones de seguridad asociadas con Kubernetes y los entornos de contenedores. Las soluciones de software de Kubernetes de código abierto no son seguras y afectan la seguridad de la cadena de suministro de software. Más del 67% de las empresas han retrasado operaciones comerciales debido a problemas de seguridad, y la mayoría de las empresas globales se sienten abrumadas con todos los aspectos de la gestión de seguridad, desde el desarrollo, la implementación y el mantenimiento.
La lista de verificación definitiva de seguridad de Kubernetes para 2026
#1. Siga los Benchmarks de CIS
Los Benchmarks de CIS proporcionan políticas de seguridad base que las organizaciones pueden utilizar para mejorar la seguridad de Kubernetes. Protege los sistemas de TI contra ciberataques y presenta un conjunto de procesos y directrices consensuadas por la comunidad desarrolladas para asegurar los entornos de Kubernetes. Según la lista de verificación de seguridad de Kubernetes CIS Benchmark, los principales componentes que los usuarios deben asegurar son: Kubernetes PKI, kubeadm, archivos CNI, directorio de datos etcd, kubeadm admin.conf, controller manager.conf y el archivo de especificación del pod.
#2. Autenticación de la API de Kubernetes
Uno de los métodos más adoptados de autenticación de la API de Kubernetes en la lista de verificación de seguridad de Kubernetes es el uso de certificados X509. Los certificados se utilizan para resaltar un grupo de membresías y pueden verificar los nombres de los sujetos que envían solicitudes.
Según la lista de verificación de seguridad de Kubernetes, existen otros métodos integrados para autenticar cuentas de usuario. Las prácticas de autenticación de Kubernetes validan la identidad de los usuarios y determinan si se les debe conceder acceso. Se implementa el control de acceso basado en roles en el proceso.
Para utilizar la autenticación X509, los usuarios deben crear una clave privada y emitir una solicitud de firma de certificado. Esto puede iniciarse en entornos de sistemas operativos Unix o similares. La segunda técnica más popular de autenticación de Kubernetes es el uso de tokens OpenID Connect (OIDC). Muchos proveedores de OIDC como Google, Okta, dex y OpenUnison ayudan con esto. Diversos servicios de inicio de sesión único asisten con la autenticación de la API de Kubernetes, y los pasos de implementación varían según el servicio que elijan los usuarios. Los tokens de autenticación de cuentas de servicio pueden utilizarse para validar solicitudes de autenticación, y los tokens portadores en los encabezados HTTP también pueden emitir recomendaciones.
El método final de autenticación es el uso de archivos de contraseñas estáticas. Es el enfoque de autenticación menos seguro, pero el más sencillo. Requiere una configuración mínima, y los usuarios deben actualizar manualmente el archivo de contraseñas para reflejar los cambios de acceso de los usuarios. Para quienes son nuevos en la autenticación de Kubernetes, el uso de archivos de contraseñas estáticas como solución de autenticación es el enfoque más directo para usar con clusters de prueba.
#3. Seguridad de Kubelet
La seguridad de Kubelet implica ejecutar nodos en los clusters de Kubernetes. Es principalmente responsable de gestionar los contenedores de Kubernetes directamente en los nodos e interactúa con las interfaces de ejecución de contenedores (CRI).
Hay dos puertos involucrados: 10255 y 10250. El 10255 es un puerto de solo lectura que devuelve datos sobre los pods y contenedores que se ejecutan en los nodos. El 10250 es un puerto de escritura que puede programar pods en nodos seleccionados.
Al implementar clusters de Kubernetes por primera vez, se deben considerar las siguientes medidas de seguridad como parte de la lista de verificación de seguridad de Kubernetes:
- Ejecutar los nodos siempre en redes internas
- Usar kubelet con el parámetro –anonymous-auth=false y restringir el acceso anónimo
- Evitar configurar el modo de autorización en AlwaysAllow y seleccionar otra opción
- Restringir los permisos de los kubelets. El plugin de admisión NodeRestriction puede modificar pods y vincularlos a objetos Node.
- Utilizar autenticación basada en certificados y configurarla correctamente para habilitar la comunicación fluida entre el master y los nodos.
- Aplicar reglas estrictas de firewall y permitir solo que el master de Kubernetes se comunique con el kubelet
- Desactivar los puertos de solo lectura y restringir la información compartida por las cargas de trabajo
- Probar manualmente todos los controles de seguridad de Kubernetes y asegurarse de que los kubelets sean inaccesibles por defecto
#4. Gestión de Secretos
Los secretos de Kubernetes almacenan datos sensibles como claves API, contraseñas y tokens. Los secretos de Kubernetes están diseñados para no ser accesibles por los componentes internos de Kubernetes y solo se envían a los nodos de los pods según sea necesario. Los secretos son uno de los mayores objetivos para los atacantes y deben protegerse cuidadosamente.
Los usuarios deben restringir el acceso a etcd, controlarlo y aplicar cifrado a los clusters de etcd. Los contenedores de Kubernetes también deben seguir el principio de privilegio mínimo de acceso. Se debe implementar la autorización de nodos entre otros elementos de la lista de verificación de seguridad de Kubernetes. Idealmente, los usuarios deben utilizar diferentes conjuntos de secretos para distintos entornos de Kubernetes.
Es una buena práctica evitar incluir secretos en las imágenes. También se recomienda habilitar el escaneo en tiempo real de secretos en los repositorios de código fuente y verificarlos. Los secretos corren el riesgo de ser escritos en los registros, y una de las mejores prácticas de seguridad es pasar los secretos en archivos. Configure el volumen montado como un directorio temporal en lugar de escribir en el disco. También puede rotar las claves secretas, elegir diferentes formas de almacenarlas y pasarlas a los contenedores para obtener los mejores resultados. A veces, las aplicaciones deben reiniciarse para leer nuevas contraseñas de bases de datos. Para los usuarios de flujos de trabajo basados en archivos, los secretos de archivos pueden actualizarse automáticamente sin reinicios.
#5. Controladores de Admisión
Los controladores de admisión están incluidos en la lista de verificación de seguridad de Kubernetes para 2026. Estos aplican marcos de políticas de seguridad de Kubernetes y funcionan como una segunda línea de defensa junto a los controles RBAC.
Los controladores de admisión pueden establecer reglas basadas en diferentes parámetros y limitar la utilización de recursos. Pueden evitar la ejecución de comandos en contenedores privilegiados y siempre requieren que los pods extraigan imágenes en lugar de usar las almacenadas localmente en el nodo. Otro beneficio de los controladores de admisión es monitorear las solicitudes entrantes y establecer restricciones de recursos en los espacios de nombres. Se recomienda que los usuarios habiliten los controladores de admisión predeterminados proporcionados por Kubernetes como mínimo indispensable.
#6. Límites de Seguridad de Kubernetes
Los límites de seguridad de Kubernetes forman la base de la lista de verificación de seguridad de Kubernetes. Evita que los procesos accedan a los datos de otros usuarios y aplica políticas que ofrecen aislamiento en contenedores. Las plantillas de admisión LimitRanger y ResourceQuota inhiben la privación de recursos, y en cuanto a los pods, los usuarios pueden definir contextos de seguridad personalizados y aplicarlos.
#7. Políticas de Seguridad de Kubernetes
Los estándares de seguridad de los pods están sujetos a diferentes grados de complejidad. Las políticas de seguridad de pods de Kubernetes se configuran en un recurso a nivel de cluster y aplican el uso de contextos de seguridad y controladores de admisión. El pod debe cumplir con los requisitos de la política de seguridad del pod, de lo contrario no se ejecutará. Las políticas de seguridad de pods se eliminan automáticamente a partir de Kubernetes v1.25, lo que significa que los usuarios deben migrar al controlador de admisión de seguridad de pods de Kubernetes.
Los contextos de seguridad definen la configuración de control de acceso y privilegios para los contenedores de Kubernetes. Implementa controles de acceso discrecional, establece permisos para acceder a objetos según los ID de grupo y configura procesos no privilegiados.
Los usuarios pueden definir herramientas internas de contexto de seguridad e integrarlas con funciones externas. Pueden usar seccomp para filtrar llamadas al sistema, y AppArmor puede restringir las capacidades de componentes individuales. No es necesario proporcionar privilegios de acceso ni asignar permisos específicos de recursos, lo que ayuda a adoptar un enfoque granular. Los usuarios pueden incluir contextos de seguridad con el código de contexto de seguridad encontrado dentro de los archivos de implementación al crear pods. Kubernetes es muy ágil, y los usuarios también pueden automatizar el despliegue de perfiles en los nodos. La única desventaja es que no hay soporte para contenedores de Windows. También pueden habilitar permisos para asegurar cuentas de servicio, nodos y usuarios.
#8. Seguridad de Red de Kubernetes
La seguridad de red de Kubernetes es un componente esencial de la lista de verificación de seguridad de Kubernetes. Agrega controles que especifican cómo fluye el tráfico entre los contenedores y define el tipo de tráfico que debe bloquearse. Los usuarios pueden seguir una arquitectura multicluster para aislar cargas de trabajo y mitigar problemas de seguridad implementando cargas de trabajo en diferentes clusters. Se puede lograr un alto grado de aislamiento de contenedores y reducir la complejidad simultáneamente.
Existen políticas de red de Kubernetes que agregan capacidades de firewall y restringen el flujo de tráfico entre pods. Especifica qué pods se comunican con entidades de red seleccionadas. La política de ingreso se permite en el puerto de destino, y la política de egreso debe estar en el pod de origen para habilitar un flujo de tráfico óptimo. Como regla general, es bueno usar etiquetas, y los usuarios pueden agregar procedimientos para permitir y dirigir el tráfico solo a donde lo esperan. Pueden restringir el tráfico a puertos específicos para diferentes aplicaciones. Los service mesh de Kubernetes pueden simplificar la monitorización y proporcionar diversas funciones relacionadas con la monitorización continua y alertas. Detectan amenazas de seguridad e informan incidentes; hay muchos proyectos de service mesh disponibles. La lista de verificación de seguridad de Kubernetes sugiere usar opciones como Linkerd, Consul e Istio.
#9. Auditoría y Registro de Kubernetes
Mantener registros de eventos de contenedores y crear una pista de auditoría para entornos de producción es esencial. El registro de auditoría de Kubernetes incluye registrar la identidad de las imágenes y los usuarios que invocan comandos de inicio y detención. Los plugins CNI generan interfaces de red virtual utilizadas por los contenedores. Los plugins CNI también se integran con varias plataformas y herramientas de gestión de configuración de terceros, y los más populares son Cilium y Project Calico. Otros aspectos de la auditoría y el registro de Kubernetes incluyen la modificación de cargas útiles de contenedores y montajes de volúmenes, la monitorización de conexiones entrantes y salientes, y la remediación de acciones fallidas. El registro de aplicaciones es la forma más sencilla de monitorear la actividad del cluster y puede proporcionar información para depurar aplicaciones. Implementar el registro a nivel de cluster y enviar los registros a contenedores de almacenamiento es una práctica estándar utilizando una plataforma o servicio centralizado de gestión de registros.
¿Por qué SentinelOne para la seguridad de Kubernetes?
Cloud Workload Security (CWS) de SentinelOne para Kubernetes, parte de la plataforma Singularity™, ofrece una solución de vanguardia diseñada para abordar eficazmente estas amenazas modernas. Así es como SentinelOne mejora la seguridad de Kubernetes:
- Protección contra amenazas en tiempo real: Singularity CWS supervisa y protege continuamente sus cargas de trabajo de Kubernetes frente a amenazas como ransomware y vulnerabilidades desconocidas. Su tecnología impulsada por IA garantiza una detección y respuesta rápidas, protegiendo sus entornos de Kubernetes.
- Investigación de incidentes y búsqueda de amenazas: Con Singularity Data Lake, SentinelOne proporciona información integral sobre la actividad de sus cargas de trabajo. Esta herramienta ayuda en la investigación de incidentes y la búsqueda de amenazas. Workload Flight Data Recorder™ ayuda en la recuperación de incidentes eliminando cargas de trabajo problemáticas, minimizando la pérdida financiera y los daños.
- Amplia compatibilidad: SentinelOne es compatible con una amplia variedad de cargas de trabajo en contenedores, incluidas 14 distribuciones principales de Linux, tres entornos de ejecución de contenedores populares y servicios de Kubernetes tanto gestionados como autogestionados.
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.
Conclusión
Los principios básicos de la Lista de Verificación de Seguridad de Kubernetes 2026 giran en torno a la autenticación, la gestión de la seguridad de los pods, el manejo de secretos y otros componentes. Al seguir estas prácticas, las organizaciones pueden asegurar los entornos de Kubernetes y garantizar que el acceso a los datos esté restringido. Estos consejos simplifican la seguridad de Kubernetes y agregan capas de seguridad para reducir las complejidades en la arquitectura. Cuando los usuarios optimizan la seguridad de Kubernetes para la nube, resulta sencillo integrarla con otros flujos de trabajo de seguridad.
Preguntas frecuentes sobre la lista de verificación de seguridad de Kubernetes
Una lista de verificación de seguridad de Kubernetes es un conjunto de pasos que se siguen para proteger su clúster. Incluye asegurar el API server, etcd y kubelet; aplicar RBAC; aislar pods con políticas de red y de seguridad de pods; cifrar secretos; y auditar eventos.
La lista sirve como guía para garantizar que cada componente crítico, desde el plano de control hasta las cargas de trabajo, cumpla con los estándares mínimos de seguridad.
Los clústeres de Kubernetes gestionan cargas de trabajo críticas, y cualquier error puede exponer datos sensibles o permitir que los atacantes se desplacen lateralmente. Una lista de verificación previene desviaciones: aplica controles acordados de manera consistente, detecta brechas—como puertos API abiertos o RBAC demasiado permisivo—y mantiene el cumplimiento. Seguir la lista regularmente reduce sorpresas y mantiene los clústeres reforzados contra amenazas conocidas y emergentes.
Su lista de producción debe incluir: restringir el acceso al API server a redes confiables; habilitar registros de auditoría; cifrar los datos de etcd en reposo; aplicar RBAC de mínimo privilegio; implementar políticas de seguridad de pods o de admisión; usar políticas de red para aislar servicios; proteger imágenes de contenedores; rotar certificados; y validar la seguridad de la canalización CI/CD. Cada elemento refuerza una capa de su clúster antes de que el tráfico o las cargas de trabajo estén en producción.
Los equipos deben revisar la lista al menos trimestralmente y después de cualquier actualización importante de versión de Kubernetes o cambio de arquitectura. Las revisiones frecuentes detectan desviaciones de configuración—como nuevos puertos abiertos o reglas RBAC relajadas—y aseguran que los controles se adapten a nuevas amenazas o componentes añadidos.
Cambios críticos, como nuevos namespaces o controladores de admisión personalizados, también requieren una revisión inmediata de la lista.
Herramientas de código abierto como kube-bench auditan su clúster según los CIS Kubernetes Benchmarks. Kube-hunter busca exposiciones y configuraciones incorrectas. Polaris valida cargas de trabajo en vivo frente a políticas personalizadas. Los registros de auditoría nativos de Kubernetes se integran en SIEMs para el monitoreo de eventos.
En conjunto, estas herramientas automatizan la verificación de configuraciones del plano de control, RBAC, políticas de red y más, facilitando la detección y corrección de desviaciones respecto a su lista de verificación.
Puede comenzar con la lista de verificación de seguridad oficial de Kubernetes en GitHub (kubernetes.io/docs/concepts/security/security-checklist/) o con guías mantenidas por la comunidad como el repositorio krol3/kubernetes-security-checklist.
Muchos proveedores de nube y empresas de seguridad también publican listas de verificación en PDF descargables—simplemente busque “Kubernetes Security Checklist PDF” para encontrar ejemplos que puede adaptar a su entorno.
La implementación es un esfuerzo compartido entre DevOps, ingenieros de plataforma y equipos de seguridad. Los ingenieros de plataforma configuran los componentes del plano de control y las políticas de red. Los equipos de DevOps aseguran las cargas de trabajo y las canalizaciones CI/CD.
Los equipos de seguridad definen controles base, realizan auditorías y monitorean el cumplimiento. Juntos, aseguran que cada elemento de la lista—desde reglas RBAC hasta políticas de seguridad de pods—sea aplicado y validado.
