Introducción a la seguridad de Kubernetes

Si bien cada vez son más las empresas que adoptan los contenedores y Kubernetes, su seguridad sigue siendo la mayor preocupación. La buena noticia es que tiene varias opciones para garantizar la seguridad de su implementación. En este artículo sobre la seguridad de Kubernetes, se detallan muchos de los pasos que puede dar para dar sus primeros pasos respecto de la seguridad de los contenedores.

Por lo general, en las imágenes de contenedores se originan varios puntos vulnerables, los cuales pueden introducirse en los entornos de nube. Uno de los aspectos fundamentales de una estrategia de seguridad efectiva consiste en adoptar las prácticas de diseño de imágenes seguras en toda la empresa. Si bien es importante realizar un análisis de las imágenes, también debe protegerlas para garantizar la seguridad de las aplicaciones en contenedores de forma anticipada, es decir, al inicio de su ciclo de vida.

Siga las prácticas recomendadas que se mencionan a continuación para diseñar imágenes de contenedores de forma segura:

1. Utilice imágenes de base con lo indispensable

   La imagen debe contener solo las bibliotecas y las herramientas que necesita el contenedor para reducir la superficie de ataque.

2. Elija imágenes de base de fuentes conocidas

   Si no va a diseñar sus imágenes desde cero, procure que provengan de fuentes confiables. Debe alojarlas en un registro de confianza y poder visualizar el Dockerfile y el código fuente de todos sus elementos. También es importante actualizar las imágenes de base con regularidad.

3. Especifique un usuario

   Si el Dockerfile no especifica un usuario, el contenedor se ejecutará de forma predeterminada con el superusuario, el cual amplía la posible superficie de ataque y permite aumentar los privilegios si la aplicación se ve comprometida.

4. Verifique las imágenes de Docker

   Si bien garantizar la autenticidad de las imágenes es una tarea difícil, es un componente importante a la hora de diseñar imágenes seguras. Toda imagen de base debe contar con firma y validación. Una manera de garantizar la autenticidad de todas ellas es extraerlas únicamente de registros de confianza.

5. Analice las imágenes para encontrar puntos vulnerables

   Es fundamental que encuentre y solucione los puntos vulnerables de las imágenes de contenedores, incluso aquellas que provienen de las bibliotecas open source.

6. No almacene información confidencial

   Los datos confidenciales, como las credenciales o las claves, no deben incluirse en las imágenes de contenedores.

7. Establezca los límites de los recursos

   Al restringir la cantidad de recursos de CPU o memoria a los que tiene acceso un contenedor, se reducirá el daño que puede ocasionar si se utiliza de forma inadecuada.

8. Delimite los privilegios

   Restrinja al máximo la cantidad de privilegios de los contenedores y, mediante la configuración, asegúrese de que no se puedan ampliar.

9. Utilice compilaciones de varias etapas

   Puede aprovechar las herramientas que se utilizan para generar y compilar aplicaciones cuando estas se ejecutan en los sistemas de producción. En lugar de utilizar las mismas imágenes en las fases de desarrollo y producción, utilice los Dockerfiles de varias etapas para eliminar cualquier herramienta de compilación innecesaria de las imágenes para la ejecución. Los depuradores también se deben eliminar de las imágenes de producción.

10. Utilice prácticas de codificación centradas en la seguridad

    Se puede utilizar un linter para detectar el código no seguro durante el proceso de desarrollo.

Estos pasos son específicos del diseño de imágenes. Sin embargo, los principios que permiten crearlas de manera segura también deberían regir las prácticas de seguridad en otras partes de la aplicación. Estas prácticas incluyen reducir al máximo la superficie de ataque, limitar los privilegios y ajustar las configuraciones, en vez de utilizar los ajustes predeterminados de Kubernetes y otros aspectos de la stack propia de la nube.

La organización Center for Internet Security (CIS) se encarga de desarrollar las prácticas recomendadas en materia de seguridad cibernética, para lo cual utiliza la colaboración abierta. Entre sus herramientas más conocidas se encuentran los indicadores de CIS.

Las empresas pueden utilizar estos indicadores para reforzar los entornos de Kubernetes. Además, disponen de varias herramientas open source y comerciales que verifican automáticamente las configuraciones y los controles establecidos en los indicadores de CIS para identificar aspectos no seguros.

Si bien estos indicadores ofrecen una serie de verificaciones útiles para la configuración, las empresas deberían utilizar otros métodos para asegurarse de aplicar las prácticas recomendadas a Kubernetes, como la implementación de políticas de red, los ajustes del control de acceso basado en funciones (RBAC), los privilegios de administrador y otros medios que protejan al servidor de la API de Kubernetes.

El control de acceso basado en funciones (RBAC) de Kubernetes proporciona el método estándar para gestionar las autorizaciones de los extremos de la API de Kubernetes. La configuración del RBAC de su clúster controla quién puede ejecutar determinados verbos u operaciones en ciertos tipos de recursos dentro de algunos espacios de nombres. Por ejemplo, se puede ajustar la configuración para que el usuario "alicia" pueda ver los recursos "pod" en el espacio de nombre external-api. La API del RBAC incluye cuatro objetos declarativos: Role, ClusterRole, RoleBinding y ClusterRoleBinding.

La diferencia entre Role y ClusterRole es que el primero es una regla que establece los permisos para espacios de nombres individuales, mientras que el segundo otorga permisos para todo el clúster o para varios espacios de nombres. Cada regla está formada por una combinación de verbos, tipos de recursos y selectores de espacios de nombres.

El enlace de funciones vincula a un usuario, un grupo de usuarios o una cuenta de servicio (también conocidos como sujetos) a una función, y les otorga los permisos definidos en ella. En el caso del clúster, este enlace une el ClusterRole con todos los espacios de nombres en el clúster. De esta forma, el RoleBinding otorga permisos dentro de un espacio de nombres, mientras que el ClusterRoleBinding lo hace en todo el clúster.

En función de nuestra experiencia con los clientes, descubrimos cuáles son los cinco errores más comunes que se deben buscar en los ajustes de configuración del RBAC.

Primer error de configuración:función de administrador del clúster otorgada innecesariamente

La función integrada cluster-admin brinda acceso ilimitado a todo el clúster. Es posible que, durante la transición del controlador heredado ABAC al RBAC, algunos administradores y usuarios pasen por alto las advertencias descritas en la documentación pertinente y repliquen el tipo de configuración permisiva de este controlador. Esto implica que, si a los usuarios o los grupos se les asigna habitualmente la función de administradores del clúster, los errores de la cuenta, o bien sus puntos vulnerables, pueden tener efectos perjudiciales. Por lo general, las cuentas de servicio no suelen necesitar este tipo de acceso. En ambos casos, se debería crear una función (Role) o una función del clúster (ClusterRole) más personalizada y concedérsela solo a los usuarios que particularmente la necesitan.

Segundo error de configuración:uso inadecuado de la agrupación de funciones

A partir de la versión 1.9 de Kubernetes, se puede usar la agrupación de funciones para simplificar la concesión de privilegios, ya que permite agregar los nuevos a las funciones actuales. Sin embargo, si estas agrupaciones no se revisan cuidadosamente, pueden modificar el uso previsto de una función. Por ejemplo: la función system:view puede agregar indebidamente reglas con verbos que no sean "visualizar" (view), con lo cual se incumpliría la regla de que los sujetos con la función system:view no pueden modificar el clúster.

Tercer error de configuración:duplicación de la concesión de funciones

Es posible que se superpongan las definiciones de las funciones, lo cual otorgaría a los sujetos el mismo acceso de distintas maneras. En algunos casos, los administradores lo hacen de forma intencional, pero esta superposición dificulta saber cuáles son los permisos otorgados a los distintos sujetos. De hecho, puede dificultar también la revocación de accesos si un administrador no se percata de que varios enlaces de funciones conceden los mismos privilegios.

Cuarto error de configuración:funciones sin utilizar

La gestión del RBAC se vuelve más compleja cuando se crean funciones que luego no se otorgan a nadie. Del mismo modo, no es posible visualizar con claridad las configuraciones importantes cuando se conceden funciones a sujetos que no existen (como cuentas de servicios en espacios de nombres eliminados o usuarios que ya no pertenecen a la empresa). Por lo general, no hay riesgo alguno en la eliminación de las funciones que no se utilizan o no están activas, y esto permite enfocarse en las que sí lo están.

Quinto error de configuración:concesión de funciones que no existen

Puede suceder que los enlaces de funciones hagan referencia a algunas que no existen. Si se reutiliza un nombre para una función con un propósito distinto, es posible que los enlaces de funciones inactivos inesperadamente concedan privilegios a sujetos que no eran los que el creador de esta función tenía en mente.

Cuando se configuran adecuadamente los enlaces y las funciones del RBAC del clúster, se reduce el impacto de las aplicaciones en riesgo, el traspaso de las cuentas de usuarios, los errores de las aplicaciones o los errores humanos.

Si bien las máquinas virtuales (VM) y los contenedores poseen arquitecturas muy diferentes, son lo suficientemente parecidas como para generar confusión. Además, los aspectos que los diferencian tienen implicancias importantes en materia de seguridad. Ambos ofrecen diferentes niveles de aislamiento y permiten la portabilidad. Las máquinas virtuales son completamente autosuficientes, ya que cuentan con su propio sistema operativo y no comparten recursos con otras máquinas virtuales. En cambio, los contenedores sí comparten los hosts entre ellos, lo cual dificulta la posibilidad de contar con un límite seguro.

Los contenedores y Kubernetes presentan un paradigma arquitectónico muy diferente, el cual requiere un enfoque de seguridad distinto. Las técnicas de seguridad consolidadas basadas en el host y en las máquinas virtuales no se pueden utilizar en los contenedores, como la aplicación de firewalls de red en un perímetro definido. Un aspecto fundamental de las prácticas recomendadas en materia de seguridad de las máquinas virtuales es la aplicación de parches. Sin embargo, en el caso de los contenedores, no se pueden aplicar si están en ejecución, así que deberá actualizar sus imágenes y volver a diseñarlos.

Para proteger los contenedores necesita:

• Controlar las conexiones entre contenedores
• Garantizar que no posean puntos vulnerables conocidos
• Evitar que tengan acceso de superusuario
• Restringir los permisos y el acceso únicamente a los elementos necesarios para el funcionamiento de la aplicación

Kubernetes aumenta la complejidad e introduce nuevos posibles riesgos de seguridad. Una buena estrategia para proteger las aplicaciones en contenedores se basa en gestionar las configuraciones de Kubernetes y las políticas de red.

Además, debido a los cambios en el flujo de trabajo que derivan de la adopción de las aplicaciones en contenedores, se vuelve fundamental integrar la seguridad a todo el ciclo de vida, es decir, desde la configuración de las imágenes y los contenedores. No es posible incorporar la seguridad en la etapa final del proceso de desarrollo, justo antes de que se implementen.

La seguridad de las aplicaciones en contenedores implica controlar el origen de todos los elementos, incluso de los que son open source; gestionar las configuraciones; analizar las imágenes; y habilitar los controles detallados de acceso basado en funciones. Los contenedores y Kubernetes exigen un enfoque de seguridad diferente. Sin embargo, su naturaleza declarativa e inmutable les permite desarrollar las aplicaciones más seguras de todos los tiempos, siempre y cuando se configuren adecuadamente.

En Kubernetes, los contenedores se ejecutan dentro de los pods, uno de los tantos objetos de este sistema, cuyo tiempo de ejecución se puede configurar y aplicar mediante una combinación del contexto de seguridad en la especificación del pod, las políticas de seguridad de los pods (PSP) o un controlador de admisión, como Open Policy Agent (OPA), que gestiona los accesos.

El contexto de seguridad se define en el manifiesto de implementación y le permite determinar los requisitos específicos para cada carga de trabajo, ya sea para un pod o un contenedor. Las políticas de seguridad de los pod son un recurso de Kubernetes en el clúster que se encarga de controlar el contexto de seguridad con el que se pueden ejecutar los pods. Cuando se activan para un clúster en particular, el controlador de admisión denegará la creación de los pods que no cumplan con las PSP asociadas.

Restricción de los privilegios del tiempo de ejecución de los contenedores:

• No ejecute los procesos de la aplicación como superusuario. En el campo runAsUser, establezca el valor MustRunAsNonRoot.
• No permita que se puedan ampliar los privilegios. En el campo allowPrivilegeEscalation, establezca la opción false.
• Utilice un sistema de archivos de superusuario de solo lectura. En el campo readOnlyRootFilesystem, establezca la opción true.
• Utilice el montaje predeterminado del sistema de archivos /proc (oculto).
• No utilice el espacio de procesamiento ni la red del host. En los campos hostPID, hostNetwork y hostIPC, establezca la opción false.
• Deje de lado las funciones de Linux que no utilice y evite agregar otras si la aplicación no las necesita realmente.
• Opte por las opciones de SELinux para un control más preciso de los procesos.
• Asegúrese de que cada aplicación tenga su propia cuenta de servicio de Kubernetes.
• No instale las credenciales de la cuenta de servicio en un contenedor si este no necesita acceder a la API de Kubernetes.

Uso de los espacios de nombres de Kubernetes

Los espacios de nombres de Kubernetes también permiten incluir los objetos del clúster, para que pueda gestionarlos de forma más detallada. En tal caso, se pueden aislar los contenedores, los pods, los servicios y las implementaciones dentro de un espacio de nombres utilizando ciertos controles, como las políticas de red de Kubernetes; o bien, restringiendo su acceso con el RBAC.

Antes de implementar las cargas de trabajo en los clústeres, planifique de qué forma desea asignar los espacios de nombres. Si utiliza uno por aplicación, aumentará la capacidad de control. Sin embargo, esto generará costos de gestión adicionales al asignar los privilegios del RBAC y las políticas de red predeterminadas. Si decide agrupar varias aplicaciones en un espacio de nombres, debe tener en cuenta si tienen requisitos de RBAC en común y si sería seguro otorgar esos privilegios a las cuentas de servicios y a los usuarios que necesitan acceder a la API de Kubernetes en ese espacio de nombres.

En términos generales, la gestión de la configuración es la práctica de ingeniería que consiste en establecer políticas relativas a las configuraciones y en garantizar que se apliquen de manera uniforme en toda la empresa, durante todo el ciclo de vida de las aplicaciones. En el caso de las aplicaciones desarrolladas en la nube, es fundamental establecer sus ajustes para gestionar los riesgos de seguridad, principalmente porque las configuraciones predeterminadas de los contenedores y de Kubernetes no son seguras o suelen presentar errores.

Es necesario automatizar la gestión de estas configuraciones. Además, los recursos de protección, los cuales se basan en las políticas de seguridad de la empresa, se deben manejar de forma concentrada para que los desarrolladores o los operadores individuales no tengan que encargarse de gestionar las cargas de trabajo manualmente.

Según IBM, el 95 % de los fallos de seguridad en la nube se deben a errores humanos. Como las aplicaciones son cada vez más complejas, ya que se ejecutan en sistemas distribuidos en contenedores y en Kubernetes, también aumenta el riesgo de problemas de configuración. Y como no existen herramientas para gestionar la configuración desde un solo lugar, es muy difícil que las empresas puedan aplicar las políticas relacionadas de manera uniforme. Esto es aún más difícil si se utilizan entornos multicloud o de nube híbrida, ya que cada uno de ellos posee requisitos específicos diferentes. Por otro lado, es usual que algunos desarrolladores y operadores no conozcan todas las prácticas recomendadas que deben seguir para garantizar la seguridad de la configuración.

En muchos casos, permiten el acceso de superusuario, otorgan privilegios de administrador o no delimitan adecuadamente los recursos, lo cual es la forma más sencilla de configurar las aplicaciones para que se ejecuten, pero también la menos segura. Si se utilizan las herramientas adecuadas, se puede integrar la gestión de la configuración al flujo de trabajo de DevOps, de manera que no ralentice la velocidad de desarrollo. Se recomienda esta práctica, ya que elimina la tensión que se genera al tener que realizar lanzamientos con rapidez, pero sin dejar de proteger las configuraciones de las cargas de trabajo.

La gestión de la configuración debería permitirle acceder a los ajustes y establecer cuáles están permitidos, de manera que las implementaciones o las compilaciones no seguras o que presentan riesgos fallen automáticamente. Es necesario que las empresas puedan visualizar todas las configuraciones importantes de los contenedores y de Kubernetes a través de un solo panel, para conocer los posibles riesgos.

A continuación, se mencionan los pilares de la gestión de la configuración de los contenedores y de Kubernetes:

• Controles de acceso basado en funciones (RBAC): las empresas deben poder detectar las funciones innecesarias o los ajustes demasiado permisivos.
• Información confidencial: una buena herramienta de gestión de la configuración debe restringir el acceso a la información confidencial de forma preventiva.
• Evaluaciones basadas en políticas: para cualquier empresa, es fundamental establecer políticas de seguridad. Además, sería muy importante poder verificar las implementaciones en función de esas políticas predeterminadas.
• Privilegios: estos deberían asignarse según los principios de privilegios mínimos.
• Límites de recursos: es necesario delimitar la cantidad de CPU y memoria de la que disponen tanto los contenedores como los clústeres de Kubernetes.
• Políticas de red: se utilizan para delimitar al máximo la comunicación entre las partes de la aplicación para reducir los posibles daños en caso de que un contenedor se vea comprometido.

La forma más sencilla de comenzar a gestionar la configuración consiste en seguir las prácticas recomendadas del sector, como los indicadores de CIS. A medida que las empresas avanzan en la adopción de los contenedores, se vuelve fundamental crear políticas de control en torno a la gestión de la configuración. Esta debe contemplar los ajustes tanto de los contenedores como de Kubernetes, ya que la configuración adecuada de ambos entornos garantiza una estrategia de seguridad sólida.

Kubernetes permite de forma predeterminada que todos los pods de un clúster se comuniquen libremente, lo cual facilita el funcionamiento de las aplicaciones, pero también genera un riesgo de seguridad. A pesar de ello, Kubernetes cuenta con funciones de cumplimiento integradas que se pueden configurar para restringir la comunicación entre los recursos, como la segmentación de las redes. Algunos marcos de cumplimiento, como el PCI DSS, también utilizan esta estrategia.

La segmentación de las redes consiste en dividirlas en subredes más pequeñas. Desde el punto de vista de la seguridad, la principal ventaja es que si algún agente malintencionado obtiene acceso a una aplicación, no le será posible llegar a las demás que se ejecuten en el mismo clúster de Kubernetes. También sirve para aislar las cargas de trabajo más importantes o que se encuentran dentro del alcance de un marco de cumplimiento específico de otras partes de la aplicación.

Las políticas deben ser tan restrictivas como sea posible. Esto quiere decir que los contenedores individuales solo deben poder comunicarse con aquellos que sean necesarios para el funcionamiento previsto de la aplicación.

En Kubernetes, se utilizan políticas de red para segmentarlas, ya sea mediante funciones de implementación propias de esa plataforma o mediante el uso de capas de infraestructura adicionales, como una malla de servicios.

De forma predeterminada, los pods, los contenedores y los nodos se pueden comunicar libremente, ya sea que pertenezcan al mismo espacio de nombres o a diferentes. Como primera práctica recomendada, conviene aplicar políticas de red que restrinjan por completo la comunicación. Sin embargo, la mejor estrategia es enumerar sistemáticamente los pods que se deben comunicar entre sí, ya que esto es esencial. También se debe permitir la entrada al Internet público, y la salida de él, e incluir en una lista solo los pods que necesitan hacerlo.

Además, al segmentar cada vez más las redes y modificar las políticas asociadas a ellas, se corren ciertos riesgos operativos, cuyas consecuencias inesperadas podrían reducirse con una herramienta que permita visualizar el posible impacto en la aplicación de estos ajustes al sistema.

Ninguna empresa podrá proteger por completo sus aplicaciones o infraestructuras de TI. La seguridad implica no solo conocer los riesgos y los aspectos positivos y negativos de las diferentes medidas que se pueden tomar, sino también ordenarlas según su prioridad. Las empresas crean perfiles de riesgo para describir aquellos que afectan su seguridad y establecer las políticas y las prácticas que utilizarán para gestionarlos. Si bien deben aceptar que no podrán eliminarlos en su totalidad, es importante que tengan en claro hasta qué punto los considerarán aceptables. Por eso, no solo se debe llevar a cabo un análisis en la empresa en general, sino también en las distintas aplicaciones. Habrá diferencias entre el perfil de riesgo de las cargas de trabajo más importantes, o que deben cumplir con ciertos requisitos normativos, y las demás.

Este análisis también sirve para evaluar el alcance que tienen los puntos vulnerables del entorno. Como no es posible responder a cada uno de ellos, se necesita una estrategia de seguridad sólida que evalúe el riesgo que presentan y establezca un orden de prioridad para abordarlos correctamente.

En el caso de las aplicaciones distribuidas y en contenedores, será más difícil entender y priorizar su perfil de riesgo, ya que seguramente poseen cientos de puntos vulnerables con diferentes niveles de gravedad. Los riesgos de seguridad de un punto vulnerable dependerán de estos factores:

• Si el punto vulnerable tiene un nivel de gravedad elevado
• Si la aplicación está dirigida al público
• Si la aplicación se encuentra en la etapa de producción
• Si la aplicación se encuentra dentro del alcance de las normativas de cumplimiento
• Si la aplicación tiene acceso a la información confidencial
• Si la cantidad de privilegios del contenedor es elevada
• Si la red del contenedor se encuentra expuesta

