¿Su clúster Kubernetes es seguro o simplemente está en ejecución?Las configuraciones predeterminadas de Kubernetes priorizan la facilidad de uso sobre la seguridad. Sin un endurecimiento deliberado, los clústeres son vulnerables a fugas de contenedores, escalada de privilegios, movimientos laterales y robo de datos. Esta lista de verificación cubre todos los controles de seguridad que necesita implementar para entornos de producción Kubernetes.
Conclusiones clave
- El Kubernetes predeterminado no es seguro:Las configuraciones listas para usar permiten contenedores privilegiados, acceso a la red sin restricciones y amplios permisos de servidor API.
- RBAC es tu primera defensa:Restrinja el acceso al servidor API al mínimo requerido para cada cuenta de servicio y usuario.
- Las políticas de red impiden el movimiento lateral:Sin políticas de red, cada módulo puede comunicarse con todos los demás: una red plana dentro de su clúster.
- Los estándares de seguridad Pod reemplazan a PSP:La Admisión de Seguridad de Pods (PSA) impone restricciones de seguridad en todos los pods.
- La seguridad de la cadena de suministro es importante:Verifique la procedencia de las imágenes, busque vulnerabilidades y aplique políticas de imágenes a través del control de admisión.
Kubernetes Lista de verificación de seguridad
API Seguridad del servidor
- Habilite RBAC y deshabilite la autenticación anónima
- Utilice autenticación sólida (OIDC, basada en certificados), no autenticación básica ni tokens estáticos
- Restringir el acceso al servidor API a rangos de IP conocidos (administrada Kubernetes: utilizar redes autorizadas)
- Habilite el registro de auditoría para todas las solicitudes del servidor API
- Deshabilitar funciones alfa/beta en clústeres de producción
- Configurar controladores de admisión: PodSecurity, ResourceQuota, LimitRange
Mejores prácticas de RBAC
- Siga el privilegio mínimo: no hay enlaces de ClusterAdmin para cuentas de servicio
- Utilice roles con espacios de nombres en lugar de ClusterRoles cuando sea posible
- Audite RBAC periódicamente con herramientas como kubectl-who-can y rbac-lookup
- Nunca concedas permisos comodín (verbos: ["*"], recursos: ["*"])
- Restringir el acceso a secretos: conceder obtención/lista de secretos solo a los pods que los necesiten
- Utilice cuentas de servicio independientes por aplicación (no la cuenta de servicio predeterminada)
Seguridad de la red
- Implementar NetworkPolicies de denegación predeterminada en todos los espacios de nombres
- Permitir solo el tráfico de entrada y salida requerido por aplicación
- Utilice un CNI que admita NetworkPolicies (Calico, Cilium, Antrea)
- Cifrar la comunicación entre pods con la malla de servicio mTLS (Istio, Linkerd)
- Restringir la salida a puntos finales externos conocidos (evitar la filtración de datos)
- Aislar cargas de trabajo confidenciales en espacios de nombres dedicados con políticas estrictas
Seguridad del módulo
- Habilite la admisión de seguridad del pod a nivel de espacio de nombres (aplicar perfil "restringido")
- Ejecutar contenedores como no root (runAsNonRoot: true)
- Utilice un sistema de archivos raíz de solo lectura (readOnlyRootFilesystem: true)
- Elimine todas las capacidades, agregue solo lo que sea necesario (elimine: ["TODOS"])
- Deshabilitar la escalada de privilegios (allowPrivilegeEscalation: false)
- Establezca límites de recursos (CPU, memoria) en todos los contenedores para evitar el abuso de recursos
- No monte el token de la cuenta de servicio a menos que sea necesario (automountServiceAccountToken: false)
Seguridad de imagen
- Escanee todas las imágenes en busca de vulnerabilidades antes de la implementación (Trivy, Snyk)
- Utilice imágenes base mínimas (sin distribución, Alpine) para reducir la superficie de ataque
- Firmar imágenes de contenedores y verificar firmas en el momento de la admisión (cofirma, notación)
- Permitir únicamente imágenes de registros confiables (aplicar mediante control de admisión)
- Nunca use la etiqueta :latest: fije a resúmenes de imágenes específicos para mayor reproducibilidad
- Reconstruya y actualice periódicamente las imágenes base para incorporar parches de seguridad
Gestión de secretos
- No almacene secretos en variables de entorno o ConfigMaps
- Utilice la gestión de secretos externa (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Si utiliza Kubernetes Secrets, habilite el cifrado en reposo (EncryptionConfiguration)
- Rotar secretos periódicamente con rotación automatizada a través de operadores secretos externos
- Restrinja el acceso de RBAC a los secretos: la mayoría de los pods no deberían poder enumerar todos los secretos
Monitoreo y Detección
- Habilite el registro de auditoría Kubernetes y reenvíe a SIEM
- Implementar monitoreo de seguridad en tiempo de ejecución (Falco, Sysdig)
- Supervisar: ejecución inesperada de procesos, conexiones de red, modificaciones de archivos, escalada de privilegios
- Alerta sobre: creación de un nuevo ClusterRoleBinding, acceso secreto por pods inesperados, comandos ejecutivos de contenedor
- Implementar violaciones de la política de seguridad del pod como alertas SIEM
Índice de referencia CEI Kubernetes
El Centro para la Seguridad de Internet (CIS) publica puntos de referencia de seguridad detallados para Kubernetes. Utilice kube-bench para evaluar automáticamente su clúster con respecto a los puntos de referencia CIS. Aborde todos los hallazgos críticos y altos antes de la implementación de producción. Los servicios Kubernetes administrados (EKS, AKS, GKE) manejan algunos elementos de referencia automáticamente, pero los elementos responsables del cliente aún requieren configuración.
Cómo Opsio protege Kubernetes
- Evaluación de seguridad del clúster:Evaluamos sus clústeres Kubernetes comparándolos con los puntos de referencia CIS y las mejores prácticas de los proveedores de nube.
- Implementación de refuerzo:Implementamos todos los elementos de la lista de verificación, incluidos RBAC, políticas de red, seguridad de pod y monitoreo.
- Supervisión del tiempo de ejecución:Nuestro SOC monitorea los clústeres Kubernetes en busca de eventos de seguridad y comportamientos anómalos.
- Aplicación de políticas:Implementamos OPA/Gatekeeper o Kyverno para hacer cumplir las políticas de seguridad automáticamente.
- Gestión continua:Revisiones de seguridad periódicas, reevaluación de los puntos de referencia CIS y actualizaciones de configuración de seguridad.
Preguntas frecuentes
¿Cuál es el control de seguridad Kubernetes más importante?
Políticas de red con denegación predeterminada. Sin políticas de red, cada pod puede comunicarse con todos los demás pods: un pod de aplicación web comprometido puede acceder directamente al pod de base de datos, a la pila de monitoreo y al servidor Kubernetes API. Las políticas de red de denegación predeterminada reducen inmediatamente el radio de explosión de cualquier contenedor comprometido.
¿Debo utilizar una malla de servicios por seguridad?
Service Mesh (Istio, Linkerd) agrega mTLS entre servicios, proporcionando cifrado y autenticación para todas las comunicaciones entre pods. Si maneja datos confidenciales o necesita cumplir con los requisitos de cumplimiento para el cifrado en tránsito, la malla de servicios es valiosa. Para entornos más simples, las políticas de red por sí solas pueden ser suficientes.
¿Cómo manejo los secretos en Kubernetes de forma segura?
Utilice un administrador de secretos externo (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) con un operador de secretos Kubernetes (Operador de secretos externo, Operador de secretos de Vault). Esto mantiene los secretos fuera de Git, proporciona registros de auditoría, permite la rotación y centraliza la gestión de secretos en cargas de trabajo Kubernetes y no Kubernetes.