Articles

Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

por
Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

Introducción

El autoescalado de Kubernetes ha sufrido un cambio dramático. Desde el lanzamiento de Kubernetes 1.26, todos los componentes deben migrar sus objetos HorizontalPodAutoscaler de la versión v1 a la nueva versión v2 que ha estado disponible desde Kubernetes 1.23.

HorizontalPodAutoscaler es un componente crucial en cualquier carga de trabajo desplegada en un clúster de Kubernetes, ya que la escalabilidad de esta solución es uno de los grandes beneficios y características clave de este tipo de entorno.

Un poco de Historia

Kubernetes ha introducido una solución para la capacidad de autoescalado desde la versión Kubernetes 1.3 hace mucho tiempo, en 2016. Y la solución se basaba en un bucle de control que se ejecuta en un intervalo específico que puedes configurar con los parámetros de la propiedad --horizontal-pod-autoscaler-sync-period que pertenecen al kube-controller-manager.

Entonces, una vez durante este período, obtendrá las métricas y evaluará a través de la condición definida en el componente HorizontalPodAutoscaler. Inicialmente, se basaba en los recursos de cómputo utilizados por el pod, memoria principal y CPU.

Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

Esto proporcionó una excelente característica, pero con el paso del tiempo y la adopción del entorno de Kubernetes, se ha mostrado un poco limitado para manejar todos los escenarios que deberíamos tener, y aquí es donde otros proyectos impresionantes que hemos discutido aquí, como KEDA entran en escena para proporcionar un conjunto de características mucho más flexible.

Capacidades de Autoescalado de Kubernetes Introducidas v2

Con el lanzamiento de la v2 de los objetos de la API de Autoescalado, hemos incluido una gama de capacidades para mejorar la flexibilidad y las opciones disponibles ahora. Las más relevantes son las siguientes:

  • Escalado en métricas personalizadas: Con el nuevo lanzamiento, puedes configurar un objeto HorizontalPodAutoscaler para escalar usando métricas personalizadas. Cuando hablamos de métricas personalizadas, hablamos de cualquier métrica generada desde Kubernetes. Puedes ver una guía detallada sobre el uso de métricas personalizadas en la documentación oficial
  • Escalado en múltiples métricas: Con el nuevo lanzamiento, también tienes la opción de escalar basado en más de una métrica. Así que ahora el HorizontalPodAutoscaler evaluará cada condición de regla de escalado, propondrá un nuevo valor de escala para cada una de ellas, y tomará el valor máximo como el final.
  • Soporte para la API de Métricas: Con el nuevo lanzamiento, el controlador de los componentes de HoriztalPodAutoscaler recupera métricas de una serie de APIs registradas, como metrics.k8s.io, custom.metrics.k8s.io, external.metrics.k8s.io. Para más información sobre las diferentes métricas disponibles, puedes echar un vistazo a la propuesta de diseño
  • Comportamiento de Escalado Configurable: Con el nuevo lanzamiento, tienes un nuevo campo, behavior, que permite configurar cómo se comportará el componente en términos de actividad de escalado hacia arriba o hacia abajo. Así, puedes definir diferentes políticas para el escalado hacia arriba y otras para el escalado hacia abajo, limitar el número máximo de réplicas que se pueden agregar o eliminar en un período específico, para manejar los problemas con los picos de algunos componentes como las cargas de trabajo de Java, entre otros. También, puedes definir una ventana de estabilización para evitar el estrés cuando la métrica aún está fluctuando.

Kubernetes Autoscaling v2 vs KEDA

Hemos visto todos los nuevos beneficios que proporciona Autoscaling v2, así que estoy seguro de que la mayoría de ustedes se están haciendo la misma pregunta: ¿Está Kubernetes Autoscaling v2 matando a KEDA?

Desde las últimas versiones de KEDA, KEDA ya incluye los nuevos objetos bajo el grupo autoscaling/v2 como parte de su desarrollo, ya que KEDA se basa en los objetos nativos de Kubernetes, y simplifica parte del proceso que necesitas hacer cuando quieres usar métricas personalizadas o externas, ya que tienen escaladores disponibles para prácticamente todo lo que podrías necesitar ahora o incluso en el futuro.

Pero, incluso con eso, todavía hay características que KEDA proporciona que no están cubiertas aquí, como las capacidades de escalado “desde cero” y “a cero” que son muy relevantes para tipos específicos de cargas de trabajo y para obtener un uso muy optimizado de los recursos. Aún así, es seguro decir que con las nuevas características incluidas en el lanzamiento de autoscaling/v2, la brecha ahora es más pequeña. Dependiendo de tus necesidades, puedes optar por las capacidades listas para usar sin incluir un nuevo componente en tu arquitectura.

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

por
¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Istio te permite configurar Sticky Session, entre otras características de red, para tus cargas de trabajo de Kubernetes. Como hemos comentado en varios artículos sobre Istio, istio despliega una malla de servicios que proporciona un plano de control central para tener toda la configuración relacionada con los aspectos de red de tus cargas de trabajo de Kubernetes. Esto cubre muchos aspectos diferentes de la comunicación dentro de la plataforma de contenedores, como la seguridad que cubre el transporte seguro, la autenticación o la autorización, y, al mismo tiempo, características de red, como el enrutamiento y la distribución de tráfico, que es el tema principal del artículo de hoy.

Estas capacidades de enrutamiento son similares a lo que un Balanceador de Carga tradicional de Nivel 7 puede proporcionar. Cuando hablamos de Nivel 7, nos referimos a los niveles convencionales que componen la pila OSI, donde el nivel 7 está relacionado con el Nivel de Aplicación.

Una configuración de Sticky Session o Afinidad de Sesión es una de las características más comunes que puedes necesitar implementar en este escenario. El caso de uso es el siguiente:

¿Cómo habilitar Sticky Session en tus cargas de trabajo de Kubernetes usando Istio?

Tienes varias instancias de tus cargas de trabajo, por lo que diferentes réplicas de pods en una situación de Kubernetes. Todos estos pods detrás del mismo servicio. Por defecto, redirigirá las solicitudes de manera round-robin entre las réplicas de pods en un estado Ready, por lo que Kubernetes entiende que están listas para recibir la solicitud a menos que lo definas de manera diferente.

Pero en algunos casos, principalmente cuando estás tratando con una aplicación web o cualquier aplicación con estado que maneja el concepto de una sesión, podrías querer que la réplica que procesa la primera solicitud también maneje el resto de las solicitudes durante la vida útil de la sesión.

Por supuesto, podrías hacer eso fácilmente simplemente enrutando todo el tráfico a una solicitud, pero en ese caso, perderíamos otras características como el balanceo de carga de tráfico y HA. Entonces, esto generalmente se implementa usando políticas de Afinidad de Sesión o Sticky Session que proporcionan lo mejor de ambos mundos: la misma réplica manejando todas las solicitudes de un usuario, pero distribución de tráfico entre diferentes usuarios.

¿Cómo funciona Sticky Session?

El comportamiento detrás de esto es relativamente fácil. Veamos cómo funciona.

Primero, lo importante es que necesitas «algo» como parte de tus solicitudes de red que identifique todas las solicitudes que pertenecen a la misma sesión, para que el componente de enrutamiento (en este caso, este rol lo desempeña istio) pueda determinar qué parte necesita manejar estas solicitudes.

Este «algo» que usamos para hacer eso, puede ser diferente dependiendo de tu configuración, pero generalmente, esto es una Cookie o un Encabezado HTTP que enviamos en cada solicitud. Por lo tanto, sabemos que la réplica maneja todas las solicitudes de ese tipo específico.

¿Cómo implementa Istio el soporte para Sticky Session?

En el caso de usar Istio para desempeñar este rol, podemos implementar eso usando una Regla de Destino específica que nos permite, entre otras capacidades, definir la política de tráfico para definir cómo queremos que se divida el tráfico y para implementar el Sticky Session necesitamos usar la característica “consistentHash”, que permite que todas las solicitudes que se computan al mismo hash sean enviadas a la réplica.

Cuando definimos las características de consistentHash, podemos decir cómo se creará este hash y, en otras palabras, qué componentes se usarán para generar este hash, y esto puede ser una de las siguientes opciones:

  • httpHeaderName: Usa un Encabezado HTTP para hacer la distribución de tráfico
  • httpCookie: Usa una Cookie HTTP para hacer la distribución de tráfico
  • httpQueryParameterName: Usa una Cadena de Consulta para hacer la Distribución de Tráfico.
  • maglev: Usa el Balanceador de Carga Maglev de Google para hacer la determinación. Puedes leer más sobre Maglev en el artículo de Google.
  • ringHash: Usa un enfoque de hash basado en anillo para el balanceo de carga entre los pods disponibles.

Entonces, como puedes ver, tendrás muchas opciones diferentes. Aún así, solo las tres primeras serían las más utilizadas para implementar una sesión persistente, y generalmente, la opción de Cookie HTTP (httpCookie) será la preferida, ya que se basaría en el enfoque HTTP para gestionar la sesión entre clientes y servidores.

Ejemplo de Implementación de Sticky Session usando TIBCO BW

Definiremos una carga de trabajo TIBCO BW muy simple para implementar un servicio REST, sirviendo una respuesta GET con un valor codificado. Para simplificar el proceso de validación, la aplicación registrará el nombre de host del pod para que rápidamente podamos ver quién está manejando cada una de las solicitudes:

