Asegurando un Cluster

Este documento cubre temas relacionados con la protección de un clúster del acceso accidental o malicioso y proporciona recomendaciones sobre la seguridad general.

Control de acceso a la API de Kubernetes

Como Kubernetes está completamente basado en API, controlar y limitar quién puede acceder al clúster y qué acciones se les permite realizar es la primera línea de defensa.

Use Transport Layer Security (TLS) para todo el tráfico API

Kubernetes espera que toda la comunicación API en el clúster esté encriptada de manera predeterminada con TLS, y la mayoría de los métodos de instalación permitirán que se creen y distribuyan los certificados necesarios a los componentes del clúster. Tenga en cuenta que algunos componentes y métodos de instalación pueden habilitar puertos locales a través de HTTP y los administradores deben familiarizarse con la configuración de cada componente para identificar el tráfico potencialmente no seguro.

Autenticación API

Elija un mecanismo de autenticación para que lo utilicen los servidores API que coincida con los patrones de acceso comunes cuando instale un clúster. Por ejemplo, los pequeños grupos de usuarios individuales pueden desear utilizar un certificado simple o un enfoque de token de portador estático. Los clústeres más grandes pueden desear integrar un servidor OIDC o LDAP existente que permita que los usuarios se subdividan en grupos.

 

Autorización API

Una vez autenticado, también se espera que cada llamada a la API pase una verificación de autorización. Kubernetes incluye un componente integrado de control basado en acceso (RBAC) que hace coincidir un usuario o grupo entrante con un conjunto de permisos agrupados en roles. Estos permisos combinan verbos (obtener, crear, eliminar) con recursos (pods, servicios, nodos) y pueden ser de espacio de nombres o de ámbito de clúster. Se proporcionan un conjunto de roles listos para usar que ofrecen una separación de responsabilidad razonable por defecto dependiendo de las acciones que un cliente quiera realizar. 

Control de acceso al Kubelet

Kubelets expone los puntos finales HTTPS que otorgan un control poderoso sobre el nodo y los contenedores. De forma predeterminada, Kubelets permite el acceso no autenticado a esta API.

Los clústeres de producción deberían habilitar la autenticación y autorización de Kubelet.

Controlar las capacidades de una carga de trabajo o usuario en tiempo de ejecución

La autorización en Kubernetes es intencionalmente de alto nivel, enfocada en acciones malintencionadas sobre recursos. Existen controles más potentes como políticas para limitar por caso de uso cómo actúan esos objetos en el clúster, ellos mismos y otros recursos.

Limitar el uso de recursos en un clúster

La cuota de recursos limita el número o la capacidad de los recursos otorgados a un espacio de nombres. Esto se usa con mayor frecuencia para limitar la cantidad de CPU, memoria o disco persistente que un espacio de nombres puede asignar, pero también puede controlar cuántos pods, servicios o volúmenes existen en cada espacio de nombres.

Controlar con qué privilegios se ejecutan los contenedores

las políticas de seguridad de pods pueden limitar qué usuarios o cuentas de servicio pueden proporcionar configuraciones de contexto de seguridad peligrosas. Por ejemplo, las políticas de seguridad de pod pueden limitar los montajes de volumen, especialmente hostPath, que son aspectos de un pod que deben controlarse.

Evitar que los contenedores carguen módulos de kernel no deseados

El kernel de Linux carga automáticamente los módulos del kernel desde el disco si es necesario en ciertas circunstancias, como cuando se conecta una pieza de hardware o se monta un sistema de archivos. De particular relevancia para Kubernetes, incluso los procesos no privilegiados pueden causar la carga de ciertos módulos del núcleo relacionados con el protocolo de red, simplemente creando un socket del tipo apropiado. Esto puede permitir que un atacante explote un agujero de seguridad en un módulo del núcleo que el administrador supuso que no estaba en uso.

Restricción de acceso a la red

Las políticas de red para un espacio de nombres permiten a los autores de aplicaciones restringir qué pods en otros espacios de nombres pueden acceder a pods y puertos dentro de sus espacios de nombres. Muchos de los proveedores de redes de Kubernetes compatibles ahora respetan la política de red.

Proteger los componentes del clúster del compromiso

Esta sección describe algunos patrones comunes para proteger los clústeres de un ataque.

Restrinja el acceso a etcd

El acceso de escritura al backend de etcd para la API es equivalente a obtener root en todo el clúster, y el acceso de lectura se puede usar para escalar con bastante rapidez. Los administradores siempre deben usar credenciales sólidas de los servidores API a su servidor etcd, como la autenticación mutua a través de certificados de cliente TLS, y a menudo se recomienda aislar los servidores etcd detrás de un firewall al que solo pueden acceder los servidores API.

Habilitar registro de auditoría

El registro de auditoria es una función beta que registra las acciones tomadas por la API para su posterior análisis en caso de compromiso. Se recomienda habilitar el registro de auditoría y archivar el archivo de auditoría en un servidor seguro.

Rotar las credenciales de infraestructura con frecuencia

Cuanto más corta sea la vida útil de un secreto o credencial, más difícil será para un atacante hacer uso de esa credencial. Establezca vidas cortas en los certificados y automatice su rotación. Use un proveedor de autenticación que pueda controlar cuánto tiempo están disponibles los tokens emitidos y use vidas cortas cuando sea posible. Si usa tokens de cuenta de servicio en integraciones externas, planee rotar esos tokens con frecuencia. Por ejemplo, una vez que se completa la fase de arranque, se debe revocar un token de arranque utilizado para configurar nodos o eliminar su autorización.

Revise las integraciones de terceros antes de habilitarlas

Muchas integraciones de terceros a Kubernetes pueden alterar el perfil de seguridad de su clúster. Al habilitar una integración, siempre revise los permisos que solicita una extensión antes de otorgarle acceso. Por ejemplo, muchas integraciones de seguridad pueden solicitar acceso para ver todos los secretos de su clúster, lo que está haciendo que ese componente sea un administrador de clúster. En caso de duda, restrinja la integración al funcionamiento en un solo espacio de nombres si es posible.

Cifrar contraseñas en reposo

En general, la base de datos etcd contendrá cualquier información accesible a través de la API de Kubernetes y puede otorgar a un atacante una visibilidad significativa del estado de su clúster. Siempre encripte sus copias de seguridad usando una solución de encriptación y copia de seguridad bien revisada, y considere usar encriptación de disco completo cuando sea posible.

Recibir alertas de actualizaciones de seguridad y reportar vulnerabilidades

Únase al grupo de doblefactor  sobre anuncios de seguridad. Consulte la página de informes de seguridad para obtener más información sobre cómo informar vulnerabilidades.

Fuente:https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

¡Haz clic para puntuar esta entrada!
(Votos: 1 Promedio: 5)

compartir en ....
Avatar

Acerca de Brian Alexander Diaz

Brian Alexander Diaz Investigador en temas de seguridad y Devops Mi nombre es Brian Alexander Diaz. El objetivo de este blog es promover la cultura y mentalidad en seguridad por todo el Internet y que la gente aprenda a facilitar su vida y crear  sistemas mas seguros .

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *