Las amenazas cibernéticas surgen constantemente y los actores maliciosos necesitan más tiempo para prepararse para 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 2025 se puede clasificar en tres categorías generales:
- Clústeres
- Pods
- Contenedores
La lista de verificación de seguridad de Kubernetes debe simplificarse y debe abordarse la complejidad operativa. Cuando las organizaciones intentan priorizar las medidas de seguridad y remediar las amenazas, automáticamente mejoran la reputación de la empresa. Las empresas generan confianza entre los clientes y establecen credibilidad. También reducen los gastos operativos al prepararse para futuros problemas que puedan surgir más adelante con el aumento de las 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 la 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 Kubernetes , las organizaciones han documentado numerosos impactos adversos (incluidas pérdidas de ingresos y multas) debido a la negligencia en la seguridad de los contenedores de Kubernetes. 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 código abierto de Kubernetes no son seguras y afectan a la seguridad de la cadena de suministro de software. Más del 67 % de las empresas han retrasado sus operaciones comerciales debido a problemas de seguridad, y la mayoría de las empresas globales se ven abrumadas por todos los aspectos de la gestión de la seguridad, desde el desarrollo hasta la implementación y el mantenimiento.
La lista de verificación definitiva de seguridad de Kubernetes para 2025
#1. Siga los estándares CIS
Los estándares CIS proporcionan políticas de seguridad básicas que las organizaciones pueden utilizar para mejorar la seguridad de Kubernetes. Protegen los sistemas informáticos de los ciberataques y cuentan con un conjunto de procesos y directrices consensuados por la comunidad y desarrollados para proteger los entornos Kubernetes. Según la lista de verificación de seguridad de Kubernetes CIS Benchmark, los componentes principales que los usuarios deben proteger son: Kubernetes PKI, kubeadm, archivos CNI, directorio de datos etcd, kubeadm admin.conf, controller manager.conf y el archivo de especificación de pod.
#2. Autenticación de la API de Kubernetes
Uno de los métodos más utilizados para la 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 destacar 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. En el proceso se implementa el control de acceso basado en roles.
Para utilizar la autenticación X509, los usuarios deben crear una clave privada y emitir una solicitud de firma de certificado. Esto se puede iniciar en entornos Unix o sistemas operativos 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. Varios servicios de inicio de sesión único ayudan 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 se pueden utilizar para validar las solicitudes de autenticación, y los tokens de portador en los encabezados HTTP también pueden emitir recomendaciones.
El último método de autenticación es el uso de archivos de contraseñas estáticas. Es el método 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 en el acceso de los usuarios. Para aquellos que se inician en la autenticación de Kubernetes, el uso de archivos de contraseñas estáticas como solución de autenticación es el método más sencillo para utilizar con clústeres de prueba.
#3. Seguridad de Kubelet
La seguridad de Kubelet implica ejecutar nodos en clústeres de Kubernetes. Es el principal responsable de gestionar los contenedores de Kubernetes directamente en los nodos e interactúa con las interfaces de tiempo de ejecución de contenedores (CRI).
Hay dos puertos involucrados: 10255 y 10250. 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 clústeres de Kubernetes por primera vez, se deben tener en cuenta las siguientes medidas de seguridad como parte de la lista de verificación de seguridad de Kubernetes:
- Ejecutar siempre los nodos en redes internas
- Utilizar kubelet con el indicador –anonymous-auth=false y restringir el acceso anónimo
- Evitar establecer el modo de autorización en AlwaysAllow y seleccionar otra opción
- Restringir los permisos de kubelets. El complemento de admisión NodeRestriction puede modificar pods y vincularlos a objetos Node.
- Utilizar la autenticación basada en certificados y configurarla correctamente para permitir una comunicación fluida entre el maestro y los nodos.
- Aplicar reglas de firewall estrictas y permitir que solo el maestro de Kubernetes se comunique con el kubelet
- Desactive los puertos de solo lectura y restrinja la información compartida por las cargas de trabajo.
- Pruebe manualmente todos los controles de seguridad de Kubernetes y asegúrese de que los kubelets sean inaccesibles de forma predeterminada.
#4. Gestión de secretos
Los secretos de Kubernetes almacenan datos confidenciales como claves API, contraseñas y tokens. Los secretos de Kubernetes están diseñados para que los componentes internos de Kubernetes no puedan acceder a ellos y solo se envían a los nodos de pod cuando es necesario. Los secretos son uno de los principales objetivos de los atacantes y deben protegerse cuidadosamente.
Los usuarios deben restringir el acceso a etcd, controlarlo y aplicar cifrado a los clústeres etcd. Los contenedores de Kubernetes también deben seguir el principio del privilegio mínimo. La autorización de nodos debe implementarse entre otros elementos de la lista de verificación de seguridad de Kubernetes. Lo ideal es que los usuarios utilicen diferentes conjuntos de secretos para diferentes entornos de Kubernetes.
Es una buena práctica evitar incorporar secretos en las imágenes. También se recomienda habilitar el escaneo en tiempo real de los 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, es necesario reiniciar las aplicaciones para leer las nuevas contraseñas de la base de datos. Para los usuarios de flujos de trabajo basados en archivos, los secretos de los archivos se pueden actualizar automáticamente sin necesidad de reiniciar.
#5. Controladores de admisión
Los controladores de admisión se incluyen en la lista de verificación de seguridad de Kubernetes para 2025. Estos controladores aplican los 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 impedir la ejecución de comandos en contenedores privilegiados y exigir siempre que los pods extraigan imágenes en lugar de utilizar las almacenadas localmente en el nodo. Otra ventaja de los controladores de admisión es que supervisan las solicitudes entrantes y establecen restricciones de recursos en los espacios de nombres. Se recomienda que los usuarios habiliten como mínimo los controladores de admisión predeterminados que proporciona Kubernetes.
#6. Límites de seguridad de Kubernetes
Los límites de seguridad de Kubernetes constituyen la base de la lista de comprobación de seguridad de Kubernetes. Impiden que los procesos accedan a los datos de otros usuarios y aplican 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 diversos grados de complejidad. Las políticas de seguridad de los pods de Kubernetes se configuran en un recurso a nivel de clúster y aplican el uso de contextos de seguridad y controladores de admisión. El pod debe cumplir los requisitos de la política de seguridad de los pods, o de lo contrario no se ejecutará. Las políticas de seguridad de pods se eliminan automáticamente de Kubernetes v1.25 y versiones posteriores, 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 del control de acceso y los privilegios para los contenedores de Kubernetes. Implementa controles de acceso discrecionales, establece permisos para acceder a objetos basados en ID de grupo y configura procesos sin privilegios.
Los usuarios pueden definir herramientas de contexto de seguridad internas e integrarlas con funciones externas. Pueden utilizar seccomp para filtrar las llamadas al sistema, y AppArmor puede restringir las capacidades de los componentes individuales. No es necesario proporcionar privilegios de acceso ni asignar permisos específicos para los recursos, lo que le ayuda a adoptar un enfoque granular. Los usuarios pueden incluir contextos de seguridad con el código de contexto de seguridad que se encuentra en los archivos de implementación al crear pods. Kubernetes es muy ágil y los usuarios también pueden automatizar la implementación de perfiles en todos los nodos. La única desventaja es que no hay compatibilidad con contenedores Windows. También pueden habilitar permisos para proteger 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. Añade controles que especifican cómo fluye el tráfico entre contenedores y define el tipo de tráfico que debe bloquearse. Los usuarios pueden seguir una arquitectura multiclúster para aislar las cargas de trabajo y mitigar los problemas de seguridad mediante la implementación de cargas de trabajo en diferentes clústeres. Se puede lograr un alto grado de aislamiento de los contenedores y reducir la complejidad al mismo tiempo.
Existen políticas de red de Kubernetes que añaden capacidades de cortafuegos y restringen el flujo de tráfico entre pods. Especifica qué pods se comunican con entidades de red seleccionadas. La política de entrada se permite en el puerto de destino, y la política de salida debe estar en el pod de origen para permitir un flujo de tráfico óptimo. Como regla general, es bueno utilizar etiquetas, y los usuarios pueden añadir 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. Las mallas de servicio de Kubernetes pueden simplificar la supervisión y proporcionar diversas funciones relacionadas con la supervisión continua y las alertas. Detectan amenazas de seguridad e informan de incidentes; hay muchos proyectos de malla de servicios disponibles. La lista de verificación de seguridad de Kubernetes sugiere utilizar opciones como Linkerd, Consul e Istio.
#9. Auditoría y registro de Kubernetes
Es esencial mantener registros de eventos de contenedores y crear un registro de auditoría para los entornos de producción. El registro de auditoría de Kubernetes incluye el registro de la identidad de las imágenes y los usuarios que invocan los comandos de inicio y parada. Los complementos CNI generan interfaces de red virtuales utilizadas por los contenedores. Los complementos CNI también se integran con varias plataformas y herramientas de gestión de configuración de terceros, siendo las más populares Cilium y Project Calico. Otros aspectos de la auditoría y el registro de Kubernetes incluyen la modificación de las cargas útiles de los contenedores y los montajes de volúmenes, la supervisión de las conexiones entrantes y salientes, y la corrección de las acciones fallidas. El registro de aplicaciones es la forma más sencilla de supervisar la actividad del clúster y puede proporcionar información útil para la depuración de aplicaciones. La implementación del registro a nivel de clúster y el envío de registros a contenedores de almacenamiento es una práctica estándar que utiliza una plataforma o servicio de gestión de registros centralizado.
¿Por qué SentinelOne para la seguridad de Kubernetes?
Cloud Workload Security (CWS) de SentinelOne’s para Kubernetes, parte de la plataforma Singularity™, ofrece una solución de vanguardia diseñada para abordar estas amenazas modernas de manera eficaz. 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 el ransomware y vulnerabilidades desconocidas. Su tecnología basada en 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 completa sobre la actividad de su carga de trabajo. Esta herramienta ayuda a investigar incidentes y a realizar búsquedas de amenazas. Workload Flight Data Recorder™ ayuda a recuperarse de incidentes eliminando las cargas de trabajo problemáticas, minimizando las pérdidas económicas y los daños.
- Amplia compatibilidad: SentinelOne es compatible con una amplia gama de cargas de trabajo en contenedores, incluidas 14 distribuciones principales de Linux, tres entornos de ejecución de contenedores populares y servicios Kubernetes gestionados y autogestionados.
Vea SentinelOne en acción
Descubra cómo la seguridad en la nube basada en IA puede proteger su organización en una demostración individual con un experto en productos SentinelOne.
DemostraciónConclusión
Los principios básicos de la lista de verificación de seguridad de Kubernetes 2025 giran en torno a la autenticación, la gestión de la seguridad de los pods, el manejo de secretos y otros componentes. Siguiendo estas prácticas, las organizaciones pueden proteger los entornos de Kubernetes y garantizar que el acceso a los datos esté restringido. Estos consejos simplifican la seguridad de Kubernetes y la seguridad por capas para reducir las complejidades de la arquitectura. Cuando los usuarios optimizan la seguridad de Kubernetes para la nube, resulta fácil 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 una lista de pasos que se deben seguir para bloquear el clúster. Abarca la protección del servidor API, etcd y kubelet; la aplicación de RBAC; el aislamiento de pods con políticas de seguridad de red y pod; el cifrado de secretos; y la auditoría de eventos.
La lista de verificación sirve como guía para garantizar que todos los componentes críticos, desde el plano de control hasta las cargas de trabajo, cumplan con los estándares de seguridad básicos.
Los clústeres de Kubernetes gestionan cargas de trabajo críticas, y cualquier error puede exponer datos confidenciales o permitir que los atacantes se muevan lateralmente. Una lista de verificación evita desviaciones: se aplican controles acordados de forma coherente, se detectan lagunas (como puertos API abiertos o RBAC demasiado permisivos) y se mantiene el cumplimiento. Seguir regularmente la lista de verificación reduce las sorpresas y mantiene los clústeres protegidos contra amenazas conocidas y emergentes.
Su lista de verificación de producción debe incluir: restringir el acceso al servidor API a redes de confianza; habilitar los registros de auditoría; cifrar los datos etcd en reposo; aplicar RBAC de privilegios mínimos; aplicar políticas de seguridad o admisión de pods; utilizar políticas de red para aislar servicios; proteger las imágenes de contenedores; rotar certificados; y validar la seguridad del canal de CI/CD. Cada elemento bloquea una capa de su clúster antes de que el tráfico o las cargas de trabajo se activen.
Los equipos deben revisar la lista de verificación al menos una vez al trimestre y después de cualquier actualización importante de la versión de Kubernetes o cambio de arquitectura. Las revisiones frecuentes detectan desviaciones en la configuración, como nuevos puertos abiertos o reglas RBAC menos estrictas, y garantizan que los controles se adapten a las nuevas amenazas o a los componentes añadidos.
Los cambios críticos, como nuevos espacios de nombres o controladores de admisión personalizados, también justifican una revisión inmediata de la lista de comprobación.
Las herramientas de código abierto como kube-bench auditan su clúster según los benchmarks de CIS Kubernetes. Kube-hunter busca exposiciones y configuraciones incorrectas. Polaris valida las cargas de trabajo en tiempo real según políticas personalizadas. Los registros de auditoría nativos de Kubernetes se envían a los SIEM para la supervisión de eventos.
En conjunto, estas herramientas automatizan las comprobaciones de la configuración del plano de control, RBAC, políticas de red y mucho más, lo que facilita la detección y corrección de desviaciones de la lista de verificación.
Puede empezar 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 servicios en la nube y de seguridad también publican listas de verificación en formato PDF descargables. Solo tiene que buscar "Kubernetes Security Checklist PDF" para encontrar ejemplos que pueda adaptar a su entorno.
La implementación es un esfuerzo compartido entre DevOps, ingenieros de plataforma y equipos de seguridad. Los ingenieros de plataformas configuran los componentes del plano de control y las políticas de red. Los equipos de DevOps protegen las cargas de trabajo y los procesos de CI/CD.
Los equipos de seguridad definen los controles básicos, realizan auditorías y supervisan el cumplimiento. Juntos, se aseguran de que se apliquen y validen todos los elementos de la lista de verificación, desde las reglas RBAC hasta las políticas de seguridad de los pods.