Si bien las empresas deben definir de antemano la cantidad de riesgo que consideran aceptable, la elaboración de perfiles no es una actividad estática. En algunas ocasiones, se pueden establecer políticas internas que indiquen el momento en que se deben abordar los puntos vulnerables, según su gravedad. Por otro lado, la evaluación de riesgos de seguridad debe realizarse permanentemente durante el tiempo de ejecución, sobre todo si se trata de aplicaciones en contenedores.

No es recomendable clasificar manualmente los posibles incidentes, los puntos vulnerables y las políticas de seguridad, ya que resulta agotador y da lugar a errores. A veces, la creación de perfiles de riesgo no se puede llevar a cabo sin herramientas automatizadas que detecten los riesgos y los clasifiquen según un orden de prioridad, en especial si debe hacerse en toda la empresa. En Kubernetes, se utilizan los datos declarativos y contextuales de la plataforma para crear los perfiles con éxito y automatizar el proceso de priorización. Gracias a ello, los equipos de seguridad pueden centrarse en corregir primero las implementaciones que presentan mayor riesgo, en lugar de dedicar tiempo a la creación de perfiles.

Lo ideal sería utilizar los perfiles de riesgo como una herramienta reactiva y preventiva a la vez. Esto significa que la información que se recopila tras detectar y solucionar una implementación se puede volver a utilizar para encontrar otras similares y abordar los posibles riesgos de seguridad con antelación.

La seguridad del tiempo de ejecución es un mecanismo de protección fundamental contra los agentes malintencionados. Se recomienda que los puntos vulnerables en los que no se aplicaron parches y las configuraciones o las credenciales no seguras se detecten durante el diseño o el desarrollo. Sin embargo, es posible que surjan nuevos fallos o que algunos pasen inadvertidos en las primeras etapas, así que resulta fundamental poder detectarlos y abordarlos también durante la ejecución. Esto también es importante por razones de cumplimiento normativo y porque constituye un mecanismo de defensa frente a las amenazas internas.

Las cargas de trabajo declarativas e inmutables necesitan un modelo completamente nuevo para detectar los posibles incidentes de seguridad en el tiempo de ejecución, y responder a ellos. Suele ser más sencillo proteger varios aspectos de esta etapa en los contenedores que en las aplicaciones basadas en máquinas virtuales (VM). Esto se debe al hecho de que los contenedores generalmente ejecutan una cantidad mínima de procesos y a la naturaleza declarativa de Kubernetes. Por otro lado, los parches de seguridad no se aplican de la misma forma en ambos entornos. En el caso de los contenedores en ejecución, se los debe considerar inmutables, por lo que debemos detenerlos, actualizarlos y reiniciarlos.

El proceso de detección es fundamental para la seguridad durante el tiempo de ejecución, lo cual implica conocer el modo en que se comporta normalmente la aplicación y averiguar si alguna actividad se aleja mucho de ello. Algunas de las actividades que se podrían rastrear son las solicitudes de red y las ejecuciones de los procesos. Si no se comportan acorde a lo esperado, podría ser una señal de actividad sospechosa o maliciosa. Por ejemplo, intentar conectarse a Internet cuando no está permitido. En cualquier caso, esa actividad fuera de lo normal puede indicar la necesidad de abordar algún aspecto.

La detección de anomalías siempre debe estar vinculada a un proceso de respuesta ante incidentes y suele ser más precisa en los contenedores que en las cargas de trabajo de las máquinas virtuales, ya que estos solo contienen una aplicación, lo cual facilita la identificación de los comportamientos que no se ajustan a lo esperado.

Según el tipo de comportamiento inusual, a veces conviene responder de forma automática, es decir, que la plataforma detenga los pods o contenedores afectados. En otras ocasiones, es más adecuado enviar una alerta y realizar una evaluación manual. Sin embargo, para acortar los tiempos de respuesta y aumentar la seguridad general de las aplicaciones en contenedores, es necesario automatizar la mayor cantidad de respuestas ante incidentes posible.

El kubelet es el agente principal que se ejecuta en cada uno de los nodos. Si no se lo configura bien, puede quedar expuesto a una serie de riesgos de seguridad. Para establecer sus ajustes, puede utilizar argumentos en el kubelet ejecutable mientras está en funcionamiento o un archivo de configuración.

Si desea encontrar dicho archivo, ejecute el siguiente comando:

ps -ef | grep kubelet | grep config

Busque el argumento --config, el cual le indicará su ubicación.

Luego, ejecute el siguiente comando en cada nodo:

ps -ef | grep kubelet

Asegúrese de que el resultado tenga las siguientes características:

El argumento --anonymous-auth debe estar configurado como false. En el artículo sobre kubelets al que hicimos referencia anteriormente, se explica que los agentes malintencionados aprovechan cuando el servidor del kubelet autoriza las solicitudes anónimas (y no autenticadas) debido a errores en su configuración.

El argumento --authorization-mode debe estar configurado como AlwaysAllow, si existiese. En caso contrario, asegúrese de que --config especifique un archivo de configuración de kubelet que no esté configurado como AlwaysAllow.

El argumento --client-ca-file debe estar configurado y su valor debe ser la ubicación del archivo de autoridad de certificación del cliente. En caso contrario, asegúrese de que --config especifique un archivo de configuración de kubelet, cuyo valor authentication: x509: clientCAFile sea la ubicación del archivo de autoridad de certificación del cliente.

El argumento --read-only-port debe estar configurado y su valor debe ser 0. En caso contrario, asegúrese de que --config especifique un archivo de configuración de kubelet y que el valor de readOnlyPort sea 0.

El argumento --protect-kernel-defaults debe estar configurado como true. En caso contrario, asegúrese de que --config especifique un archivo de configuración de kubelet y que el valor de protectKernelDefaults sea true.

El argumento --hostname-override no debe estar configurado, para garantizar que no haya inconvenientes en la configuración del protocolo TLS entre el kubelet y el servidor de la API.

El argumento --event-qps debe estar configurado y su valor debe ser 0. En caso contrario, asegúrese de que --config especifique un archivo de configuración de kubelet y que el valor de eventRecordQPS sea 0.

El valor de los argumentos --tls-cert-file y --tls-private-key-file debe ser el adecuado; o bien, el archivo de configuración de kubelet que especifica --config debe tener los ajustes adecuados para tlsCertFile y tlsPrivateKeyFile. Esta configuración garantiza que todas las conexiones se realicen a través del protocolo TLS en los kubelets.

Los argumentos RotateKubeletServerCertificate y --rotate-certificates deben estar configurados como true, siempre que los kubelets obtengan sus certificados del servidor de la API. Además, asegúrese de que solo utilicen métodos sólidos de cifrado.

El servidor de la API de Kubernetes gestiona las llamadas a la API de REST de los usuarios o las aplicaciones que se ejecutan en el clúster para poder administrarlo. Se lo considera la puerta de enlace al plano de control de Kubernetes, y puede acceder a él usando el kubectl del servidor y las bibliotecas de clientes; o bien, enviando solicitudes a la API directamente. Una forma de gestionar sus autorizaciones es con el control de acceso basado en funciones (RBAC) de Kubernetes. También puede utilizar los controladores de admisión para validar las solicitudes que se envían al servidor de la API.

El primer paso para proteger el servidor de la API es controlar el acceso a él. Para reforzar sus medidas de seguridad, Center for Internet Security (CIS) ofrece una serie de prácticas recomendadas de configuración.

Ejecute el siguiente comando en el nodo maestro:

ps -ef | grep kube-apiserver

Asegúrese de que el resultado tenga las siguientes características:

El argumento --anonymous-auth debe estar configurado como false. Esto garantiza que las solicitudes no rechazadas por otros métodos de autenticación no se consideren anónimas y, por lo tanto, se admitan en función de las políticas.

El argumento --basic-auth-file no debe estar configurado. La autenticación de acceso básica utiliza credenciales con texto sin formato en lugar de tokens o certificados.

El argumento --insecure-allow-any-token no debe estar configurado. Esto garantiza que solo se admitan los tokens seguros autenticados.

El argumento –kubelet-https no debe estar configurado; o bien, debe mostrarse como true. Esto garantiza que el protocolo de seguridad de la capa de transporte (TLS) proteja las conexiones en tránsito entre el servidor de la API y los kubelets.

El argumento --insecure-bind-address no debe estar configurado. Esto evitará que el servidor de la API se enlace con una dirección no segura, lo cual no solo impedirá el acceso no autenticado y no cifrado al nodo maestro, sino que también reducirá el riesgo de que la información confidencial en tránsito quede expuesta.

El argumento --insecure-port debe estar configurado como 0. Esto evitará que el servidor de la API se utilice en un puerto poco seguro, lo cual no solo impedirá el acceso no autenticado y no cifrado al nodo maestro, sino que también reducirá el riesgo de que algún agente malintencionado tome el control del clúster.

El argumento --secure-port no debe estar configurado o su valor debe ser un número entero entre 1 y 65535. El objetivo es asegurarse de que todo el tráfico esté protegido por la autenticación y la autorización que ofrece el protocolo HTTPS.

El argumento --profiling debe estar configurado como false. A menos que esté experimentando bloqueos o que necesite solucionar algún problema, no necesitará utilizar la herramienta de análisis del rendimiento. Si la habilita, expondrá innecesariamente los detalles del sistema y el programa.

El argumento --repair-malformed-updates debe estar configurado como false, lo cual garantiza que el servidor de la API rechace las solicitudes de los clientes que se crearon de manera incorrecta intencionalmente.

El valor del argumento --enable-admission-plugins no debe incluir el controlador AlwaysAdmit. Si lo configura para que admita todas las solicitudes, aceptará incluso aquellas que no especifica el plugin de control de admisión y, por lo tanto, reducirá su efectividad.

El valor del argumento --enable-admission-plugins debe incluir el controlador AlwaysPullImages. Con esta configuración, los usuarios no podrán extraer imágenes del nodo y enviarlas a los pods solo con el nombre de la imagen. Si habilita este controlador, siempre se extraerán antes de iniciar un contenedor, lo que requerirá contar con credenciales válidas.

El valor del argumento --enable-admission-plugins debe incluir el controlador SecurityContextDeny. Esta medida de control impide personalizar el contexto de seguridad de los pods de manera diferente a lo que se establece en su política de seguridad.

El valor del argumento --disable-admission-plugins no debe incluir el controlador NamespaceLifecycle. No desactive esta configuración, ya que impide que los objetos se creen en espacios de nombres que no existen o que se eliminarán.

El argumento --audit-log-path debe especificar la ruta de acceso adecuada para almacenar los registros de auditoría. Se recomienda habilitar la auditoría de los elementos de Kubernetes (entre ellos, el servidor de la API de Kubernetes) siempre que sea posible.

El valor del argumento --audit-log-maxage debe ser 30 o cualquier otro número que represente la cantidad de días que debe guardar los archivos de registro de auditorías para cumplir con las políticas internas y externas de conservación de datos.

El valor del argumento --audit-log-maxbackup debe ser 10 o cualquier otro número que le permita cumplir con los requisitos normativos para la conservación de archivos de registro antiguos.

El valor del argumento --audit-log-maxsize debe ser 100 o cualquier otro número que le permita cumplir con los requisitos normativos. Tenga en cuenta que el número 100 representa 100 MB.

El argumento --authorization-mode no debe estar configurado como AlwaysAllow. Esta configuración garantiza que el servidor de la API solo admita las solicitudes autorizadas, especialmente en los clústeres de producción.

El argumento --token-auth-file no debe estar configurado. Cuando se configura, utiliza la autenticación estática con token, la cual tiene muchos fallos de seguridad. En su lugar, aplique otros métodos de autenticación, como los certificados.

El argumento --kubelet-certificate-authority debe estar configurado. Esto impide que se produzca un ataque de intermediario cuando se establece una conexión con el servidor de la API y el kubelet.

Los argumentos --kubelet-client-certificate y --kubelet-client-key deben estar configurados. De este modo, el servidor de la API puede autenticarse en los extremos HTTPS del kubelet, lo cual no hace de forma predeterminada.

El argumento --service-account-lookup debe estar configurado como true. Esto evita que haya un caso en el que el servidor de la API verifique solo la validez del token de autenticación, sin asegurarse de que el de la cuenta de servicio que se incluye en la solicitud esté presente en etcd.

El valor del argumento --enable-admission-plugins debe incluir el controlador PodSecurityPolicy.

El argumento --service-account-key-file debe estar configurado en un par independiente de claves pública y privada para firmar los tokens de las cuentas de servicio. Si no lo especifica, utilizará la clave privada del certificado de TLS, y no podrá rotar las claves para los tokens de las cuentas de servicio.

Los argumentos --etcd-certfile y --etcd-keyfile deben estar configurados, de modo que el servidor de la API se identifique en el servidor de etcd con la clave y el certificado del cliente. Tenga en cuenta que el etcd almacena objetos confidenciales, así que todas las conexiones del cliente deben utilizar el protocolo de cifrado TLS.

El argumento --disable-admission-plugins debe estar configurado y no debe incluir el controlador ServiceAccount. Esto garantiza que, a la hora de crear un pod nuevo, no se utilice una cuenta de servicio predeterminada dentro del mismo espacio de nombres.

Los argumentos --tls-cert-file y --tls-private-key-file deben estar configurados, de modo que el servidor de la API solo trabaje con el tráfico HTTPS utilizando el protocolo TLS.

El argumento --client-ca-file debe estar configurado, lo que garantiza que exista la autenticación del protocolo TLS y de los certificados del cliente para las implementaciones de los clústeres de Kubernetes.

El argumento --etcd-cafile debe estar configurado, de manera que el servidor de la API deba verificarse ante el servidor etcd por medio de un archivo de autoridad de certificación SSL.

El argumento --tls-cipher-suites debe estar configurado de manera tal que utilice métodos sólidos de cifrado.

El argumento --authorization-mode debe estar configurado e incluir Node. Esto determina los objetos asociados a sus nodos que pueden leer los kubelets.

El argumento --enable-admission-plugins debe estar configurado e incluir el valor NodeRestriction. Este plugin garantiza que cada kubelet solo pueda modificar su propio objeto de la API de Node y los de la API del pod asociados a su nodo.

El argumento --encryption-provider-config debe estar configurado en un archivo EncryptionConfig, el cual debe contener todos los recursos necesarios. Esto permite que todos los objetos de la API de REST que están en el almacén de clave-valor de etcd se cifren en reposo.

Asegúrese de utilizar el cifrado aescbc para todos los recursos que desee, ya que se considera el más sólido.

El argumento --enable-admission-plugins debe incluir el controlador EventRateLimit, el cual permite delimitar la cantidad de eventos que acepta el servidor de la API para optimizar el rendimiento del clúster.

El argumento --feature-gates no debe estar configurado con un valor que contenga AdvancedAuditing=false. En otras palabras, asegúrese de que la auditoría avanzada no esté habilitada para poder realizar tareas de auditoría e investigación.

El argumento --request-timeout no debe estar configurado o debe estarlo adecuadamente (es decir, el valor no debe ser ni muy pequeño ni muy grande). El valor predeterminado es 60 segundos.

El argumento --authorization-mode debe estar configurado e incluir el RBAC de Kubernetes.

Esto garantiza que el RBAC esté habilitado. Asimismo, es conveniente seguir algunas otras recomendaciones para un mejor uso de este método de control:

• Evite otorgar a los usuarios la función de administradores del clúster. Debe utilizar esta función con mucha moderación (o no hacerlo directamente), ya que proporciona demasiado control sobe el entorno.
• Audite las reglas para combinar funciones y controle si las está utilizando correctamente.
• No otorgue permisos duplicados a los sujetos porque puede dificultar la revocación del acceso.
• Elimine regularmente las funciones que no se utilizan.

Uno de los mayores riesgos de los contenedores y de Kubernetes es que sus configuraciones predeterminadas no son seguras. Para reducir el riesgo de sufrir incidentes de seguridad, deberá cambiarlas lo antes posible y de manera uniforme en toda la empresa. Si no lo hace, ya sea por descuido o falta de conocimiento, o porque los flujos de trabajo no incluyen un paso de gestión de la configuración, las cargas de trabajo quedarán expuestas innecesariamente.

Ajustes predeterminados en los contenedores

Muchos de los puntos vulnerables de los contenedores surgen de las configuraciones predeterminadas y de las prácticas comunes que se siguen al diseñarlos. Tenga en cuenta los siguientes aspectos al momento de configurarlos:

• Especifique un usuario: si no lo hace, el sistema seleccionará al superusuario de forma predeterminada, lo cual podría otorgarle al contenedor acceso al host con privilegio de administrador.
• Verifique las imágenes: la configuración predeterminada no las verifica, lo cual da lugar a la posibilidad de que se extraigan imágenes comprometidas sin saberlo.
• Establezca los límites de los recursos: los límites no vienen predeterminados, pero es posible configurarlos. Si delimita la cantidad de memoria y CPU que puede utilizar un contenedor, impedirá que emplee una gran cantidad de recursos si se encuentra comprometido.
• Instale herramientas y bibliotecas de manera selectiva: cuantas menos haya en los contenedores, menor será la cantidad de recursos que podrán aprovechar los agentes malintencionados si logran acceder a ellos. No instale un conjunto estándar de herramientas en cada contenedor, sino solo aquellas que realmente necesite.
• Controle el acceso al registro por medio de listas: además de asegurarse de que las imágenes que utiliza sean de fuentes confiables, debe llevar un control estricto de los accesos al registro. La manera ideal de hacerlo es mediante una lista que solo permita el acceso a los usuarios confiables.

Ajustes predeterminados en Kubernetes

Kubernetes también proporciona muchas herramientas para mejorar la estrategia de seguridad de la empresa, pero deben configurarse adecuadamente para brindar beneficios. Estos son algunos de los aspectos principales que debe tener en cuenta en Kubernetes:

• Configure los controles de acceso basado en funciones (RBAC): el RBAC se encuentra habilitado de forma predeterminada desde la versión 1.6 de Kubernetes; sin embargo, debe configurarlo adecuadamente para aprovechar sus beneficios. Lo ideal es que los espacios de nombres brinden acceso, no los clústeres.
• Use espacios de nombres: De forma predeterminada, todo se ejecuta en el mismo espacio de nombres. Utilice la separación que ofrece este recurso para aislar las cargas de trabajo entre sí.
• Aplique las políticas de red de Kubernetes: estas no se encuentran configuradas desde un primer momento. Las empresas deben instalar un plugin de red para controlar el tráfico de entrada y salida de la aplicación, y configurar las políticas en consecuencia.
• Habilite el registro de auditorías: por lo general, esta función no se encuentra habilitada de forma predeterminada. Actívela para obtener información sobre los llamados inusuales a las API y las fallas en relación con las autorizaciones.

Por lo general, los primeros en utilizar los contenedores y Kubernetes son los equipos de desarrollo que no tienen mucha experiencia en materia de seguridad. Sin embargo, ignorar este aspecto pone en riesgo a las empresas, independientemente del tipo de infraestructura que utilicen.

Como ya mencionamos, los ajustes predeterminados de ambas tecnologías no son seguros, por lo que debe configurar las funciones de seguridad propias de Kubernetes para obtener sus beneficios. Para poner en marcha una aplicación con la mayor rapidez y facilidad posible, la mejor estrategia suele ser otorgarle muchos privilegios y establecer límites de recursos mucho más altos de lo necesario, o dejar los valores predeterminados como están. Si bien las empresas pueden verse tentadas a descuidar la seguridad en un primer momento, sobre todo a medida que se familiarizan con los contenedores y Kubernetes, esto supone un gran riesgo. Los agentes malintencionados se aprovechan de las aplicaciones en contenedores de Kubernetes con la misma facilidad con la que se aprovechan de las heredadas.

El principal riesgo de no hacer nada es que estas personas puedan comprometer las aplicaciones. La gravedad del asunto dependerá del sector al que pertenezca la empresa, el tipo de aplicación, y el alcance y el tipo de filtración. Asimismo, la probabilidad de que el descuido de la seguridad genere un incidente también dependerá de otros factores, por ejemplo, de si la aplicación tiene acceso a Internet o no.

Si no protege las aplicaciones en contenedores, corre el riesgo de que queden expuestas innecesariamente. Estos son algunos de los problemas que surgen cuando se pasa por alto la seguridad:

Puntos vulnerables de seguridad sin parches aplicados: todo el tiempo se descubren nuevos puntos vulnerables con diferentes niveles de gravedad. Tanto la comunidad open source como los agentes malintencionados tomarán conocimiento de ellos en cuanto se publiquen. Si no los aborda con rapidez, pondrá en riesgo su empresa.

Permisos demasiado flexibles: si bien el control de acceso basado en funciones (RBAC) se encuentra habilitado de forma predeterminada en Kubernetes, su implementación depende de los desarrolladores. Si no disponen de la orientación necesaria en materia de seguridad, es probable que creen cargas de trabajo demasiado accesibles.

Cargas de trabajo sin aislar: todo se ejecuta de manera predeterminada en un mismo espacio de nombres. Una práctica de seguridad básica consiste en usar varios de ellos para aislar las cargas de trabajo. Si no tiene en cuenta este paso, no logrará generar el nivel de aislamiento necesario.

Falta de control sobre las políticas de red: si bien las políticas de red de Kubernetes son las que permiten controlar el tráfico, las empresas deben implementar un plugin de red y configurarlas.

Si se demora en aplicar las medidas de control pertinentes, dará lugar a prácticas de seguridad desarticuladas: obstaculizará la revisión de la seguridad, ralentizará el desarrollo y aumentará el riesgo de incidentes. Por eso, debe ayudar a que las empresas implementen los controles de seguridad durante las primeras etapas del ciclo de desarrollo de software.

Si bien Kubernetes es el sistema predeterminado para la organización de los contenedores y posibilita su gestión, también introduce potenciales puntos vulnerables de seguridad en los entornos de infraestructura. Las diferencias entre la seguridad de las máquinas virtuales y de los contenedores y Kubernetes, así como la falta constante de personal capacitado en la seguridad de Kubernetes, pueden generar riesgos innecesarios.

Las prácticas recomendadas de seguridad para Kubernetes, igual que las de otros sistemas, incluyen no solo aquellas que protegen la aplicación y la infraestructura, sino también las organizativas y culturales que favorecen un control concentrado de la seguridad.

Elabore políticas de seguridad organizativas y garantice su cumplimiento. Esta medida constituye una práctica recomendada, independientemente de la stack de tecnología en la que se base su empresa. La seguridad es un proceso de gestión de los riesgos, por lo que no se puede confiar en que las herramientas decidan el nivel de riesgo aceptable para cada aplicación. Este tipo de decisiones deben tomarlas las personas, ya que pueden determinar el nivel de riesgo aceptable para la empresa en general, para las distintas unidades comerciales y para cada aplicación.

Controle la seguridad desde un solo lugar. En relación con el punto anterior, las empresas necesitan asegurarse de que se cumplan las políticas de seguridad y control que establecieron. Los equipos principales deben poder obtener información sobre las configuraciones y los puntos vulnerables de toda la aplicación distribuida, así como también visualizar fácilmente los posibles inconvenientes y establecer un orden de prioridad para abordarlos. Además, deben poder crear recursos de protección que brinden información instantánea en caso de que alguna compilación presente imágenes o configuraciones poco seguras, o cualquier otro posible riesgo de seguridad.

Aplique las medidas de seguridad al comienzo. Si tiene en cuenta la seguridad desde las primeras etapas del proceso de desarrollo, no solo evitará las demoras en las revisiones de seguridad y lanzará las aplicaciones con mayor rapidez, sino también disminuirá la probabilidad de que los errores generen puntos vulnerables o problemas de configuración de los que podrían aprovecharse los agentes malintencionados.

Aproveche la automatización. Como el entorno de Kubernetes abarca cada vez más clústeres y cientos de espacios de nombres, se torna casi imposible gestionar las configuraciones o supervisar el comportamiento del tiempo de ejecución de forma manual.

Las siguientes prácticas técnicas recomendadas le permitirán garantizar la mayor seguridad posible para Kubernetes:

• Actualice Kubernetes permanentemente: le recomendamos ejecutar una versión compatible y más moderna de la plataforma, ya que no siempre se lanzan parches de seguridad para las versiones anteriores.
• Utilice el control de acceso basado en funciones: es importante asignar privilegios mínimos de acceso, es decir, que solo se pueda acceder a la información y los recursos necesarios para un propósito.
• Restrinja la comunicación entre los pods: los límites deben ser lo más restrictivos posible para que los pods funcionen como se espera.
• Utilice la segmentación de las redes: cada pod debería poder comunicarse únicamente con los recursos internos o externos que necesita y permanecer aislado del resto.

La gestión de los puntos vulnerables es fundamental para la seguridad de las aplicaciones, ya que permite identificarlos, evaluarlos y corregirlos en todas las etapas del ciclo de vida de desarrollo del software. En el caso de las aplicaciones en contenedores desarrolladas en la nube, esta actividad debe automatizarse e integrarse a los procesos de DevOps relacionados con el diseño y la distribución de las aplicaciones. El entorno es demasiado complejo como para gestionar los puntos vulnerables de forma manual y, si se ralentiza demasiado la velocidad de desarrollo, las empresas pueden verse tentadas a saltarse las medidas de seguridad.

La gestión de los puntos vulnerables debe verse como un proceso constante que comienza en la etapa de diseño con el análisis y la evaluación de las imágenes, y continúa durante todo el ciclo de vida de la aplicación, en los entornos de prueba y producción.

Durante la etapa de diseño, además del análisis de las imágenes, también se deben implementar políticas en relación con los puntos vulnerables. Resulta fundamental poder realizar análisis según sea necesario durante el diseño de las imágenes, o cuando los contenedores ya están en funcionamiento, para detectar los puntos vulnerables que pueden haber sido expuestos durante el tiempo de ejecución. Para que el proceso sea efectivo, es preciso identificar las exposiciones tanto en los contenedores como en Kubernetes, ya que se pueden originar en ambos entornos.

No existen las aplicaciones completamente seguras. Sin embargo, gracias a una buena gestión de los puntos vulnerables, los equipos no solo pueden detectarlos, sino también obtener información adicional que les permita ordenarlos según su nivel de gravedad para la empresa. Por ejemplo, incluso un CVE de prioridad alta tendrá un perfil de riesgo distinto en función de la importancia de la carga de trabajo. Para lograr la mejor estrategia de seguridad posible, un buen proceso de gestión tiene que equilibrar, evaluar y priorizar las correcciones.

La gestión de los puntos vulnerables debe automatizarse principalmente en las aplicaciones desarrolladas en la nube. Si bien necesitamos de la inteligencia humana para definir las políticas, las herramientas deben encargarse de detectar los respectivos incumplimientos y de tomar las medidas adecuadas según el tipo de punto vulnerable, el nivel de riesgo y la etapa del ciclo de vida, ya sea detener las compilaciones de forma automática, bloquear las implementaciones o ajustar su ejecución en la producción según la demanda.

El análisis de las imágenes y de los puntos vulnerables debe comenzar en la etapa de diseño y continuar durante todo el ciclo de vida de la aplicación, incluso en la ejecución. Se pueden detectar nuevos fallos de seguridad en cualquier momento. Es fundamental para las empresas poder descubrirlos en las implementaciones en ejecución y solucionarlos de forma inmediata, ya que podrían presentar un riesgo directo para su seguridad.

Durante la etapa de diseño, no debería ser posible crear las imágenes que no cumplen con los requisitos, como aquellas con aspectos vulnerables graves o que se pueden solucionar. El equipo de DevOps debería recibir la información directamente en el sistema de CI. Luego, las herramientas de seguridad pueden aplicar controles de admisión, los cuales evitan de forma automática que se implementen los contenedores con aspectos vulnerables detectados en la imagen. Es fundamental conocer el modo en que se establecerá el orden de prioridad de las correcciones, según la gravedad del problema, la importancia de la carga de trabajo y la tolerancia general de la empresa a los riesgos de seguridad. Las empresas deben elaborar políticas personalizadas y utilizar herramientas que permitan aplicarlas a través de la automatización, tanto en la etapa de diseño como en la de implementación. Y los análisis se deben seguir realizando permanentemente, incluso cuando las implementaciones ya estén en ejecución.

Diferentes funciones de las herramientas para analizar imágenes

No todas las herramientas realizan el mismo tipo de verificación exhaustiva: algunas analizan solo el sistema operativo fundamental, otras también revisan las bibliotecas, algunas trabajan sobre el lenguaje y hay otras que lo hacen sobre el contenido de los archivos. Es importante elegir una que cubra todas las necesidades de la empresa y que sea compatible con los lenguajes de programación que utilizan sus aplicaciones.

Algunas herramientas realizan el análisis al momento de extraer la imagen, pero este enfoque puede aumentar la latencia, así que las empresas decidirán si vale la pena sacrificar el rendimiento para obtener información inmediata.

Análisis durante el tiempo de ejecución

Tal como sucede con el análisis de imágenes en la etapa de diseño, no todos los puntos vulnerables ameritan la misma respuesta. Como ninguna empresa utiliza los mismos procedimientos ni tiene objetivos similares en relación con los servicios que sirvan como guía para responder a los puntos vulnerables, deben establecer un orden de prioridad para abordarlos en función de la importancia de sus cargas de trabajo, la confidencialidad de sus datos, la exposición a Internet y la gravedad de los problemas detectados. Por ejemplo, el hecho de bloquear todos los contenedores en los que se encontraron puntos vulnerables, sin tener en cuenta su gravedad o importancia, tiene sus ventajas y desventajas. Para que el análisis de las implementaciones en ejecución sea exitoso, se necesitan las herramientas adecuadas que permitan controlar los puntos vulnerables y obtener información sobre ellos, y también políticas de seguridad bien pensadas que equilibren la gestión de los puntos vulnerables y el impacto a nivel operativo.

No solo ha evolucionado la complejidad de las redes empresariales y de sus aplicaciones distribuidas, sino también los modelos de amenaza y los métodos que se utilizan para aumentar las infiltraciones. Los perímetros seguros pasaron de ser una estrategia de seguridad integral para la infraestructura y los datos a servir únicamente como un sistema básico de protección para las redes internas. Un sistema sólido de seguridad combina distintos controles y estrategias.

Las redes de confianza cero son una parte fundamental del sistema de seguridad, ya que se centran en aumentar la protección del tráfico de las aplicaciones internas. Este modelo derriba la idea tan arraigada de que todo el tráfico que se encuentra dentro de la red protegida con un firewall es genuino, y supone lo opuesto: ninguna conexión de red es segura hasta que se demuestre lo contrario.

Antiguamente, los administradores de redes asumían que cualquier entidad (ya sea una aplicación, un servidor o una parte del software o hardware de la red) que se encontrara en sus redes internas pertenecía a ellas y era confiable. Algunas aplicaciones no requerían la autenticación de las conexiones de los clientes o se basaban en credenciales estáticas y compartidas (por ejemplo, una contraseña para la base de datos), y todas debían manejar los esquemas de autenticación o autorización en caso de necesitarlos. También era usual que las conexiones de redes internas, incluso las que pertenecían a servicios confidenciales, no estuvieran cifradas.

En la actualidad, varias redes empresariales aún siguen este patrón. Sin embargo, un solo agente malintencionado podría ingresar a este entorno poco seguro (ya sea a través de un jaqueo informático directo, un troyano introducido accidentalmente por alguien con autorización o un punto vulnerable en el firewall de la red), aprovecharse al máximo de esta red tradicional de confianza implícita y producir grandes daños. Quizás las posibilidades no sean infinitas, pero son previsibles. Hay muchas actividades que pueden dar lugar a riesgos inaceptables, como la pérdida o la exportación no autorizada de datos: el rastreo de paquetes de red con texto sin formato, la averiguación de las contraseñas de aplicaciones que permiten acceder a las bases de datos u otros sistemas importantes, o el control de los equipos de red.

La confianza cero es la base de una cantidad cada vez mayor de infraestructuras de producción, en las cuales la seguridad es un aspecto primordial. En lugar de confiar en cualquier entidad de una red sin haberla verificado, asume que nada es seguro, ni siquiera la propia infraestructura de red. Este enfoque no ofrece una implementación prescriptiva ni un grupo específico de herramientas, sino que describe un conjunto de principios y objetivos, y delega los detalles técnicos particulares de la implementación a cada empresa.

Arquitecturas de confianza cero

Por lo general, las arquitecturas de confianza cero se rigen por los siguientes principios:

• Los controles de seguridad se deben aplicar por igual a todas las entidades (ya sean sistemas de hardware o de software), sin importar la ubicación de la red.
• Las conexiones de red se deben autenticar en ambos extremos: el servidor y el cliente. En la actualidad, se espera que el servidor realice la autenticación de los clientes, pero ellos también tienen que verificar si se conectaron a un servidor válido. Si las conexiones abarcan más de una operación, se deben autenticar de nuevo, y las solicitudes deben volver a autorizarse, según sea necesario.
• Las autorizaciones deben seguir el principio de privilegio mínimo y otorgar solo los permisos indispensables para la carga de trabajo de un cliente.
• Todas las conexiones y las operaciones de red se deben analizar permanentemente.

Implementación del modelo de confianza cero en Kubernetes

¿Qué pasa si implementamos el modelo de confianza cero en un clúster de Kubernetes? Si bien no existe una única metodología para implementar los principios de confianza cero en un clúster de Kubernetes, las mallas de servicios se han convertido en una solución popular que se utiliza para muchos de los objetivos de la arquitectura.

Estas crean una capa de red virtualizada que conecta y controla los servicios de las aplicaciones distribuidas. Al principio, la mayoría de estas soluciones no se centraban en proteger la red, sino en facilitar y gestionar el descubrimiento de servicios inteligentes y el enrutamiento de las solicitudes. Sin embargo, hoy en día los proyectos open source más conocidos ofrecen funciones que se ajustan a las arquitecturas de confianza cero. Como muchas de estas mallas intentan crear una superposición de las redes que no requiera la modificación de las aplicaciones individuales, eliminan gran parte de la presión que implica tener que hacer cambios importantes para habilitar los controles estrictos de autenticación y autorización.

Las mallas de servicios compatibles con Kubernetes suelen utilizar el enrutamiento de punto a punto que no está concentrado, es decir, que le otorgan a cada pod del clúster su propia instancia de proxy. Estos servidores pueden gestionar los certificados TLS del cliente y utilizarlos para comprobar su identidad a la hora de conectarse a otros servicios o de recibir conexiones de otros clientes. El uso de los certificados TLS para comprobar la identidad tanto del cliente como del servidor se denomina "seguridad mutua de la capa de transporte" (mTLS), la cual también se utiliza para cifrar la conexión de red. Además de estas funciones, las diferentes mallas de servicios son compatibles con distintas fuentes de autorización, que abarcan desde las listas estáticas hasta las integraciones con Single Sign-On de terceros u otros servicios.

Si bien no proporcionan una solución de confianza cero completa para los clústeres de Kubernetes, ofrecen varias de sus ventajas principales. Aunque no logre una arquitectura totalmente basada en este modelo en los clústeres de su plataforma, cualquier cambio gradual que realice en este sentido servirá para protegerlos, como así también sus cargas de trabajo.

Es necesario introducir cambios significativos en la forma en que una empresa aborda la seguridad para proteger las aplicaciones desarrolladas en la nube y la infraestructura fundamental: las empresas deben aplicar los controles en una fase más temprana del proceso de desarrollo de las aplicaciones, utilizar controles integrados para aplicar políticas que eviten problemas operativos y de escalabilidad, y seguir el ritmo cada vez más rápido de las planificaciones de lanzamiento.

Red Hat® Advanced Cluster Security for Kubernetes es una plataforma de seguridad desarrollada en Kubernetes con la cual las empresas pueden diseñar aplicaciones en la nube, implementarlas y ejecutarlas de una forma más segura en todas partes, y también agilizar la innovación con confianza. Permite mejorar la seguridad del proceso de diseño de las aplicaciones, proteger la plataforma y las configuraciones, y detectar los problemas con los tiempos de ejecución y solucionarlos.