¿Cómo habilitar Sticky Session en tus cargas de trabajo de Kubernetes usando Istio?

Desplegamos esto en nuestro clúster de Kubernetes y lo exponemos usando un servicio de Kubernetes; en nuestro caso, el nombre de este servicio será test2-bwce-srv

Además de eso, aplicamos la configuración de istio, que requerirá tres (3) objetos de istio: gateway, servicio virtual y la regla de destino. Como nuestro enfoque está en la regla de destino, intentaremos mantenerlo lo más simple posible en los otros dos objetos:

 apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: default-gw
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP

Servicio Virtual:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: test-vs
spec:
  gateways:
  - default-gw
  hosts:
  - test.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: test2-bwce-srv
        port:
          number: 8080

Y finalmente, la DestinationRule usará una httpCookie que llamaremos ISTIOD, como puedes ver en el fragmento a continuación:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
    name: default-sticky-dr
    namespace: default
spec:
    host: test2-bwce-srv.default.svc.cluster.local
    trafficPolicy:
      loadBalancer:
        consistentHash:
          httpCookie: 
            name: ISTIOID
            ttl: 60s

Ahora, que ya hemos comenzado nuestra prueba, y después de lanzar la primera solicitud, obtenemos una nueva Cookie que es generada por istio mismo que se muestra en la ventana de respuesta de Postman:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Esta solicitud ha sido manejada por una de las réplicas disponibles del servicio, como puedes ver aquí:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Todas las solicitudes subsiguientes de Postman ya incluyen la cookie, y todas ellas son manejadas desde el mismo pod:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Mientras que el registro de la otra réplica está vacío, ya que todas las solicitudes han sido enrutadas a ese pod específico.

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Resumen

Cubrimos en este artículo la razón detrás de la necesidad de una sesión persistente en la carga de trabajo de Kubernetes y cómo podemos lograr eso usando las capacidades de la Malla de Servicios de Istio. Así que, espero que esto pueda ayudar a implementar esta configuración en tus cargas de trabajo que puedas necesitar hoy o en el futuro.

Desbloqueando el Rendimiento y la Adaptabilidad: Explorando el Autoscaling Vertical de Kubernetes

por
Desbloqueando el Rendimiento y la Adaptabilidad: Explorando el Autoscaling Vertical de Kubernetes

Kubernetes ha introducido como su versión alfa en su lanzamiento de Kubernetes 1.27 la capacidad de Autoscaling Vertical de Pods para proporcionar la opción de que la carga de trabajo de Kubernetes pueda escalar utilizando el enfoque «vertical» al agregar más recursos a un pod existente. Esto aumenta las capacidades de escalado automático de sus cargas de trabajo de Kubernetes que tiene a su disposición, como KEDA o Autoscaling Horizontal de Pods.

Escalado Vertical vs Escalado Horizontal

El escalado vertical y horizontal son dos enfoques utilizados para aumentar el rendimiento y la capacidad de los sistemas informáticos, particularmente en sistemas distribuidos y computación en la nube. El escalado vertical, también conocido como escalado hacia arriba o escalado verticalmente, implica agregar más recursos, como potencia de procesamiento, memoria o almacenamiento, a una sola instancia o servidor. Esto significa actualizar los componentes de cómputo existentes o migrar a una infraestructura más potente. El escalado vertical a menudo es sencillo de implementar y requiere cambios mínimos en la arquitectura del software. Se utiliza comúnmente cuando las demandas del sistema pueden ser satisfechas por una sola infraestructura más potente.

Por otro lado, el escalado horizontal, también llamado escalado hacia afuera o escalado horizontalmente, implica agregar más instancias o servidores para distribuir la carga de trabajo. En lugar de actualizar una sola instancia, se emplean múltiples instancias, cada una manejando una parte de la carga de trabajo. El escalado horizontal ofrece la ventaja de aumentar la redundancia y la tolerancia a fallos, ya que múltiples instancias pueden compartir la carga. Además, proporciona la capacidad de manejar cargas de trabajo más grandes simplemente agregando más máquinas al clúster. Sin embargo, el escalado horizontal a menudo requiere arquitecturas de software más complejas, como balanceo de carga y sistemas de archivos distribuidos, para distribuir y gestionar eficientemente la carga de trabajo entre las máquinas.

En resumen, el escalado vertical implica mejorar las capacidades de un solo objeto, mientras que el escalado horizontal implica distribuir la carga de trabajo entre múltiples instancias. El escalado vertical es más fácil de implementar, pero puede tener limitaciones en términos de los recursos máximos disponibles en una sola máquina. El escalado horizontal proporciona mejor escalabilidad y tolerancia a fallos, pero requiere una infraestructura de software más compleja. La elección entre el escalado vertical y horizontal depende de factores como los requisitos específicos del sistema, la carga de trabajo esperada y los recursos disponibles.

¿Por qué el Autoscaling Vertical de Kubernetes?

Este es un tema interesante porque hemos estado viviendo en un mundo donde el estado era que siempre era mejor escalar hacia afuera (usando el Escalado Horizontal) en lugar de escalar hacia arriba (usando el Escalado Vertical) y especialmente este era uno de los mantras que escuchabas en desarrollos nativos de la nube. Y eso no ha cambiado porque el escalado horizontal proporciona muchos más beneficios que el escalado vertical y está bien cubierto con las capacidades de Autoscaling o proyectos paralelos como KEDA. Entonces, en ese caso, ¿por qué Kubernetes está incluyendo esta característica y por qué estamos usando este sitio para discutirlo?

Porque con la transformación de Kubernetes para ser la alternativa de facto para cualquier implementación que realices hoy en día, las características y capacidades de las cargas de trabajo que necesitas manejar se han ampliado y por eso necesitas usar diferentes técnicas para proporcionar la mejor experiencia a cada uno de los tipos de cargas de trabajo.

¿Cómo el Autoscaling Vertical de Kubernetes?

Aquí encontrarás toda la documentación sobre esta nueva característica que, como se comentó, todavía está en la etapa «alfa», por lo que es algo para probar en modo experimental en lugar de usarlo a nivel de producción Documentación de HPA

El Escalado Vertical funciona de manera que podrás cambiar los recursos asignados al pod, CPU y memoria sin necesidad de reiniciar el pod y cambiar la declaración del manifiesto, y ese es un claro beneficio de este enfoque. Como sabes, hasta ahora si quieres cambiar los recursos aplicados a una carga de trabajo necesitas actualizar el documento del manifiesto y reiniciar el pod para aplicar los nuevos cambios.

Para definir esto necesitas especificar el resizePolicy agregando una nueva sección al manifiesto del pod como puedes ver aquí:

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Por ejemplo, en este caso definimos para los diferentes nombres de recursos la política que queremos aplicar, si vamos a cambiar la CPU asignada no requerirá un reinicio, pero en caso de que estemos cambiando la memoria, requeriría un reinicio.

Eso implica que si deseas cambiar la CPU asignada, puedes parchear directamente el manifiesto como puedes ver en el fragmento a continuación y eso proporciona una actualización de los recursos asignados:

 kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

¿Cuándo usar el Escalado Vertical son los escenarios objetivo?

Dependerá de muchos escenarios diferentes del caso de uso, pero también de la pila tecnológica que está utilizando tu carga de trabajo para saber cuáles de estas capacidades pueden aplicarse. Como algo normal, el cambio de CPU será fácil de adaptar a cualquier tecnología, pero el de memoria sería más difícil dependiendo de la tecnología utilizada, ya que en la mayoría de las tecnologías la memoria asignada se define en el momento del inicio.

Esto ayudará a actualizar componentes que han cambiado sus requisitos como un escenario promedio o cuando estás probando nuevas cargas de trabajo con carga en vivo y no quieres interrumpir el procesamiento actual de la aplicación o simplemente cargas de trabajo que no admiten el escalado horizontal porque están diseñadas en modo de réplica única.

 Conclusión

En conclusión, Kubernetes ha introducido el Autoscaling Vertical de Pods, permitiendo el autoscaling vertical de cargas de trabajo de Kubernetes al agregar recursos a pods existentes. El autoscaling vertical de Kubernetes permite cambios de recursos sin reiniciar pods, proporcionando flexibilidad en la gestión de asignaciones de CPU y memoria.

El autoscaling vertical de Kubernetes ofrece una opción valiosa para adaptarse a las necesidades cambiantes de las cargas de trabajo. Complementa el escalado horizontal al proporcionar flexibilidad sin la necesidad de arquitecturas de software complejas. Al combinar enfoques de escalado vertical y horizontal, los usuarios de Kubernetes pueden optimizar sus implementaciones en función de las características específicas de la carga de trabajo y los recursos disponibles.

Asegurando la Seguridad de Kubernetes: Un Viaje Colaborativo para Desarrolladores y Operadores

por
Asegurando la Seguridad de Kubernetes: Un Viaje Colaborativo para Desarrolladores y Operadores

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.

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.

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.

Explorando los Contenedores Efímeros en Kubernetes: Revelando una Potente Herramienta de Depuración

por
Explorando los Contenedores Efímeros en Kubernetes: Revelando una Potente Herramienta de Depuración

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!

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.

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.

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.