Seguridad de contenedores: una nueva frontera (Parte 2)

Un serial de blogs de dos partes sobre consideraciones para mantener seguro el uso de contenedores.

Seguridad de contenedores, con una nueva dimensión

Describimos los desafíos de seguridad que pueden presentar los contenedores en nuestra primera publicación de blog. Esto nos deja con preguntas sobre cómo debemos pensar en la seguridad de los contenedores. 

Creemos que deberíamos comenzar con (y basarnos) en el consejo de Kubernetes de usar un enfoque de defensa en profundidad en capas que tenga en cuenta las cuatro C: nube, clústeres, contenedores y código. También creemos que debemos considerar cómo contener las amenazas que comprometen los contenedores, mediante la segmentación.

Siendo este el caso, proponemos la contención como una quinta C. 

Discutimos anteriormente la necesidad no solo de cerciorar los contenedores, sino también de garantizar que no puedan ser explotados y empleados como cabeza de playa para mover lateralmente dentro de un centro de datos. Ahí es donde entra en juego la necesidad de contención. 

Examinemos la guía inicial de Kubernetes sobre las 4 C y luego discutiremos la contención.

Recipientes

Para ejecutar software en Kubernetes, debe estar en un contenedor. Debido a esto, hay ciertas consideraciones generales de seguridad que describe Kubernetes:

• Escanear: Escanee sus contenedores en busca de vulnerabilidades conocidas. Herramientas como Clair de CoreOS pueden ser útiles.
• Firmar imágenes de contenedor: Mantenga la confianza para el contenido del contenedor mediante Docker Content Trust, integrado en Docker Engine. El proyecto Portieris de IBM se puede emplear como controlador de admisión para hacer cumplir la confianza de contenido para imágenes firmadas correctamente.
• Controlar los privilegios de los usuarios: Busque crear usuarios dentro de los contenedores que tengan el menor nivel de privilegios del sistema operativo necesarios para llevar a cabo el objetivo del contenedor. 

Código

Al examinar el nivel de código de la aplicación, la guía de Kubernetes aborda algunos puntos:

• Permitir el acceso solo a través de TLS: Establezca el cifrado predeterminado de todo lo que está en tránsito, incluso entre los servicios de red detrás del firewall.
• Limitar intervalos de puertos de comunicación: exponga solo los puertos del servicio que sean absolutamente esenciales.
• Analizar código estático: Analice el código en busca de prácticas de codificación potencialmente inseguras.
• Prueba de ataques de sondeo dinámico: Emplee las herramientas OWASP para automatizar ataques comunes como inyección SQL, CSRF, etc.

Nube

Cada proveedor de nube proporciona amplias recomendaciones sobre cómo ejecutar cargas de trabajo de contenedores en su infraestructura de nube. Las ofertas de seguridad pueden ser diferentes para diferentes proveedores de nube y los usuarios deben ser meticulosos al seguir estas recomendaciones. En https:\/\/kubernetes.io\/docs\/concepts\/security\/#the-4c-s-of-cloud-native-security se encuentran enlaces a proveedores de nube populares y recomendaciones de seguridad.

La orientación general incluye:

• Restringir el acceso a la red: la mayoría de los proveedores de seguridad en la nube proporcionan seguridad de red mediante listas de control de acceso, por ejemplo, AWS proporciona grupos de seguridad que permiten segmentar las cargas de trabajo en grupos y permitir que las ACL se configuren por grupo.
• Restringir el acceso a la API: Idealmente, solo los servidores necesarios para gestionar un clúster deben tener acceso a los servidores de API.
• Restringir el acceso a las API del clúster de Kubernetes: Es mejor proporcionar al clúster acceso al proveedor de nube que siga el principio de privilegios mínimos para los recursos que necesita gestionar. Un ejemplo de Kops en AWS se puede encontrar aquí: https:\/\/github.com\/kubernetes\/kops\/blob\/master\/docs\/iam_roles.md#iam-roles.
• Restringir el acceso a 'etcd': Este directorio es donde existen los archivos de configuración en la nube para Kubernetes. Emplee siempre TLS para acceder a estos archivos y realizar modificaciones en ellos.
• Cifre todas las unidades, especialmente las unidades etcd: evite que los usuarios no autorizados vean archivos de configuración críticos y almacenes de datos que pertenecen a su clúster de Kubernetes.

Racimos

• Restrinja el acceso a la API de Kubernetes al clúster mediante RBAC.
• Autenticar todo el acceso a la API que controla el clúster.
• Cifre todas las claves secretas empleadas por el clúster, incluidos todos los datos de etcd.
• Controlar los aspectos de seguridad de los pods: los objetos de seguridad de los pods definen un conjunto de condiciones con las que un pod debe ejecutar para ser aceptado en el sistema.
• Controle la utilización de recursos: los nodos de Kubernetes que ejecutan su aplicación dependen unos de otros para la confiabilidad y el equilibrio de recursos. Por lo tanto, debe haber políticas que restrinjan la cantidad de recursos empleados por estos nodos.
• Controle todas las políticas de red de los pods mediante listas de control de acceso. Se trata de políticas de seguridad Norte-Sur. Para conocer las políticas dentro del centro de datos, consulte Contención a continuación.
• Restrinja todo el acceso de entrada para que sea a través de TLS.

Contención

Esto nos lleva a la quinta C de contención que evita la propagación de brechas que se inician desde un contenedor. La contención debe tener en cuenta algunas cosas para que sea más efectiva:

• Descubra los contenedores recién creados en tiempo real.
• Permita la segmentación automatizada de las nuevas cargas de trabajo de contenedores para que la seguridad esté presente automáticamente "al nacer".
• Centralice la visibilidad de los contenedores junto con otros entornos informáticos para obtener una vista única de las cargas de trabajo en contenedores y las máquinas virtuales, la nube privada y pública, porque no puede proteger lo que no puede ver.
• Aplique una política uniforme en todos los contenedores, y todo lo demás, para segmentar con una política unificada, independientemente del entorno. Esto evita múltiples herramientas puntuales para la segmentación de máquinas virtuales, servidores sin sistema operativo, nubes y contenedores.

Con un amplio enfoque de defensa en profundidad para contenedores, las organizaciones pueden estar seguras de la viabilidad de seguridad de los contenedores para implementarlos con mayor confianza.