Nota perev. : Este no es el primer artículo con recomendaciones generales de seguridad sobre Kubernetes que traducimos en nuestro blog. Sin embargo, su relevancia, al menos como un recordatorio de cosas simples e importantes que no se deben ignorar debido a la falta de tiempo, solo se confirma por los eventos recientes mencionados por el autor al comienzo del material. Por cierto, el autor es Connor Gilbert, gerente de producto de StackRox, una plataforma preparada para proteger las aplicaciones implementadas dentro de los clústeres de Kubernetes. Entonces, esto es lo que aconseja a los lectores del blog de CNCF ...
NB : Para que el artículo sea más informativo, para algunos de los términos / métodos mencionados por el autor, agregamos enlaces a la documentación relevante.
El mes pasado, Kubernetes, el sistema de orquestación de contenedores más popular del mundo,
descubrió la primera vulnerabilidad de seguridad importante que golpeó el ecosistema del proyecto. La vulnerabilidad
CVE-2018-1002105 permite a los atacantes comprometer los clústeres a través del servidor API de Kubernetes, lo que permite que se ejecute código malicioso para instalar malware, etc.
A principios de año, la configuración incorrecta del panel de control de Kubernetes llevó al hecho de que los recursos de Tesla
tenían instalado un software de minería de criptomonedas. Luego, los atacantes aprovecharon el hecho de que uno de los paneles de Kubernetes no estaba protegido con contraseña, lo que les permitió acceder a una de las cápsulas con una cuenta para acceder a la infraestructura más grande de Tesla en AWS.
Las organizaciones que aceleran la implementación de contenedores y su orquestación también deben tomar medidas obligatorias para proteger una parte tan crítica de su infraestructura. A continuación se presentan nueve de las mejores prácticas de seguridad de Kubernetes basadas en datos de clientes: sígalas para proteger mejor su infraestructura.
1. Actualiza a la última versión
En cada versión trimestral de [Kubernetes] no solo hay correcciones de errores, sino también nuevas características de seguridad: para aprovecharlas, recomendamos trabajar con la última versión estable.
El uso de la última versión con los últimos parches será especialmente relevante a la luz del reciente descubrimiento de CVE-2018-1002105. Las actualizaciones y el soporte pueden ser más difíciles que las nuevas funciones ofrecidas en las versiones, por lo tanto, planifique sus actualizaciones al menos una vez por trimestre.
Las actualizaciones simplificadas significativamente pueden usar los proveedores de soluciones Kubernetes administradas.
2. Habilite el control de acceso basado en roles (RBAC)
Use
RBAC (Control de acceso basado en roles) para controlar quién puede acceder a la API de Kubernetes y qué derechos tienen. Por lo general, RBAC está habilitado de forma predeterminada en Kubernetes versión 1.6 y superior (o posterior para algunos proveedores), pero si ha sido actualizado desde entonces y no ha cambiado la configuración, debe verificar nuevamente su configuración. Debido al mecanismo por el cual se combina el trabajo de los controladores de autorización en Kubernetes
(para la secuencia general de operaciones, lea el artículo " ¿Qué sucede en Kubernetes cuando comienza la ejecución de kubectl? Parte 1 " - Transl. Aprox. ) , Debe tener habilitados tanto RBAC como ABAC heredado (Control de acceso basado en atributos).
Sin embargo, habilitar RBAC no es suficiente, aún debe usarse de manera efectiva. En el caso general, se deben evitar los derechos de todo el clúster
(en todo el clúster
) , dando preferencia a los derechos en ciertos espacios de nombres. Evite otorgar privilegios de administrador de clúster a alguien incluso para la depuración: es mucho más seguro otorgar derechos solo cuando sea necesario y de vez en cuando.
Puede ver roles de clúster y simplemente roles con los
kubectl get clusterrolebinding o
kubectl get rolebinding --all-namespaces . Y así puede verificar rápidamente a quién se le
cluster-admin rol de
cluster-admin (en este ejemplo, es solo para el grupo de
masters ):
$ kubectl describe clusterrolebinding cluster-admin Name: cluster-admin Labels: kubernetes.io/boostrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate=true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name ---- ---- Group system:masters Namespace ---------
Si la aplicación requiere acceso a la API de Kubernetes, cree cuentas de servicio separadas
(lea más sobre ellas en este material , aprox. Transl. ) Y deles el conjunto mínimo de derechos necesarios para cada caso de uso. Este enfoque es mucho mejor que otorgar demasiados privilegios a la cuenta predeterminada en el espacio de nombres.
La mayoría de las aplicaciones no necesitan acceso a la API en absoluto:
puede configurar automountServiceAccountToken en
false para ellas.
3. Use espacios de nombres para establecer límites de seguridad
Crear espacios de nombres separados es importante como primer nivel de aislamiento de componentes. Es mucho más fácil ajustar la configuración de seguridad, por ejemplo, las políticas de red, cuando se implementan diferentes tipos de cargas de trabajo en espacios de nombres separados.
¿Su equipo usa espacios de nombres de manera eficiente? Verifique su lista de no estándar (no creado por defecto):
$ kubectl get ns NAME STATUS AGE default Active 16m kube-public Active 16m kube-system Active 16m
4. Separar las cargas de trabajo sensibles.
Una buena práctica para limitar las posibles consecuencias del compromiso es ejecutar cargas de trabajo con datos confidenciales en un conjunto dedicado de máquinas. Este enfoque reduce el riesgo de que una aplicación menos segura acceda a la aplicación con datos confidenciales que se ejecutan en el mismo entorno ejecutable del contenedor o en el mismo host. Por ejemplo, un kubelet de un nodo comprometido generalmente tiene acceso al contenido de los secretos solo si están montados en pods que están programados para ejecutarse en el mismo nodo. Si se pueden encontrar secretos importantes en múltiples nodos del clúster, un atacante tendrá más oportunidades de obtenerlos.
La separación se puede hacer usando
agrupaciones de nodos (
agrupaciones de nodos (en la nube o locales)), así como mecanismos de control de Kubernetes, como espacios de nombres,
contaminaciones, tolerancias y otros.
5. Proteger el acceso a los metadatos del servicio en la nube
Los metadatos confidenciales, por ejemplo, las credenciales administrativas de kubelet, pueden ser robados o utilizados maliciosamente para escalar privilegios en un clúster. Por ejemplo, un
hallazgo reciente dentro de la recompensa de errores de Shopify mostró en detalle cómo un usuario podría exceder la autoridad al recibir metadatos de un proveedor de la nube utilizando datos especialmente generados para uno de los microservicios.
En GKE, la función de
ocultación de metadatos , la
ocultación de metadatos , cambia el mecanismo para implementar el clúster de una manera que evite tal problema, y recomendamos usarlo hasta que se implemente una solución permanente.
Se pueden requerir contramedidas similares en otros entornos.
6. Crear y definir políticas de red de clúster
Políticas de red - Políticas de
red - le permiten controlar el acceso a la red desde y hacia aplicaciones en contenedores. Para usarlos, debe tener un proveedor de red con soporte para dicho recurso; Para los proveedores de soluciones administradas de Kubernetes como Google Kubernetes Engine (GKE), será necesario habilitar el soporte. (La habilitación de políticas de red para los clústeres existentes en GKE requerirá una breve actualización continua).
Una vez que todo esté listo, comience con políticas de red simples y predeterminadas, por ejemplo, bloqueando (por defecto) el tráfico de otros espacios de nombres.
Si está utilizando Google Container Engine, puede verificar si el soporte de políticas está habilitado en clústeres de trabajo:
$ gcloud container clusters list \ --format='table[box] (name,addonsConfig.networkPolicyConfig)'
7. Establezca la Política de seguridad de pod para el clúster.
Política de seguridad de pod: política de seguridad de pod : establece los valores predeterminados utilizados para iniciar las cargas de trabajo en el clúster. Considere la posibilidad de definir una política y habilitar el
controlador de admisión de la Política de seguridad de pod: las instrucciones para estos pasos varían según el proveedor de la nube o el modelo de implementación utilizado.
Para empezar, es posible que
NET_RAW capacidad NET_RAW en contenedores para protegerse de ciertos tipos de ataques de suplantación de identidad.
8. Trabajar en seguridad de nodo
Para mejorar la seguridad del host, puede seguir estos pasos:
- Asegúrese de que el host esté configurado de forma segura y correcta . Una forma son los puntos de referencia CIS ; Muchos productos tienen un autochecker que verifica automáticamente que el sistema cumpla con estos estándares.
- Monitoree la disponibilidad de red de puertos importantes . Asegúrese de que su red esté bloqueando el acceso a los puertos utilizados por kubelet, incluidos 10250 y 10255. Considere restringir el acceso al servidor API de Kubernetes, a excepción de las redes confiables. En los clústeres que no requerían autenticación y autorización en la API de Kubelet, los atacantes utilizaron el acceso a dichos puertos para lanzar mineros de criptomonedas.
- Minimice el acceso administrativo a los hosts Kubernetes . En principio, el acceso a los nodos del clúster debe ser limitado: para depurar y resolver otros problemas, por regla general, puede prescindir del acceso directo al nodo.
9. Habilite el registro de auditoría
Asegúrese de que los
registros de auditoría estén habilitados y de que esté supervisando la aparición de llamadas API inusuales o no deseadas en ellos, especialmente en el contexto de fallas de autorización; dichas entradas tendrán un mensaje con el estado "Prohibido". Las fallas de autorización pueden significar que un atacante está tratando de aprovechar las credenciales obtenidas.
Los proveedores de soluciones administradas (incluido GKE) proporcionan acceso a estos datos en sus interfaces y pueden ayudarlo a configurar notificaciones en caso de fallas de autorización.
Mirando hacia el futuro
Siga estas pautas para un clúster de Kubernetes más seguro. Recuerde que incluso después de que el clúster esté configurado de forma segura, debe garantizar la seguridad en otros aspectos de la configuración y el funcionamiento de los contenedores. Para mejorar la seguridad de la pila de tecnología, explore las herramientas que proporcionan un sistema central para administrar los contenedores desplegados, monitoreando y protegiendo constantemente los contenedores y las aplicaciones nativas de la nube.
PD del traductor
Lea también en nuestro blog: