Alexandre Vazquez

Aumentar los registros HTTP en TIBCO BusinessWorks en 5 minutos

por
Aumentar los registros HTTP en TIBCO BusinessWorks en 5 minutos

Aumentar los registros HTTP en TIBCO BusinessWorks cuando estás depurando o solucionando problemas en una integración basada en HTTP que podría estar relacionada con un servicio REST o SOAP es una de las cosas más utilizadas y útiles que puedes hacer al desarrollar con TIBCO BusinessWorks.

El propósito principal de aumentar los registros HTTP es obtener un conocimiento completo sobre qué información estás enviando y qué comunicación estás recibiendo de tu comunicador asociado para ayudar a entender un error o comportamiento inesperado.

¿Cuáles son los casos de uso principales para aumentar los registros HTTP?

Al final, todos los diferentes casos de uso son variaciones del caso de uso principal: “Obtener conocimiento completo sobre la comunicación de intercambio HTTP entre ambas partes.” Aún así, algunos más detallados se pueden listar a continuación:

  • Entender por qué un servidor backend está rechazando una llamada que podría estar relacionada con Autenticación o Autorización, y necesitas ver la respuesta detallada del servidor backend.
  • Verificar el valor de cada Encabezado HTTP que estás enviando y que podría afectar la compresión de la comunicación o el tipo de contenido aceptado.
  • Ver por qué estás rechazando una llamada de un consumidor

Dividiendo la comunicación según la fuente

Lo más importante a entender es que los registros usualmente dependen de la biblioteca que estás usando, y no es la misma biblioteca utilizada para exponer un servidor basado en HTTP que la biblioteca que usas para consumir un servicio basado en HTTP como REST o un servicio SOAP.

Comenzando por lo que expones, esto es lo más fácil porque esto será definido por los recursos del Conector HTTP que estás usando, como puedes ver en la imagen a continuación:

Conector de Recursos Compartidos HTTP en BW

Todos los Recursos del Conector HTTP que puedes usar para exponer servicios REST y SOAP están basados en la implementación del Servicio Jetty, y eso significa que los registradores que necesitas cambiar su configuración están relacionados con el servidor Jetty en sí.

Más complejos, en teoría, son los relacionados con la comunicación del cliente cuando nuestra aplicación TIBCO BusinessWorks consume un servicio basado en HTTP proporcionado por un backend porque cada una de estas comunicaciones tiene sus propios Recursos Compartidos del Cliente HTTP. La configuración de cada uno de ellos será diferente porque una de las configuraciones que podemos obtener aquí es la Biblioteca de Implementación, y eso tendrá un efecto directo en la forma de cambiar la configuración del registro:

Recurso del Cliente HTTP en BW que muestra las diferentes bibliotecas de implementación para detectar el registrador para Aumentar los Registros HTTP en TIBCO BusinessWorks

Tienes tres opciones cuando defines un Recurso del Cliente HTTP, como puedes ver en la imagen anterior:

  • Apache HttpComponents: El predeterminado que soporta servicios HTTP1, SOAP y REST.
  • Cliente HTTP Jetty: Este cliente solo soporta flujos HTTP como HTTP1 y HTTP2, y sería la opción principal cuando estás trabajando con flujos HTTP2.
  • Apache Commons: Similar al primero, pero actualmente está obsoleto, y para ser honesto, si tienes algún componente cliente usando esta configuración, deberías cambiarlo cuando puedas a Apache HttpComponents.

Entonces, si estamos consumiendo un servicio SOAP y REST, está claro que estaremos usando la biblioteca de implementación Apache HttpComponents, y eso nos dará el registrador que necesitamos usar.

Porque para Apache HttpComponents, podemos confiar en el siguiente registrador: “org.apache.http” y en caso de que queramos extender el lado del servidor, o estemos usando el cliente HTTP Jetty, podemos usar este: “org.eclipse.jetty.http”

Debemos ser conscientes de que no podemos extenderlo solo para un único recurso de Cliente HTTP porque la configuración se basará en la Biblioteca de Implementación, así que en caso de que establezcamos el nivel DEBUG para la biblioteca Apache HttpComponents, afectará a todos los Recursos Compartidos que usen esta Biblioteca de Implementación, y necesitarás diferenciar basado en los datos dentro del registro, por lo que eso será parte de tu análisis de datos.

¿Cómo configurar los Registros HTTP en TIBCO BusinessWorks?

Ahora que tenemos los registradores, debemos configurarlo a un nivel DEBUG (o TRACE). Necesitamos saber cómo hacerlo, y tenemos varias opciones dependiendo de cómo nos gustaría hacerlo y qué acceso tenemos. El alcance de este artículo es TIBCO BusinessWorks Container Edition, pero puedes extrapolar fácilmente parte de este conocimiento a una instalación de TIBCO BusinessWorks en las instalaciones.

TIBCO BusinessWorks (contenedor o no) se basa en sus capacidades de registro en la biblioteca log back, y esta biblioteca se configura usando un archivo llamado logback.xml que podría tener la configuración que necesitas, como puedes ver en la imagen a continuación:

configuración de logback.xml con la estructura predeterminada en TIBCO BW

Entonces, si queremos agregar una nueva configuración de registro, necesitamos agregar un nuevo elemento logger al archivo con la siguiente estructura:

  <logger name="%LOGGER_QUE_QUEREMOS_VER">
    <level value="%NIVEL_QUE_QUEREMOS_VER%"/>
  </logger>

Entonces, el registrador fue preciso basado en la sección anterior, y el nivel dependerá de cuánta información quieras ver. Los niveles de registro son los siguientes: ERROR, WARN, INFO, DEBUG, TRACE. DEBUG y TRACE son los que muestran más información.

En nuestro caso, DEBUG debería ser suficiente para obtener la Solicitud HTTP completa y la Respuesta HTTP, pero también puedes aplicarlo a otras cosas donde podrías necesitar un nivel de registro diferente.

Ahora necesitas agregar eso al archivo logback.xml, y para hacerlo, tienes varias opciones, como se comentó:

  • Puedes encontrar el logback.xml dentro del contenedor BWCE (o la carpeta de configuración de AppNode) y modificar su contenido. La ubicación predeterminada de este archivo es esta: /tmp/tibco.home/bwce/<VERSION>/config/logback.xml Para hacer esto, necesitarás tener acceso para hacer un kubectl exec en el contenedor bwce, y si haces el cambio, el cambio será temporal y se perderá en el próximo reinicio. Eso podría ser algo bueno o malo, dependiendo de tu objetivo.
  • Si quieres que sea permanente o no tienes acceso al contenedor, tienes dos opciones. La primera es incluir una copia personalizada del logback.xml en la carpeta /resources/custom-logback/ en la imagen base de BWCE y establecer la variable de entorno CUSTOM_LOGBACK a valor TRUE, y eso sobrescribirá la configuración predeterminada de logback.xml con el contenido de este archivo. Como se comentó, esto será “permanente” y se aplicará desde el primer despliegue de la aplicación con esta configuración. Puedes encontrar más información en la documentación oficial aquí.
  • También hay una adicional desde BWCE 2.7.0 y superior que te permite cambiar el contenido de logback.xml sin una nueva copia o cambiar la imagen base, y eso se basa en el uso de la propiedad de entorno BW_LOGGER_OVERRIDES con el contenido de la siguiente manera (logger=value) así que en nuestro caso sería algo como esto org.apache.http=DEBUG y en el próximo despliegue obtendrás esta configuración. Similar a la anterior, esto será permanente pero no requiere agregar un archivo a la imagen base para ser alcanzable.

Entonces, como puedes ver, tienes diferentes opciones dependiendo de tus necesidades y niveles de acceso.

Conclusión

En conclusión, mejorar los registros HTTP dentro de TIBCO BusinessWorks durante la depuración y solución de problemas es una estrategia vital. Elevar los niveles de registro proporciona una comprensión completa del intercambio de información, ayudando en el análisis de errores y comportamientos inesperados. Ya sea discerniendo las causas de rechazo del backend, examinando los efectos de los encabezados HTTP, o aislando rechazos de llamadas de consumidores, los registros amplificados iluminan escenarios de integración complejos. Las adaptaciones varían según el uso de la biblioteca, abarcando la exposición del servidor y el consumo de servicios. La configuración a través de la biblioteca logback implica ajustes personalizados de registrador y nivel. Esta práctica empodera a los desarrolladores para desentrañar las complejidades de la integración de manera eficiente, asegurando interacciones robustas y fluidas basadas en HTTP a través de sistemas.

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Cómo crear una imagen de sistema de archivos de solo lectura para TIBCO BWCE

por
Cómo crear una imagen de sistema de archivos de solo lectura para TIBCO BWCE

Este artículo cubrirá cómo mejorar la seguridad de tus imágenes de TIBCO BWCE creando una Imagen de Sistema de Archivos de Solo Lectura para TIBCO BWCE. En artículos anteriores, hemos comentado los beneficios que este tipo de imagen proporciona varias ventajas en términos de seguridad, centrándonos en aspectos como la reducción de la superficie de ataque al limitar el tipo de cosas que cualquier usuario puede hacer, incluso si logran acceder a contenedores en ejecución.

Lo mismo se aplica en caso de que cualquier malware que pueda tener tu imagen haya limitado las posibles acciones que pueden hacer sin ningún acceso de escritura a la mayor parte del contenedor.

¿Cómo afecta ReadOnlyFileSystem a una imagen de TIBCO BWCE?

Esto tiene un impacto claro ya que la imagen de TIBCO BWCE es una imagen que necesita escribir en varias carpetas como parte del comportamiento esperado de la aplicación. Eso es obligatorio y no depende de los scripts que usaste para construir tu imagen.

Como probablemente sepas, TIBCO BWCE incluye dos conjuntos de scripts para construir la imagen base de Docker: los principales y los incluidos en la carpeta reducedStartupTime, como puedes ver en la página de GitHub pero también dentro de tu carpeta docker en el TIBCO-HOME después de la instalación, como puedes ver en la imagen a continuación.

Cómo crear una imagen de sistema de archivos de solo lectura para TIBCO BWCE

La principal diferencia entre ellos es dónde se realiza la descompresión del bwce-runtime. En el caso del script por defecto, la descompresión se realiza en el proceso de inicio de la imagen, y en el reducedStartupTime esto se hace en la construcción de la imagen misma. Así que, puedes empezar a pensar que los predeterminados necesitan algún acceso de escritura ya que necesitan descomprimir el archivo dentro del contenedor, y eso es cierto.

Pero también, el reducedStartupTime requiere acceso de escritura para ejecutar la aplicación; se realizan varias actividades relacionadas con la descompresión del archivo EAR, la gestión del archivo de propiedades y actividades internas adicionales. Así que, no importa qué tipo de scripts estés usando, debes proporcionar una carpeta con acceso de escritura para realizar esta actividad.

Por defecto, todas estas actividades están limitadas a una sola carpeta. Si mantienes todo por defecto, esta es la carpeta /tmp, por lo que debes proporcionar un volumen para esa carpeta.

¿Cómo desplegar una aplicación TIBCO BWCE con el

Ahora, está claro que necesitas un volumen para la carpeta /tmp, y ahora necesitas definir el tipo de volumen que deseas usar para este. Como sabes, hay varios tipos de volúmenes que puedes determinar dependiendo de los requisitos que tengas.

En este caso, el único requisito es el acceso de escritura, pero no hay necesidad en cuanto a almacenamiento y persistencia, por lo que, en ese caso, podemos usar un modo emptyDir. El contenido de emptyDir, que se borra cuando se elimina un pod, es similar al comportamiento predeterminado pero permite permiso de escritura en su contenido.

Para mostrar cómo sería el YAML, usaremos el predeterminado que tenemos disponible en la documentación aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
    envFrom:
    - configMapRef:
      name: name

Así que, cambiaremos eso para incluir el volumen, como puedes ver aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
	securityContext:
		readOnlyRootFilesystem: true
    envFrom:
    - configMapRef:
      name: name
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

Los cambios son los siguientes:

  • Incluir la sección volumes con una única definición de volumen con el nombre de tmp con una definición de emptyDir.
  • Incluir una sección volumeMounts para el volumen tmp que se monta en la ruta /tmp para permitir escribir en esa ruta específica para habilitar también la descompresión del bwce-runtime así como todas las actividades adicionales que se requieren.
  • Para activar este comportamiento, incluye la bandera readOnlyRootFilesystem en la sección securityContext.

Conclusión

Incorporar un enfoque de ReadOnlyFileSystem en tus imágenes de TIBCO BWCE es una estrategia proactiva para fortalecer la postura de seguridad de tu aplicación. Al reducir el acceso de escritura innecesario y minimizar las posibles vías para acciones no autorizadas, estás dando un paso vital hacia la protección de tu entorno de contenedores.

Esta guía ha revelado los aspectos críticos de implementar tal medida de mejora de seguridad, guiándote a través del proceso con instrucciones claras y ejemplos prácticos. Con un enfoque en reducir vectores de ataque y reforzar el aislamiento, puedes desplegar con confianza tus aplicaciones TIBCO BWCE, sabiendo que has fortalecido su entorno de ejecución contra posibles amenazas.

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Mejorando la Seguridad de Contenedores: El Papel Vital de ReadOnlyRootFilesystem

por
Mejorando la Seguridad de Contenedores: El Papel Vital de ReadOnlyRootFilesystem

Introducción

Una característica de seguridad tan importante es el uso de ReadOnlyRootFilesystem, una herramienta poderosa que puede mejorar significativamente la postura de seguridad de tus contenedores.

En el panorama de desarrollo y despliegue de software en rápida evolución, los contenedores han surgido como una tecnología revolucionaria. Ofreciendo portabilidad, eficiencia y escalabilidad, los contenedores se han convertido en la solución preferida para empaquetar y entregar aplicaciones. Sin embargo, con estos beneficios vienen desafíos de seguridad específicos que deben abordarse para garantizar la integridad de tus aplicaciones en contenedores.

Un ReadOnlyRootFilesystem es precisamente lo que parece: un sistema de archivos que solo se puede leer, no escribir. En la contenedorización, el contenido del sistema de archivos de un contenedor está bloqueado en un estado de solo lectura, evitando cualquier modificación o alteración durante el tiempo de ejecución.

 Ventajas de Usar ReadOnlyRootFilesystem

  • Superficie de Ataque Reducida: Uno de los principios fundamentales de la ciberseguridad es reducir la superficie de ataque: los puntos de entrada potenciales para actores maliciosos. Aplicar un ReadOnlyRootFilesystem elimina la posibilidad de que un atacante obtenga acceso de escritura a tu contenedor. Esta medida simple pero efectiva limita significativamente su capacidad para inyectar código malicioso, manipular archivos críticos o instalar malware.
  • Infraestructura Inmutable: La infraestructura inmutable es un concepto donde los componentes nunca se cambian una vez desplegados. Este enfoque asegura consistencia y repetibilidad, ya que cualquier cambio se realiza desplegando una nueva instancia en lugar de modificar una existente. Al aplicar un ReadOnlyRootFilesystem, estás esencialmente adoptando los principios de infraestructura inmutable dentro de tus contenedores, haciéndolos más resistentes a modificaciones no autorizadas.
  • Mitigación de Malware: El malware a menudo depende de obtener acceso de escritura a un sistema para llevar a cabo sus actividades maliciosas. Al emplear un ReadOnlyRootFilesystem, eriges una barrera significativa contra el malware que intenta establecer persistencia o exfiltrar datos sensibles. Incluso si un atacante logra comprometer un contenedor, su capacidad para instalar y ejecutar código malicioso está severamente restringida.
  • Mejor Forense y Auditoría: En el desafortunado caso de una violación de seguridad, tener un ReadOnlyRootFilesystem en su lugar puede ayudar en el análisis forense. Dado que el sistema de archivos permanece inalterado, los investigadores pueden rastrear más precisamente el vector de ataque, determinar el alcance de la violación e identificar los puntos de entrada vulnerables.

Consideraciones de Implementación

Implementar un ReadOnlyRootFilesystem en tus aplicaciones en contenedores requiere un enfoque deliberado:

  • Diseño de Imagen: Construye tus imágenes de contenedor con el concepto de ReadOnlyRootFilesystem en mente. Asegúrate de separar las áreas de solo lectura y escritura del sistema de archivos. Esto podría implicar crear volúmenes para datos escribibles o usar variables de entorno para personalizar el comportamiento en tiempo de ejecución.
  • Configuración en Tiempo de Ejecución: Los contenedores a menudo requieren acceso de escritura para archivos temporales, registros u otras necesidades de tiempo de ejecución. Diseña cuidadosamente tu aplicación para usar directorios o volúmenes designados para estos propósitos mientras mantienes los componentes críticos de solo lectura.
  • Pruebas y Validación: Prueba exhaustivamente tu aplicación en contenedores con la configuración de ReadOnlyRootFilesystem para asegurar que funcione como se espera. Presta atención a cualquier error en tiempo de ejecución, problemas de permisos o comportamientos inesperados que puedan surgir.

¿Cómo Definir un Pod como ReadOnlyRootFilesystem?

Para definir un Pod como “ReadOnlyRootFilesystem”, esta es una de las banderas que pertenecen a la sección securityContext del pod, como puedes ver en el ejemplo a continuación:

apiVersion: v1
kind: Pod
metadata:
  name: <nombre del Pod>
spec:
  containers:
  - name: <nombre del contenedor>
    image: <imagen>
    securityContext:
      readOnlyRootFilesystem: true

Conclusión

A medida que la adopción de contenedores continúa aumentando, también lo hace la importancia de medidas de seguridad robustas. Incorporar un ReadOnlyRootFilesystem en tu estrategia de contenedores es un paso proactivo hacia la protección de tus aplicaciones y datos. Al reducir la superficie de ataque, fortalecer contra el malware y permitir un mejor análisis forense, estás mejorando la postura de seguridad general de tu entorno en contenedores.

A medida que adoptas infraestructura inmutable dentro de tus contenedores, estarás mejor preparado para enfrentar el panorama en constante evolución de las amenazas de ciberseguridad. Recuerda, cuando se trata de seguridad en contenedores, un ReadOnlyRootFilesystem puede ser el escudo que protege tus activos digitales de posibles daños.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Contenedores Efímeros en Kubernetes: Una Guía de Depuración Esencial

por
Contenedores Efímeros en Kubernetes: Una Guía de Depuración Esencial

En el mundo dinámico y en constante evolución de la orquestación de contenedores, Kubernetes sigue reinando como la elección definitiva para gestionar, desplegar y escalar aplicaciones en contenedores. A medida que Kubernetes evoluciona, también lo hacen sus características y capacidades, y una de esas fascinantes adiciones es el concepto de Contenedores Efímeros. En esta publicación de blog, profundizaremos en el mundo de los Contenedores Efímeros, entendiendo qué son, explorando sus casos de uso principales y aprendiendo cómo implementarlos, todo con la guía de la documentación oficial de Kubernetes.

 ¿Qué Son los Contenedores Efímeros?

Los Contenedores Efímeros, introducidos como una característica alfa en Kubernetes 1.16 y que alcanzaron un nivel estable en la versión 1.25 de Kubernetes, ofrecen un conjunto de herramientas poderoso para depurar, diagnosticar y solucionar problemas dentro de tus pods de Kubernetes sin requerir que alteres la configuración original de tu pod. A diferencia de los contenedores regulares que son parte de la definición central del pod, los contenedores efímeros se agregan dinámicamente a un pod en ejecución por una duración breve, proporcionándote un entorno temporal para ejecutar tareas de diagnóstico.

Lo bueno de los contenedores efímeros es que te permiten tener todas las herramientas necesarias para hacer el trabajo (depuración, recuperación de datos o cualquier otra cosa que pueda ser requerida) sin agregar más dispositivos a los contenedores base y aumentar el riesgo de seguridad basado en esa acción.

 Principales Casos de Uso de los Contenedores Efímeros

  • Solución de Problemas y Depuración: Los Contenedores Efímeros brillan más cuando se trata de solucionar problemas y depurar. Te permiten inyectar un nuevo contenedor en un pod problemático para recopilar registros, examinar archivos, ejecutar comandos o incluso instalar herramientas de diagnóstico sobre la marcha. Esto es particularmente valioso cuando se encuentran problemas que son difíciles de reproducir o diagnosticar en un entorno estático.
  • Recopilación y Análisis de Registros: Cuando un pod encuentra problemas, inspeccionar sus registros suele ser esencial. Los Contenedores Efímeros hacen que este proceso sea fluido al permitirte iniciar un contenedor temporal con herramientas de análisis de registros, dándote acceso instantáneo a los archivos de registro y ayudando a identificar la causa raíz de los problemas.
  • Recuperación y Reparación de Datos: Los Contenedores Efímeros también pueden usarse para escenarios de recuperación y reparación de datos. Imagina una situación donde un pod de base de datos enfrenta corrupción. Con un contenedor efímero, puedes montar el volumen de almacenamiento del pod, realizar operaciones de recuperación de datos y potencialmente reparar los datos sin comprometer el pod en ejecución.
  • Monitoreo y Análisis de Recursos: Los cuellos de botella de rendimiento o las restricciones de recursos a veces pueden afectar la funcionalidad de un pod. Los Contenedores Efímeros te permiten analizar la utilización de recursos, ejecutar diagnósticos y perfilar el entorno del pod, ayudándote a optimizar su rendimiento.

Implementación de Contenedores Efímeros

Gracias al enfoque amigable de Kubernetes, implementar contenedores efímeros es sencillo. Kubernetes proporciona el comando kubectl debug, que simplifica el proceso de adjuntar contenedores efímeros a los pods. Este comando te permite especificar el pod y el espacio de nombres e incluso elegir la imagen del contenedor de depuración a inyectar.

kubectl debug <nombre-del-pod> -n <espacio-de-nombres> --image=<imagen-del-contenedor-de-depuración>

Puedes ir incluso más allá, y en lugar de agregar los contenedores efímeros al pod en ejecución, puedes hacer lo mismo con una copia del pod, como puedes ver en el siguiente comando:

kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug

Finalmente, una vez que hayas cumplido con tu deber, puedes eliminarlo permanentemente usando un comando kubectl delete, y eso es todo.

Es esencial notar que todas estas acciones requieren acceso directo al entorno. Incluso eso genera temporalmente una discrepancia en el despliegue de «infraestructura como código», ya que estamos manipulando el estado de ejecución temporalmente. Por lo tanto, este enfoque es mucho más desafiante de implementar si utilizas algunas prácticas de GitOps o herramientas como Rancher Fleet o ArgoCD.

Conclusión

Los Contenedores Efímeros, aunque actualmente son una característica estable desde el lanzamiento de Kubernetes 1.25, ofrecen capacidades impresionantes para depurar y diagnosticar problemas dentro de tus pods de Kubernetes. Al permitirte inyectar contenedores temporales en pods en ejecución de manera dinámica, te capacitan para solucionar problemas, recopilar registros, recuperar datos y optimizar el rendimiento sin interrumpir la funcionalidad central de tu aplicación. A medida que Kubernetes continúa evolucionando, agregar características como los Contenedores Efímeros demuestra su compromiso de proporcionar a los desarrolladores herramientas para simplificar la gestión y el mantenimiento de aplicaciones en contenedores. Así que, la próxima vez que encuentres un problema persistente dentro de tu entorno de Kubernetes, recuerda que los Contenedores Efímeros podrían ser el superhéroe de depuración que necesitas.

Para obtener información más detallada y ejemplos de uso, consulta la documentación oficial de Kubernetes sobre Contenedores Efímeros. ¡Feliz depuración!

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Prevención de Divulgación de Información con Istio Service Mesh

por
Prevención de Divulgación de Información con Istio Service Mesh

En el panorama digital actual, donde las violaciones de datos y las amenazas cibernéticas se están volviendo cada vez más sofisticadas, garantizar la seguridad de sus servidores es primordial. Una de las preocupaciones críticas de seguridad que las organizaciones deben abordar es la «Divulgación de Información del Servidor». La Divulgación de Información del Servidor ocurre cuando información sensible sobre la configuración de un servidor, su pila tecnológica o estructura interna se expone inadvertidamente a partes no autorizadas. Los hackers pueden explotar esta vulnerabilidad para obtener información sobre posibles puntos débiles y lanzar ataques dirigidos. Tales violaciones pueden llevar al robo de datos, interrupción del servicio y daño a la reputación.

Divulgación de Información y Malla de Servicios Istio

Un ejemplo es el Encabezado HTTP del Servidor, que generalmente se incluye en la mayoría de las respuestas HTTP donde se encuentra el servidor que está proporcionando esta respuesta. Los valores pueden variar dependiendo de la pila, pero asuntos como Jetty, Tomcat o similares suelen verse. Pero también, si está utilizando una Malla de Servicios como Istio, verá el encabezado con un valor de istio-envoy, como puede ver aquí:

Divulgación de Información de Implementación del Servidor usando Malla de Servicios Istio

Como se comentó, esto es de tal importancia para varios niveles de seguridad, tales como:

  • Privacidad de Datos: La fuga de información del servidor puede exponer datos confidenciales, socavando la confianza del usuario y violando regulaciones de privacidad de datos como GDPR y HIPAA.
  • Reducción de la Superficie de Ataque: Al ocultar los detalles del servidor, minimiza la superficie de ataque disponible para posibles atacantes.
  • Seguridad por Oscuridad: Aunque no es un enfoque infalible, limitar la divulgación agrega una capa extra de seguridad, dificultando que los hackers recopilen información.

¿Cómo mitigar eso con la Malla de Servicios Istio?

Al usar Istio, podemos definir diferentes reglas para agregar y eliminar encabezados HTTP según nuestras necesidades, como puede ver en la siguiente documentación aquí: https://discuss.istio.io/t/remove-header-operation/1692 usando cláusulas simples para la definición de su VirtualService como puede ver aquí:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: k8snode-virtual-service
spec:
  hosts:
  - "example.com"
  gateways:
  - k8snode-gateway
  http:
    headers:
      response:
        remove:
          - "x-my-fault-source"
  - route:
    - destination:
        host: k8snode-service
        subset: version-1

Desafortunadamente, esto no es útil para todos los encabezados HTTP, especialmente los «principales», por lo que los que no son personalizados agregados por sus cargas de trabajo, sino los que son principalmente utilizados y definidos en el estándar HTTP W3C https://www.w3.org/Protocols/

Entonces, en el caso del encabezado HTTP del Servidor es un poco más complejo de hacer, y necesita usar un EnvoyFilter, uno de los objetos más sofisticados que forma parte de la Malla de Servicios Istio. Basado en las palabras de la documentación oficial de Istio, un EnvoyFilter proporciona un mecanismo para personalizar la configuración de Envoy generada por Istio Pilot. Por lo tanto, puede usar EnvoyFilter para modificar valores para ciertos campos, agregar filtros específicos o incluso agregar nuevos oyentes, clústeres, etc.

Implementación de EnvoyFilter para Eliminar Encabezado

Así que ahora que sabemos que necesitamos crear un EnvoyFilter personalizado, veamos cuál necesitamos usar para eliminar el encabezado del Servidor y cómo se hace esto para obtener más conocimiento sobre este componente. Aquí puede ver el EnvoyFilter para ese trabajo:

---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: gateway-response-remove-headers
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
          server_header_transformation: PASS_THROUGH
  - applyTo: ROUTE_CONFIGURATION
    match:
      context: GATEWAY
    patch:
      operation: MERGE
      value:
        response_headers_to_remove:
        - "server"

Así que centrémonos en las partes de la especificación del EnvoyFilter donde podemos obtener por un lado el usual workloadSelector, para saber dónde se aplicará este componente, que en este caso será el istio ingressgateway. Luego entramos en la sección configPatches, que son las secciones donde usamos la personalización que necesitamos hacer, y en nuestro caso, tenemos dos de ellas:

Ambas actúan en el contexto: GATEWAY y se aplican a dos objetos diferentes: NETWORK_FILTER Y ROUTE_CONFIGURATION. También puede usar filtros en sidecars para afectar su comportamiento. La primera parte lo que hace es incluir el filtro personalizado http_connection_manager que permite la manipulación del contexto HTTP, incluyendo para nuestro propósito principal también el encabezado HTTP, y luego tenemos la segunda parte que actúa en el ROUTE_CONFIGURATION eliminando el encabezado del servidor como podemos ver usando la opción response_header_to_remove

Conclusión

Como puede ver, esto no es fácil de implementar. Sin embargo, al mismo tiempo, es evidencia del poder y las capacidades de bajo nivel que tiene al usar una malla de servicios robusta como Istio para interactuar y modificar el comportamiento de cualquier pequeño detalle que desee para su beneficio y, en este caso, también para mejorar y aumentar la seguridad de sus cargas de trabajo desplegadas detrás del alcance de la Malla de Servicios.

En el panorama en constante evolución de las amenazas de ciberseguridad, proteger sus servidores contra la divulgación de información es crucial para proteger datos sensibles y mantener la integridad de su organización. Istio le permite fortalecer la seguridad de su servidor al proporcionar herramientas robustas para la gestión del tráfico, el cifrado y el control de acceso.

Recuerde, la clave para una seguridad adecuada del servidor es un enfoque proactivo que aborde las vulnerabilidades antes de que puedan ser explotadas. Tome la iniciativa de implementar Istio y eleve la protección de su servidor.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Mejorando la Resolución DNS del Service Mesh con la Capacidad de Proxy DNS de Istio: Beneficios y Casos de Uso

por
Mejorando la Resolución DNS del Service Mesh con la Capacidad de Proxy DNS de Istio: Beneficios y Casos de Uso

Istio es un popular service mesh de código abierto que proporciona una gama de potentes características para gestionar y asegurar arquitecturas basadas en microservicios. Hemos hablado mucho sobre sus capacidades y componentes, pero hoy hablaremos sobre cómo podemos usar Istio para ayudar con el mecanismo de resolución de DNS.

Como ya sabes, en una implementación típica de Istio, cada servicio está acompañado por un proxy sidecar, Envoy, que intercepta y gestiona el tráfico entre servicios. La capacidad de Proxy DNS de Istio aprovecha este proxy para manejar las solicitudes de resolución de DNS de manera más inteligente y eficiente.

Tradicionalmente, cuando un servicio dentro de una arquitectura de microservicios necesita comunicarse con otro servicio, depende de la resolución de DNS para descubrir la dirección IP del servicio objetivo. Sin embargo, la resolución de DNS tradicional puede ser difícil de gestionar en entornos complejos y dinámicos, como los que se encuentran en los clústeres de Kubernetes. Aquí es donde entra en juego la capacidad de Proxy DNS de Istio.

 Capacidades de Proxy DNS de Istio

Con Proxy DNS, Istio intercepta y controla las solicitudes de resolución de DNS de los servicios y realiza la resolución en su nombre. En lugar de depender de servidores DNS externos, los proxies sidecar manejan la resolución de DNS dentro del service mesh. Esto permite a Istio proporcionar varios beneficios valiosos:

  • Descubrimiento de servicios y balanceo de carga: El Proxy DNS de Istio permite mecanismos de descubrimiento de servicios más avanzados. Puede descubrir dinámicamente servicios y sus direcciones IP correspondientes dentro del mesh y realizar balanceo de carga entre instancias de un servicio en particular. Esto elimina la necesidad de que los servicios individuales gestionen la resolución de DNS y el balanceo de carga.
  • Seguridad y observabilidad: Istio obtiene visibilidad en el tráfico entre servicios al manejar la resolución de DNS dentro del mesh. Puede aplicar políticas de seguridad, como control de acceso y encriptación de tráfico, a nivel de DNS. Además, Istio puede recopilar datos de telemetría relacionados con DNS para monitoreo y observabilidad, proporcionando información sobre los patrones de comunicación entre servicios.
  • Gestión y control del tráfico: Proxy DNS permite a Istio implementar características avanzadas de gestión de tráfico, como reglas de enrutamiento e inyección de fallos, a nivel de resolución de DNS. Esto permite mecanismos sofisticados de control de tráfico dentro del service mesh, habilitando pruebas A/B, implementaciones canarias, ruptura de circuitos y otras estrategias de gestión de tráfico.

 Casos de Uso de Proxy DNS de Istio

Hay algunos momentos en los que no puedes o no quieres depender de la resolución normal de DNS. ¿Por qué es eso? Comenzando porque DNS es un gran protocolo pero carece de algunas capacidades, como el descubrimiento de ubicación. Si tienes el mismo DNS asignado a tres IPs, proporcionará cada una de ellas de manera circular y no puede depender de la ubicación.

O tienes varias IPs, y quieres bloquear algunas de ellas para algún servicio específico; estas son grandes cosas que puedes hacer con Istio Proxy DNS.

Habilitación de Proxy DNS de Istio

Debes saber que las capacidades de Proxy DNS de Istio no están habilitadas por defecto, por lo que debes ayudar si deseas usarlo. Lo bueno es que puedes permitirlo en diferentes niveles, desde el nivel completo del mesh hasta solo el nivel de un pod individual, por lo que puedes elegir lo que es mejor para ti en cada caso.

Por ejemplo, si queremos habilitarlo a nivel de pod, necesitamos inyectar la siguiente configuración en el proxy de Istio:

    proxy.istio.io/config: |
		proxyMetadata:   
         # Habilitar proxy DNS básico
         ISTIO_META_DNS_CAPTURE: "true" 
         # Habilitar asignación automática de direcciones, opcional
         ISTIO_META_DNS_AUTO_ALLOCATE: "true"

La misma configuración puede ser parte del nivel del Mesh como parte de la instalación del operador, como puedes encontrar la documentación aquí en la página oficial de Istio.

Conclusión

En resumen, la capacidad de Proxy DNS de Istio mejora el mecanismo de resolución de DNS dentro del entorno del service mesh, proporcionando descubrimiento de servicios avanzado, balanceo de carga, seguridad, observabilidad y características de gestión de tráfico. Istio centraliza y controla la resolución de DNS aprovechando los proxies sidecar, simplificando la gestión y optimización de la comunicación entre servicios en arquitecturas de microservicios complejas.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

por
Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

El uso de subgráficos de múltiples instancias de Helm como parte de tu gráfico principal podría ser algo que, desde el principio, puede sonar extraño. Ya comentamos sobre los subgráficos y dependencias de los gráficos de helm en el blog porque el caso de uso habitual es así:

Tengo un gráfico que necesita otro componente, y lo «importo» como un subgráfico, lo que me da la posibilidad de desplegar el mismo componente y personalizar sus valores sin necesidad de crear otra copia del gráfico y, como puedes imaginar, simplificando mucho la gestión de los gráficos, un ejemplo puede ser así:

Descubre cómo múltiples subgráficos pueden revolucionar tus despliegues de Helm. Aprende a aprovechar el poder de la reutilización y personalización, permitiéndote desplegar componentes idénticos con configuraciones únicas. Mejora la flexibilidad y simplifica la gestión con esta avanzada característica de Helm. Desbloquea todo el potencial de tu arquitectura de microservicios y toma el control de despliegues de aplicaciones complejas. Sumérgete en el mundo de múltiples subgráficos y eleva tus gráficos de Helm al siguiente nivel.

Entonces, creo que eso está totalmente claro, pero ¿de qué estamos hablando ahora? El caso de uso es tener el mismo subgráfico definido dos veces. Así que, imagina este escenario, estamos hablando de eso en lugar de esto:

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Estamos teniendo algo como esto

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached-copy1
  version: "3.2.1"
  repository: "https://another.example.com/charts"
- name: memcached-copy2
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Así que tenemos la opción de definir más de una «instancia» del mismo subgráfico. Y supongo que, en este momento, puedes empezar a preguntarte: «¿Cuáles son los casos de uso donde podría necesitar esto?»

Porque eso es bastante comprensible, a menos que lo necesites nunca te darás cuenta de eso. Es lo mismo que me pasa a mí. Así que hablemos un poco sobre posibles casos de uso para esto.

 Casos de Uso para Dependencia de Múltiples Instancias de Helm

Imagina que estás desplegando un gráfico de helm para un conjunto de microservicios que pertenecen al ámbito de la misma aplicación y cada uno de los microservicios tiene la misma base tecnológica, que puede ser TIBCO BusinessWorks Container Edition o pueden ser microservicios Golang. Así que todos ellos tienen la misma base por lo que pueden usar el mismo gráfico «bwce-microservice» o «golang-microservices» pero cada uno de ellos tiene su propia configuración, por ejemplo:

  • Cada uno de ellos tendrá su propio nombre de imagen que diferirá de uno a otro.
  • Cada uno de ellos tendrá su propia configuración que diferirá de uno a otro.
  • Cada uno de ellos tendrá sus propios puntos de conexión que diferirán y probablemente incluso se conectarán a diferentes fuentes como bases de datos o sistemas externos.

Así que, este enfoque nos ayudaría a reutilizar el mismo gráfico de helm tecnológico, «bwce» e instanciarlo varias veces, para que podamos tener cada uno de ellos con su propia configuración sin la necesidad de crear algo «personalizado» y manteniendo los mismos beneficios en términos de mantenibilidad que el enfoque de dependencia de helm nos proporciona.

 ¿Cómo podemos implementar esto?

Ahora que tenemos claro el caso de uso que vamos a soportar, el siguiente paso es sobre cómo podemos hacer esto una realidad. Y, para ser honesto, esto es mucho más simple de lo que puedes pensar desde el principio, comencemos con la situación normal cuando tenemos un gráfico principal, llamémoslo un «programa», que ha incluido una plantilla «bwce» como una dependencia como puedes ver aquí:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  version: ~1.0.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

Y ahora, vamos a movernos a un enfoque de múltiples instancias donde requeriremos dos microservicios diferentes, llamémoslos serviceA y serviceB, y ambos usarán el mismo gráfico de helm bwce.

Así que lo primero que modificaremos es el Chart.yaml de la siguiente manera:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  alias: serviceA
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
- name: bwce
  alias: serviceB
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

La parte importante aquí es cómo declaramos la dependencia. Como puedes ver en el nombre seguimos manteniendo el mismo «nombre» pero tienen un campo adicional llamado «alias» y este alias es lo que nos ayudará a identificar más tarde las propiedades para cada una de las instancias según lo requiramos. Con eso, ya tenemos nuestra definición de instancia de serviceA y serviceB y podemos comenzar a usarlo en el values.yml de la siguiente manera:

# Este es un archivo con formato YAML.
# Declara variables para ser pasadas a tus plantillas.

serviceA:
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceA:2.5.2
    pullPolicy: Always
serviceB:  
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceB:2.5.2
    pullPolicy: Always

 Conclusión

El principal beneficio de esto es que mejora las opciones de usar gráficos de helm para aplicaciones «complejas» que requieren diferentes instancias del mismo tipo de componentes y al mismo tiempo.

Eso no significa que necesites un gráfico de helm enorme para tu proyecto porque esto iría en contra de todas las mejores prácticas del enfoque de contenedorización y microservicios, pero al menos te dará la opción de definir diferentes niveles de abstracción como desees, manteniendo todos los beneficios desde una perspectiva de gestión.

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

por
Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

La API de Kubernetes cambia bastante, y sabemos que en cada nueva versión, están agregando nuevas capacidades al mismo tiempo que están desaprobando las antiguas, por lo que es una evolución constante, como ya mencionamos en artículos anteriores, como puedes ver aquí respecto a Autoscaling v2 y Autoscaling Vertical.

Algunos de estos cambios están relacionados con el cambio en la apiVersion de algunos objetos, y probablemente ya hayas sufrido de ese v1/alpha pasando a v1/beta o simplemente moviéndose a un v1 final y desaprobando el anterior. Por lo tanto, al final, es crucial asegurarse de que tu manifiesto esté sincronizado con la versión objetivo que estás implementando, y algunas herramientas pueden ayudarnos con eso, incluyendo Kubeconform.

¿Qué es Kubeconform?

Kubeconform es una poderosa utilidad diseñada para ayudar en la gestión y validación de configuraciones de Kubernetes. A medida que Kubernetes continúa ganando popularidad como la plataforma de orquestación de contenedores preferida, asegurar la corrección y consistencia de los archivos de configuración se vuelve crucial. Kubeconform aborda esta necesidad proporcionando un conjunto de herramientas integral para validar archivos de configuración de Kubernetes contra estándares predefinidos o reglas personalizadas.

Kubeconform admite múltiples versiones de Kubernetes, lo que te permite validar archivos de configuración contra diferentes versiones de API. Esta flexibilidad es beneficiosa al trabajar con clústeres que ejecutan diferentes versiones de Kubernetes o al migrar aplicaciones entre conjuntos con configuraciones variables.

Otra gran característica de Kubeconform es su capacidad para hacer cumplir las mejores prácticas y estándares en las configuraciones de Kubernetes. Te permite definir reglas, como hacer cumplir etiquetas adecuadas, límites de recursos o políticas de seguridad, y luego valida tus archivos de configuración contra estas reglas. Esto ayuda a detectar posibles problemas desde el principio y asegura que tus implementaciones cumplan con las pautas establecidas.

¿Cómo instalar Kubeconform?

Kubeconform se puede instalar desde diferentes fuentes, las más usuales son las estándar para tu entorno usando gestores de paquetes como brew, apt o similares, o simplemente obteniendo los binarios desde su página de GitHub: https://github.com/yannh/kubeconform/releases.

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

¿Cómo lanzar Kubeconform desde la Línea de Comandos?

Kubeconform se distribuye como un pequeño binario destinado a ser ejecutado en la interfaz CLI y trata de mantener su interfaz mínima para asegurar la compatibilidad. Por lo tanto, recibe un argumento con el archivo o carpeta con los archivos de manifiesto que deseas verificar, como puedes ver aquí:

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

Luego tienes varias opciones para hacer otras cosas, como las que se muestran a continuación:

-ignore-filename-pattern valor

expresión regular que especifica rutas a ignorar (se puede especificar varias veces)

-ignore-missing-schemas

omitir archivos con esquemas faltantes en lugar de fallar

-Kubernetes-version cadena

versión de Kubernetes contra la cual validar, por ejemplo: 1.18.0 (por defecto «master»)

-output cadena

formato de salida – json, junit, pretty, tap, text (por defecto «text»)

-reject cadena

lista separada por comas de tipos o GVKs a rechazar

-skip cadena

lista separada por comas de tipos o GVKs a ignorar

-strict

no permitir propiedades adicionales no en el esquema o claves duplicadas

-summary

imprimir un resumen al final (ignorado para salida junit)

Casos de uso de Kubeconform

Existen diferentes casos de uso donde Kubeconform puede desempeñar un buen papel. Uno es respecto a las actualizaciones de Kubernetes, a veces necesitas asegurarte de que tu manifiesto actual seguirá funcionando en la nueva versión a la que se actualizará el clúster, y con esta herramienta, podemos asegurarnos de que nuestro YAML sigue siendo compatible con la última versión obteniéndolo directamente del entorno y validándolo adecuadamente.

Otro aspecto notable de Kubeconform es su integración perfecta en los pipelines de CI/CD existentes. Puedes incorporar fácilmente kubeconform como un paso en tu pipeline para validar automáticamente los archivos de configuración de Kubernetes antes de implementarlos. Al hacerlo, puedes detectar errores de configuración temprano en el proceso de desarrollo, reducir el riesgo de fallos de implementación y mantener una alta consistencia de configuración.

Además de sus capacidades de validación, kubeconform proporciona comentarios útiles y sugerencias para mejorar tus archivos de configuración de Kubernetes. Resalta problemas específicos o desviaciones de las reglas definidas y ofrece orientación sobre cómo abordarlos. Esto simplifica el proceso de resolución de problemas y ayuda a los desarrolladores y administradores a familiarizarse más con las mejores prácticas y estándares de configuración de Kubernetes.

Conclusión

Kubeconform es una utilidad invaluable para los usuarios de Kubernetes que buscan implementaciones confiables y consistentes. Empodera a los equipos para mantener un alto estándar de calidad de configuración, reduce la probabilidad de configuraciones erróneas y mejora la estabilidad y seguridad general de las aplicaciones basadas en Kubernetes.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Explorando las Políticas de Seguridad de Istio para una Protección Mejorada de la Malla de Servicios con 3 Objetos

por
Explorando las Políticas de Seguridad de Istio para una Protección Mejorada de la Malla de Servicios con 3 Objetos

Las Políticas de Seguridad de Istio son cruciales para asegurar los microservicios dentro de un entorno de malla de servicios. Hemos discutido Istio y las capacidades que puede introducir a tus cargas de trabajo de Kubernetes. Sin embargo, hoy vamos a ser más detallados respecto a los diferentes objetos y recursos que nos ayudarían a hacer nuestras cargas de trabajo mucho más seguras y a reforzar la comunicación entre ellas. Estos objetos incluyen los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy.

PeerAuthentication: Aplicando seguridad en la comunicación de pod a pod

PeerAuthentication se centra en asegurar la comunicación entre servicios aplicando autenticación y autorización mutua TLS (Transport Layer Security). Permite a los administradores definir políticas de autenticación para cargas de trabajo basadas en la fuente de las solicitudes, como namespaces específicos o cuentas de servicio. Configurar PeerAuthentication asegura que solo los servicios autenticados y autorizados puedan comunicarse, previniendo el acceso no autorizado y los ataques de intermediarios. Esto se puede lograr dependiendo del valor del modo donde se define este objeto siendo STRICT para solo permitir comunicación mTLS, PERMISSIVE para permitir ambos tipos de comunicación, DISABLE para prohibir la conexión mTLS y mantener el tráfico inseguro, y UNSET para usar la opción heredada. Este es un ejemplo de la definición del objeto:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: PERMISSIVE

RequestAuthentication: Definiendo métodos de autenticación para cargas de trabajo de Istio

RequestAuthentication, por otro lado, proporciona un control detallado sobre la autenticación de solicitudes entrantes. Permite a los administradores especificar reglas y requisitos para validar y autenticar solicitudes entrantes basadas en factores como la validación de JWT (JSON Web Tokens), claves API o métodos de autenticación personalizados. Con RequestAuthentication, los propietarios de servicios pueden aplicar mecanismos de autenticación específicos para diferentes puntos finales o rutas, asegurando que solo los clientes autenticados puedan acceder a recursos protegidos. Aquí puedes ver un ejemplo de un objeto RequestAuthentication:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  jwtRules:
    - issuer: "issuer.example.com"
      jwksUri: "https://example.com/.well-known/jwks.json"

Como se comentó, la validación de JWT es el enfoque más utilizado ya que los tokens JWT se están convirtiendo en el estándar de la industria para validaciones entrantes y el protocolo de autorización OAuth V2. Aquí puedes definir las reglas que el JWT necesita cumplir para ser considerado una solicitud válida. Pero el RequestAuthentication solo describe los “métodos de autenticación” soportados por las cargas de trabajo pero no lo aplica ni proporciona detalles sobre la Autorización.

Eso significa que si defines que una carga de trabajo necesita usar autenticación JWT, enviar la solicitud con el token validará ese token y asegurará que no esté expirado. Cumple con todas las reglas que has especificado en la definición del objeto, pero también permitirá pasar solicitudes sin token alguno, ya que solo estás definiendo lo que las cargas de trabajo soportan pero no lo aplicas. Para hacer eso, necesitamos introducir el último objeto de este conjunto, el objeto AuthorizationPolicy.

AuthorizationPolicy: Definición de Políticas de Autorización Detalladas para Políticas de Istio

AuthorizationPolicy ofrece potentes capacidades de control de acceso para regular el flujo de tráfico dentro de la malla de servicios. Permite a los administradores definir reglas y condiciones basadas en atributos como fuente, destino, encabezados e incluso carga útil de la solicitud para determinar si una solicitud debe ser permitida o denegada. AuthorizationPolicy ayuda a aplicar reglas de autorización detalladas, otorgando o denegando acceso a recursos o acciones específicas basadas en las políticas definidas. Solo los clientes autorizados con permisos apropiados pueden acceder a puntos finales específicos o realizar operaciones particulares dentro de la malla de servicios. Aquí puedes ver un ejemplo de un objeto Authorization Policy:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: rbac-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  rules:
    - from:
        - source:
            principals: ["user:user@example.com"]
      to:
        - operation:
            methods: ["GET"]

Aquí puedes ser tan detallado como necesites; puedes aplicar reglas sobre la fuente de la solicitud para asegurar que solo algunas recomendaciones puedan pasar (por ejemplo, solicitudes que provienen de un token JWT para usar en combinación con el objeto RequestAuthentication), pero también reglas sobre el destino, si esto va a un host o ruta específica o método o una combinación de ambos. Además, puedes aplicar reglas de PERMITIR o DENEGAR (o incluso PERSONALIZADAS) y definir un conjunto de ellas, y todas se aplicarán en su conjunto. La evaluación se determina por las siguientes reglas como se indica en la Documentación Oficial de Istio:

  • Si hay políticas PERSONALIZADAS que coinciden con la solicitud, evalúa y niega la solicitud si el resultado de la evaluación es denegado.
  • Si hay políticas de DENEGAR que coinciden con la solicitud, niega la solicitud.
  • Si no hay políticas de PERMITIR para la carga de trabajo, permite la solicitud.
  • Si alguna de las políticas de PERMITIR coincide con la solicitud, permite la solicitud. Niega la solicitud.
Flujo de validación de la Política de Autorización de: https://istio.io/latest/docs/concepts/security/

Esto proporcionará todos los requisitos que podrías necesitar para poder hacer una definición completa de todas las políticas de seguridad necesarias.

 Conclusión

En conclusión, las Políticas de Seguridad de Istio proporcionan mecanismos robustos para mejorar la seguridad de los microservicios dentro de un entorno de malla de servicios. Los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy ofrecen un conjunto de herramientas integral para aplicar controles de autenticación y autorización, asegurando la comunicación segura y el control de acceso dentro de la malla de servicios. Al aprovechar estas Políticas de Seguridad de Istio, las organizaciones pueden fortalecer la postura de seguridad de sus microservicios, protegiendo datos sensibles y previniendo el acceso no autorizado o actividades maliciosas dentro de su entorno de malla de servicios.

Seguridad en Kubernetes: Un Viaje Colaborativo para Todos los Roles

por
Seguridad en Kubernetes: Un Viaje Colaborativo para Todos los Roles

La seguridad de Kubernetes es uno de los aspectos más críticos hoy en día en el mundo de TI. Kubernetes se ha convertido en la columna vertebral de la gestión moderna de infraestructuras, permitiendo a las organizaciones escalar y desplegar aplicaciones en contenedores con facilidad. Sin embargo, el poder de Kubernetes también conlleva la responsabilidad de garantizar que se implementen medidas de seguridad robustas. Esta responsabilidad no puede recaer únicamente en los desarrolladores o los operadores. Requiere un esfuerzo colaborativo donde ambas partes trabajen juntas para mitigar riesgos y vulnerabilidades potenciales.

Aunque los enfoques de DevOps e Ingeniería de Plataformas son bastante estándar, todavía hay tareas responsables de diferentes equipos, incluso aunque hoy en día existan equipos de plataforma y de proyecto.

Aquí verás tres formas fáciles de mejorar la seguridad de Kubernetes desde las perspectivas de desarrollo y operaciones:

Sin Vulnerabilidades en Imágenes de Contenedores

El escaneo de vulnerabilidades en imágenes de contenedores es algo crucial en los desarrollos actuales porque el número de componentes desplegados en el sistema ha crecido exponencialmente, así como su opacidad. El escaneo de vulnerabilidades utilizando herramientas como Trivy o las opciones integradas en nuestros entornos locales de Docker como Docker Desktop o Rancher Desktop es obligatorio, pero ¿cómo puedes usarlo para hacer tu aplicación más segura?

  • Responsabilidad del desarrollador:
    • Usar solo imágenes base estándar permitidas, bien conocidas
    • Reducir, al mínimo, el número de componentes y paquetes a instalar con tu aplicación (mejor Alpine que Debian)
    • Usar un enfoque de múltiples etapas para incluir solo lo que necesitarás en tus imágenes.
    • Realizar un escaneo de vulnerabilidades localmente antes de hacer push
  • Responsabilidad del operador:
    • Forzar la descarga de todas las imágenes base para el registro de contenedores corporativo
    • Imponer el escaneo de vulnerabilidades al hacer push, generando alertas y evitando el despliegue si no se cumplen los criterios de calidad.
    • Realizar escaneos de vulnerabilidades regulares para imágenes en tiempo de ejecución y generar incidentes para los equipos de desarrollo basados en los problemas descubiertos.

Sin Privilegios Adicionales en Imágenes de Contenedores

Ahora que nuestra aplicación no incluye ninguna vulnerabilidad, necesitamos asegurarnos de que la imagen no esté permitida para hacer lo que no debería, como elevar privilegios. Ve lo que puedes hacer dependiendo de tu rol:

  • Responsabilidad del desarrollador:
    • Nunca crear imágenes con usuario root y usar opciones de contexto de seguridad en tus archivos de manifiesto de Kubernetes
    • Probar tus imágenes con todas las capacidades posibles eliminadas a menos que se necesiten por alguna razón específica
    • Hacer que tu sistema de archivos sea de solo lectura y usar volúmenes para las carpetas requeridas en tu aplicación.
  • Responsabilidad del operador:

Restringir la visibilidad entre componentes

Cuando diseñamos aplicaciones hoy en día, se espera que necesiten conectarse a otras aplicaciones y componentes, y las capacidades de descubrimiento de servicios en Kubernetes son excelentes en cómo podemos interactuar. Sin embargo, esto también permite que otras aplicaciones se conecten a servicios a los que tal vez no deberían. Ve lo que puedes hacer para ayudar en ese aspecto dependiendo de tu rol y responsabilidad:

  • Responsabilidad del desarrollador:
    • Asegurarse de que tu aplicación tenga políticas adecuadas de autenticación y autorización para evitar cualquier uso no autorizado de tu aplicación.
  • Responsabilidad de operación:
    • Gestionar a nivel de plataforma la visibilidad de red de los componentes, pero denegar todo el tráfico por defecto y permitir las conexiones requeridas por diseño usando Políticas de Red.
    • Usar herramientas de Service Mesh para tener un enfoque central para la autenticación y autorización.
    • Usar herramientas como Kiali para monitorear el tráfico de red y detectar patrones de tráfico irrazonables.

Conclusión

En conclusión, la importancia de la seguridad en Kubernetes no puede ser subestimada. Requiere colaboración y responsabilidad compartida entre desarrolladores y operadores. Al enfocarse en prácticas como el escaneo de vulnerabilidades, la restricción de privilegios adicionales y la restricción de visibilidad entre componentes, las organizaciones pueden crear un entorno de Kubernetes más seguro. Al trabajar juntos, los desarrolladores y operadores pueden fortalecer el ecosistema de contenedores, protegiendo aplicaciones, datos y activos empresariales críticos de posibles brechas de seguridad. Con un enfoque colaborativo en la seguridad de Kubernetes, las organizaciones pueden aprovechar con confianza todo el potencial de esta poderosa plataforma de orquestación mientras mantienen los más altos estándares de seguridad. Al adoptar estas prácticas, las organizaciones pueden crear un entorno de Kubernetes más seguro, protegiendo sus aplicaciones y datos de amenazas potenciales.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.