Admisión de Seguridad de Pods (PSA) en Kubernetes: qué es, cómo funciona y sus limitaciones

Admisión de Seguridad de Pods (PSA) en Kubernetes: qué es, cómo funciona y sus limitaciones

En Kubernetes, la seguridad es una preocupación clave, especialmente a medida que los contenedores y los microservicios crecen en complejidad. Una de las características esenciales de Kubernetes para la aplicación de políticas es Pod Security Admission (PSA), que reemplaza las obsoletas Pod Security Policies (PSP). PSA proporciona un enfoque más sencillo y flexible para aplicar políticas de seguridad, ayudando a los administradores a proteger los clústeres asegurándose de que solo se ejecuten pods compatibles.

Este artículo te guiará a través de PSA, los Estándares de Seguridad de Pods disponibles, cómo configurarlos y cómo aplicar políticas de seguridad a espacios de nombres específicos usando etiquetas.

¿Qué es Pod Security Admission (PSA)?

PSA es un controlador de admisión incorporado introducido en Kubernetes 1.23 para reemplazar las Políticas de Seguridad de Pods (PSP). Las PSP tenían una curva de aprendizaje pronunciada y podían volverse engorrosas al escalar políticas de seguridad en varios entornos. PSA simplifica este proceso aplicando los Estándares de Seguridad de Pods de Kubernetes basados en niveles de seguridad predefinidos sin necesidad de lógica personalizada para cada política.

Con PSA, los administradores de clústeres pueden restringir los permisos de los pods utilizando etiquetas que corresponden a Estándares de Seguridad de Pods específicos. PSA opera a nivel de espacio de nombres, permitiendo una mejor granularidad en el control de políticas de seguridad para diferentes cargas de trabajo.

Estándares de Seguridad de Pods

Kubernetes proporciona tres Estándares de Seguridad de Pods clave en el marco de PSA:

  • Privilegiado: Sin restricciones; permite todas las características y es el modo menos restrictivo. No se recomienda para cargas de trabajo de producción, pero puede usarse en entornos controlados o para cargas de trabajo que requieren permisos elevados.
  • Básico: Proporciona un buen equilibrio entre usabilidad y seguridad, restringiendo los aspectos más peligrosos de los privilegios de los pods mientras permite configuraciones comunes. Es adecuado para la mayoría de las aplicaciones que no necesitan permisos especiales.
  • Restringido: El nivel más estricto de seguridad. Este nivel está destinado a cargas de trabajo que requieren el más alto nivel de aislamiento y control, como clústeres multi-tenant o cargas de trabajo expuestas a internet.

Cada estándar incluye reglas específicas para limitar los privilegios de los pods, como prohibir contenedores privilegiados, restringir el acceso a la red del host y prevenir cambios en ciertos contextos de seguridad.

Configuración de Pod Security Admission (PSA)

Para habilitar PSA, necesitas etiquetar tus espacios de nombres según el nivel de seguridad que deseas aplicar. El formato de la etiqueta es el siguiente:

kubectl label --overwrite ns  pod-security.kubernetes.io/enforce=<value>

Por ejemplo, para aplicar una política de seguridad restringida en el espacio de nombres producción, ejecutarías:

kubectl label --overwrite ns production pod-security.kubernetes.io/enforce=restricted

En este ejemplo, Kubernetes aplicará automáticamente las reglas asociadas con la política restringida a todos los pods desplegados en el espacio de nombres producción.

Modos Adicionales de PSA

PSA también proporciona modos adicionales para un mayor control:

  • Auditar: Registra una violación de política pero permite que el pod se cree.
  • Advertir: Emite una advertencia pero permite la creación del pod.
  • Aplicar: Bloquea la creación del pod si viola la política.

Para configurar estos modos, utiliza las siguientes etiquetas:

kubectl label --overwrite ns      pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/audit=restricted     pod-security.kubernetes.io/warn=baseline

Esta configuración aplica el estándar básico mientras emite advertencias y registra violaciones para las reglas de nivel restringido.

Ejemplo: Configuración de Seguridad de Pods en un Espacio de Nombres

Veamos un ejemplo de cómo configurar la seguridad básica para el espacio de nombres dev. Primero, necesitas aplicar las etiquetas de PSA:

kubectl create namespace dev
kubectl label --overwrite ns dev pod-security.kubernetes.io/enforce=baseline

Ahora, cualquier pod desplegado en el espacio de nombres dev será verificado contra el estándar de seguridad básico. Si un pod viola la política básica (por ejemplo, al intentar ejecutar un contenedor privilegiado), se bloqueará su inicio.

También puedes combinar los modos advertir y auditar para rastrear violaciones sin bloquear pods:

kubectl label --overwrite ns dev     pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/warn=restricted     pod-security.kubernetes.io/audit=privileged

En este caso, PSA permitirá que los pods se ejecuten si cumplen con la política básica, pero emitirá advertencias por violaciones de nivel restringido y registrará cualquier violación de nivel privilegiado.

Aplicación de Políticas por Defecto

Una de las fortalezas de PSA es su simplicidad para aplicar políticas a nivel de espacio de nombres, pero los administradores podrían preguntarse si hay una forma de aplicar una política por defecto en nuevos espacios de nombres automáticamente. Hasta ahora, Kubernetes no proporciona de forma nativa una opción para aplicar políticas de PSA globalmente por defecto. Sin embargo, puedes usar webhooks de admisión o herramientas de automatización como OPA Gatekeeper o Kyverno para aplicar políticas por defecto para nuevos espacios de nombres.

Conclusión

Pod Security Admission (PSA) simplifica la aplicación de políticas en clústeres de Kubernetes, facilitando el cumplimiento de los estándares de seguridad en diferentes entornos. Al configurar los Estándares de Seguridad de Pods a nivel de espacio de nombres y usar etiquetas, los administradores pueden controlar el nivel de seguridad de las cargas de trabajo con facilidad. La flexibilidad de PSA permite una gestión eficiente de la seguridad sin la complejidad asociada con las antiguas Políticas de Seguridad de Pods (PSP).

Para más detalles sobre la configuración de PSA y los Estándares de Seguridad de Pods, consulta la documentación oficial de PSA de Kubernetes y la documentación de Estándares de Seguridad de Pods.

📚 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.

Comprendiendo los Hooks de Helm: Una Guía para Usar Hooks en tus Charts de Helm

Comprendiendo los Hooks de Helm: Una Guía para Usar Hooks en tus Charts de Helm

Helm, el gestor de paquetes para Kubernetes, es una herramienta poderosa para gestionar aplicaciones complejas de Kubernetes. Una de sus características avanzadas son los hooks de Helm. Los hooks te permiten intervenir en diferentes puntos de una operación de Helm, como antes o después de una instalación, actualización o eliminación. En este artículo, profundizaremos en los hooks disponibles, exploraremos cómo definirlos en tus charts de Helm y proporcionaremos casos de uso para cada uno.

¿Qué son los Hooks de Helm?

Los hooks de Helm son anotaciones especiales que se pueden agregar a los recursos en un chart de Helm. Estos hooks desencadenan acciones específicas durante el ciclo de vida de la liberación de un chart de Helm. Permiten a los desarrolladores realizar tareas como configurar requisitos previos, limpiar después de una operación o validar un despliegue.

Hooks de Helm Disponibles y Casos de Uso

Helm proporciona varios hooks que se pueden usar en diferentes etapas de una operación de Helm. Aquí hay un desglose de los hooks disponibles:

1. pre-install

Momento de Ejecución: Después de que las plantillas se renderizan pero antes de que se creen recursos en Kubernetes.
Casos de Uso: Imagina que necesitas crear un ConfigMap o secreto del que depende tu aplicación pero que no forma parte del chart principal. El hook pre-install puede crear este recurso antes de que se despliegue el resto del chart.

apiVersion: v1
kind: Job
metadata:
  name: setup-config
  annotations:
"helm.sh/hook": pre-install
spec:
  template:
spec:
  containers:
    - name: config-creator
      image: busybox
      command: ['sh', '-c', 'echo "config data" > /config/config.txt']

2. post-install

Momento de Ejecución: Después de que todos los recursos se crean en Kubernetes.
Casos de Uso: Si tu aplicación requiere que se carguen algunos datos iniciales en una base de datos después de que esté en funcionamiento, un hook post-install podría usarse para ejecutar un trabajo que pueble estos datos.

apiVersion: batch/v1
kind: Job
metadata:
  name: init-database
  annotations:
"helm.sh/hook": post-install
spec:
  template:
spec:
  containers:
    - name: db-init
      image: busybox
      command: ['sh', '-c', 'init-db-command']

3. pre-delete

Momento de Ejecución: En una solicitud de eliminación, antes de que se eliminen recursos de Kubernetes.
Casos de Uso: Usa un hook pre-delete para apagar servicios de manera ordenada o para respaldar datos importantes antes de eliminar una liberación de Helm.

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-before-delete
  annotations:
"helm.sh/hook": pre-delete
spec:
  template:
spec:
  containers:
    - name: backup
      image: busybox
      command: ['sh', '-c', 'backup-command']

4. post-delete

Momento de Ejecución: Después de que se han eliminado todos los recursos de la liberación.
Casos de Uso: Un hook post-delete podría usarse para limpiar recursos externos a Kubernetes que fueron creados por el chart de Helm, como recursos en la nube o entradas de bases de datos.

apiVersion: batch/v1
kind: Job
metadata:
  name: cleanup
  annotations:
"helm.sh/hook": post-delete
spec:
  template:
spec:
  containers:
    - name: cleanup
      image: busybox
      command: ['sh', '-c', 'cleanup-command']

5. pre-upgrade

Momento de Ejecución: En una solicitud de actualización, después de que las plantillas se renderizan, pero antes de que se actualicen los recursos.
Casos de Uso: Supón que necesitas validar algunas condiciones previas antes de aplicar una actualización. Un hook pre-upgrade puede ejecutar un trabajo para verificar el entorno o validar la nueva configuración.

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-upgrade-check
  annotations:
"helm.sh/hook": pre-upgrade
spec:
  template:
spec:
  containers:
    - name: upgrade-check
      image: busybox
      command: ['sh', '-c', 'upgrade-check-command']

6. post-upgrade

Momento de Ejecución: Después de que todos los recursos han sido actualizados.
Casos de Uso: Después de una actualización exitosa, un hook post-upgrade podría usarse para desencadenar un trabajo que verifique la funcionalidad de la aplicación o migre datos a un nuevo esquema.

apiVersion: batch/v1
kind: Job
metadata:
  name: post-upgrade-verify
  annotations:
"helm.sh/hook": post-upgrade
spec:
  template:
spec:
  containers:
    - name: verification
      image: busybox
      command: ['sh', '-c', 'verify-upgrade']

7. pre-rollback

Momento de Ejecución: En una solicitud de reversión, después de que las plantillas se renderizan, pero antes de que se reviertan los recursos.
Casos de Uso: Este hook puede usarse para preparar el sistema para la reversión, como respaldar datos o notificar a otros sistemas sobre la reversión inminente.

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-rollback-backup
  annotations:
"helm.sh/hook": pre-rollback
spec:
  template:
spec:
  containers:
    - name: backup
      image: busybox
      command: ['sh', '-c', 'rollback-backup']

8. post-rollback

Momento de Ejecución: Después de que todos los recursos han sido modificados por la reversión.
Casos de Uso: Usa un hook post-rollback para verificar el estado de la aplicación después de una reversión o para notificar a sistemas externos sobre la finalización de la reversión.

apiVersion: batch/v1
kind: Job
metadata:
  name: post-rollback-verify
  annotations:
"helm.sh/hook": post-rollback
spec:
  template:
spec:
  containers:
    - name: verify
      image: busybox
      command: ['sh', '-c', 'verify-rollback']

9. test

Momento de Ejecución: Se ejecuta cuando se invoca el subcomando helm test.
Casos de Uso: Este hook es ideal para ejecutar pruebas contra una liberación de Helm para verificar que funcione como se espera.

apiVersion: batch/v1
kind: Job
metadata:
  name: test-application
  annotations:
"helm.sh/hook": test
spec:
  template:
spec:
  containers:
    - name: test
      image: busybox
      command: ['sh', '-c', 'run-tests']

Anotaciones en Hooks de Helm

Además de definir hooks, Helm te permite controlar la ejecución de hooks usando anotaciones:

  • helm.sh/resource-policy: Previene que los recursos sean eliminados después de que el hook se ejecute. Valor posible:
  • keep: Mantiene el recurso después de que el hook se ejecute, útil para depuración o retención de registros.
  • helm.sh/hook-weight: Especifica el orden en el que los hooks deben ejecutarse. Los hooks con pesos más bajos se ejecutan antes que aquellos con pesos más altos.
  • helm.sh/hook-delete-policy: Controla cuándo deben eliminarse los recursos del hook. Los valores posibles incluyen:
  • hook-succeeded: Elimina el recurso si la ejecución del hook es exitosa.
  • hook-failed: Elimina el recurso si la ejecución del hook falla.
  • before-hook-creation: Elimina recursos de hooks anteriores antes de crear nuevos, asegurando que solo una instancia del hook esté activa.

Conclusión

Los hooks de Helm son herramientas poderosas que proporcionan un control detallado sobre el ciclo de vida de despliegue de tus aplicaciones en Kubernetes. Al entender y aprovechar estos hooks, puedes asegurar que tus despliegues de Helm sean tanto robustos como confiables. Asegúrate de usar las anotaciones apropiadas para afinar aún más el comportamiento de tus hooks, optimizándolos para tu caso de uso específico.

Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

Gestionar los recursos de Kubernetes de manera efectiva puede a veces parecer abrumador, pero Helm, el gestor de paquetes de Kubernetes, ofrece varios comandos y banderas que hacen el proceso más fluido e intuitivo. En este artículo, profundizaremos en algunos comandos y banderas menos conocidos de Helm, explicando sus usos, beneficios y ejemplos prácticos.

1. helm get values: Recuperando Valores del Chart Desplegado

El comando helm get values es esencial cuando necesitas ver los valores de configuración de un chart de Helm desplegado. Esto es particularmente útil cuando tienes un chart desplegado pero no tienes acceso a su archivo de configuración original. Con este comando, puedes lograr un enfoque de «Infraestructura como Código» capturando el estado actual de tu despliegue.

Uso:

helm get values <release-name> [flags]
  • <release-name>: El nombre de tu release de Helm.

Ejemplo:

Para obtener los valores de un chart desplegado llamado my-release:

helm get values my-release --namespace my-namespace

Este comando muestra los valores actuales utilizados para el despliegue, lo cual es valioso para la documentación, replicar el entorno o modificar despliegues.

2. Entendiendo las Banderas de helm upgrade: --reset-values, --reuse-values, y --reset-then-reuse

El comando helm upgrade se utiliza típicamente para actualizar o modificar un release de Helm existente. Sin embargo, el comportamiento de este comando puede ajustarse finamente usando varias banderas: --reset-values, --reuse-values, y --reset-then-reuse.

  • --reset-values: Ignora los valores previos y utiliza solo los valores proporcionados en el comando actual. Usa esta bandera cuando quieras sobrescribir completamente la configuración existente.

Escenario de Ejemplo: Estás desplegando una nueva versión de tu aplicación y quieres asegurarte de que no se retengan valores antiguos.

  helm upgrade my-release my-chart --reset-values --set newKey=newValue
  • --reuse-values: Reutiliza los valores del release anterior y los fusiona con cualquier nuevo valor proporcionado. Esta bandera es útil cuando quieres mantener la mayor parte de la configuración antigua pero aplicar algunos ajustes.

Escenario de Ejemplo: Necesitas agregar una nueva variable de entorno a un despliegue existente sin afectar las otras configuraciones.

  helm upgrade my-release my-chart --reuse-values --set newEnv=production
  • --reset-then-reuse: Una combinación de los dos. Se restablece a los valores originales y luego se fusionan los valores antiguos, permitiéndote comenzar con una hoja limpia mientras retienes configuraciones específicas.

Escenario de Ejemplo: Útil en entornos complejos donde quieres asegurarte de que el chart esté usando la configuración predeterminada original pero retener algunos valores personalizados.

  helm upgrade my-release my-chart --reset-then-reuse --set version=2.0

3. helm lint: Asegurando la Calidad del Chart en Pipelines CI/CD

El comando helm lint verifica los charts de Helm en busca de errores de sintaxis, mejores prácticas y otros problemas potenciales. Esto es especialmente útil al integrar Helm en un pipeline CI/CD, ya que asegura que tus charts sean confiables y se adhieran a las mejores prácticas antes del despliegue.

Uso:

helm lint <chart-path> [flags]
  • <chart-path>: Ruta al chart de Helm que deseas validar.

Ejemplo:

helm lint ./my-chart/

Este comando escanea el directorio my-chart en busca de problemas como campos faltantes, estructura YAML incorrecta o uso obsoleto. Si estás automatizando despliegues, integrar helm lint en tu pipeline ayuda a detectar problemas temprano.

Integrando helm lint en un Pipeline CI/CD:

En un pipeline de Jenkins, por ejemplo, podrías agregar la siguiente etapa:

pipeline {
  agent any
  stages {
stage('Lint Helm Chart') {
  steps {
    script {
      sh 'helm lint ./my-chart/'
    }
  }
}
// Otras etapas como build, test, deploy
  }
}

Al agregar esta etapa, aseguras que cualquier problema de sintaxis o estructura se detecte antes de proceder a las etapas de construcción o despliegue.

4. helm rollback: Revertir a un Release Anterior

El comando helm rollback te permite revertir un release a una versión anterior. Esto puede ser increíblemente útil en caso de una actualización o despliegue fallido, ya que proporciona una forma de restaurar rápidamente un estado conocido como bueno.

Uso:

helm rollback <release-name> [revision] [flags]
  • <release-name>: El nombre de tu release de Helm.
  • [revision]: El número de revisión al que deseas revertir. Si se omite, Helm revertirá al release anterior por defecto.

Ejemplo:

Para revertir un release llamado my-release a su versión anterior:

helm rollback my-release

Para revertir a una revisión específica, digamos la revisión 3:

helm rollback my-release 3

Este comando puede ser un salvavidas cuando un cambio reciente rompe tu aplicación, permitiéndote restaurar rápidamente la continuidad del servicio mientras investigas el problema.

5. helm verify: Validando un Chart Antes de Usarlo

El comando helm verify verifica la integridad y validez de un chart antes de que sea desplegado. Este comando asegura que el archivo del paquete del chart no haya sido manipulado o corrompido. Es particularmente útil cuando estás obteniendo charts de repositorios externos o usando charts compartidos entre varios equipos.

Uso:

helm verify <chart-path>
  • <chart-path>: Ruta al archivo del chart de Helm (.tgz file).

Ejemplo:

Para verificar un chart descargado llamado my-chart:

helm verify ./my-chart.tgz

Si el chart pasa la verificación, Helm mostrará un mensaje de éxito. Si falla, verás detalles de los problemas, que podrían ir desde archivos faltantes hasta discrepancias en el checksum.

Conclusión

Aprovechar estos comandos y banderas avanzados de Helm puede mejorar significativamente tus capacidades de gestión de Kubernetes. Ya sea que estés recuperando configuraciones de despliegue existentes, ajustando tus actualizaciones de Helm o asegurando la calidad de tus charts en un pipeline CI/CD, estos trucos te ayudan a mantener un entorno de Kubernetes robusto y eficiente.

Exponiendo Puertos TCP Usando Istio Ingress Gateway

Exponiendo Puertos TCP Usando Istio Ingress Gateway

Istio se ha convertido en una herramienta esencial para gestionar el tráfico HTTP dentro de los clústeres de Kubernetes, ofreciendo características avanzadas como Implementaciones Canary, mTLS y visibilidad de extremo a extremo. Sin embargo, algunas tareas, como exponer un puerto TCP usando el Istio IngressGateway, pueden ser desafiantes si nunca lo has hecho antes. Este artículo te guiará a través del proceso de exponer puertos TCP con Istio Ingress Gateway, completo con ejemplos del mundo real y casos de uso prácticos.

Entendiendo el Contexto

Istio se utiliza a menudo para gestionar el tráfico HTTP en Kubernetes, proporcionando capacidades poderosas como gestión de tráfico, seguridad y observabilidad. El Istio IngressGateway sirve como punto de entrada para el tráfico externo en el clúster de Kubernetes, manejando típicamente tráfico HTTP y HTTPS. Sin embargo, Istio también soporta tráfico TCP, lo cual es necesario para casos de uso como exponer bases de datos u otros servicios no HTTP que se ejecutan en el clúster a consumidores externos.

Exponer un puerto TCP a través de Istio implica configurar el IngressGateway para manejar el tráfico TCP y enrutarlo al servicio apropiado. Esta configuración es particularmente útil en escenarios donde necesitas exponer servicios como TIBCO EMS o bases de datos basadas en Kubernetes a otras aplicaciones internas o externas.

Pasos para Exponer un Puerto TCP con Istio IngressGateway

1.- Modificar el Servicio Istio IngressGateway:

Antes de configurar el Gateway, debes asegurarte de que el servicio Istio IngressGateway esté configurado para escuchar en el nuevo puerto TCP. Este paso es crucial si estás utilizando un servicio NodePort, ya que este puerto necesita ser abierto en el Balanceador de Carga.

   apiVersion: v1
   kind: Service
   metadata:
 name: istio-ingressgateway
 namespace: istio-system
   spec:
 ports:
 - name: http2
   port: 80
   targetPort: 80
 - name: https
   port: 443
   targetPort: 443
 - name: tcp
   port: 31400
   targetPort: 31400
   protocol: TCP

2.- Actualiza el servicio Istio IngressGateway para incluir el nuevo puerto 31400 para tráfico TCP.

Configura el Istio IngressGateway: Después de modificar el servicio, configura el Istio IngressGateway para escuchar en el puerto TCP deseado.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: tcp-ingress-gateway
  namespace: istio-system
spec:
  selector:
istio: ingressgateway
  servers:
  - port:
	  number: 31400
	  name: tcp
	  protocol: TCP
	hosts:
	- "*"

En este ejemplo, el IngressGateway está configurado para escuchar en el puerto 31400 para tráfico TCP.

3.- Crea un Servicio y VirtualService:

Después de configurar el gateway, necesitas crear un Servicio que represente la aplicación backend y un VirtualService para enrutar el tráfico TCP.

apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
spec:
  ports:
  - port: 31400
	targetPort: 8080
	protocol: TCP
  selector:
app: tcp-app

El Servicio anterior mapea el puerto 31400 en el IngressGateway al puerto 8080 en la aplicación backend.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: tcp-virtual-service
  namespace: default
spec:
  hosts:
  - "*"
  gateways:
  - tcp-ingress-gateway
  tcp:
  - match:
	- port: 31400
	route:
	- destination:
		host: tcp-service
		port:
		  number: 8080

El VirtualService enruta el tráfico TCP que llega al puerto 31400 en el gateway al tcp-service en el puerto 8080.

4.- Aplica la Configuración

Aplica las configuraciones anteriores usando kubectl para crear los recursos necesarios de Kubernetes.

kubectl apply -f istio-ingressgateway-service.yaml
kubectl apply -f tcp-ingress-gateway.yaml
kubectl apply -f tcp-service.yaml
kubectl apply -f tcp-virtual-service.yaml

Después de aplicar estas configuraciones, el Istio IngressGateway expondrá el puerto TCP al tráfico externo.

Casos de Uso Prácticos

  • Exponiendo el Servidor TIBCO EMS: Un escenario común es exponer un servidor TIBCO EMS (Enterprise Message Service) que se ejecuta dentro de un clúster de Kubernetes a otras aplicaciones internas o consumidores externos. Al configurar el Istio IngressGateway para manejar el tráfico TCP, puedes exponer de manera segura el puerto TCP de EMS, permitiendo que se comunique con servicios fuera del entorno de Kubernetes.
  • Exponiendo Bases de Datos: Otro caso de uso es exponer una base de datos que se ejecuta dentro de Kubernetes a servicios externos o diferentes clústeres. Al exponer el puerto TCP de la base de datos a través del Istio IngressGateway, permites que otras aplicaciones interactúen con ella, independientemente de su ubicación.
  • Exponiendo un Servicio Personalizado Basado en TCP: Supongamos que tienes una aplicación personalizada que se ejecuta dentro de Kubernetes y se comunica a través de TCP, como un servidor de juegos o un servicio API personalizado basado en TCP. Puedes usar el Istio IngressGateway para exponer este servicio a usuarios externos, haciéndolo accesible desde fuera del clúster.

Conclusión

Exponer puertos TCP usando el Istio IngressGateway puede ser una técnica poderosa para gestionar tráfico no HTTP en tu clúster de Kubernetes. Con los pasos descritos en este artículo, puedes exponer con confianza servicios como TIBCO EMS, bases de datos o aplicaciones personalizadas basadas en TCP a consumidores externos, mejorando la flexibilidad y conectividad de tus aplicaciones.

ConfigMap con Valores Opcionales en Kubernetes

ConfigMap con Valores Opcionales en Kubernetes

Los ConfigMaps de Kubernetes son una herramienta poderosa para gestionar datos de configuración por separado del código de la aplicación. Sin embargo, a veces pueden causar problemas durante el despliegue, particularmente cuando falta un ConfigMap referenciado en una especificación de Pod, lo que provoca que la aplicación no pueda iniciarse. Este es un escenario común que puede llevar a un CreateContainerConfigError y detener tu canal de despliegue.

Entendiendo el Problema

Cuando un ConfigMap es referenciado en la especificación de un Pod, Kubernetes espera que el ConfigMap esté presente. Si no lo está, Kubernetes no iniciará el Pod, lo que lleva a un despliegue fallido. Esto puede ser problemático en situaciones donde ciertos datos de configuración son opcionales o específicos del entorno, como configuraciones de proxy que solo son necesarias en ciertos entornos.

Haciendo Opcionales los Valores de ConfigMap

Kubernetes proporciona una forma de definir elementos de ConfigMap como opcionales, permitiendo que tu aplicación se inicie incluso si el ConfigMap no está presente. Esto puede ser particularmente útil para variables de entorno que solo necesitan establecerse bajo ciertas condiciones.

Aquí hay un ejemplo básico de cómo hacer un ConfigMap opcional:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    env:
    - name: OPTIONAL_ENV_VAR
      valueFrom:
        configMapKeyRef:
          name: example-configmap
          key: optional-key
          optional: true

En este ejemplo:

  • name: example-configmap se refiere al ConfigMap que podría o no estar presente.
  • optional: true asegura que el Pod se iniciará incluso si example-configmap o la optional-key dentro de él está ausente.

Caso de Uso Práctico: Configuración de Proxy

Un caso de uso común para valores opcionales de ConfigMap es establecer variables de entorno para la configuración de proxy. En muchos entornos empresariales, las configuraciones de proxy solo son necesarias en ciertos entornos de despliegue (por ejemplo, staging, producción) pero no en otros (por ejemplo, desarrollo local).

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
data:
  HTTP_PROXY: "http://proxy.example.com"
  HTTPS_PROXY: "https://proxy.example.com"

En tu especificación de Pod, podrías referenciar estas configuraciones de proxy como opcionales:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: my-app-image
    env:
    - name: HTTP_PROXY
      valueFrom:
        configMapKeyRef:
          name: proxy-config
          key: HTTP_PROXY
          optional: true
    - name: HTTPS_PROXY
      valueFrom:
        configMapKeyRef:
          name: proxy-config
          key: HTTPS_PROXY
          optional: true

En esta configuración, si el ConfigMap proxy-config falta, la aplicación aún se iniciará, simplemente sin las configuraciones de proxy.

Aplicación de Ejemplo

Vamos a recorrer un ejemplo simple para demostrar este concepto. Crearemos un despliegue para una aplicación que utiliza valores de configuración opcionales.

  1. Crear el ConfigMap (Opcional):
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  GREETING: "¡Hola, Mundo!"
  1. Desplegar la Aplicación:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: busybox
        command: ["sh", "-c", "echo $GREETING"]
        env:
        - name: GREETING
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: GREETING
              optional: true
  1. Desplegar y Probar:
  2. Despliega la aplicación usando kubectl apply -f <tu-archivo-de-despliegue>.yaml.
  3. Si el ConfigMap app-config está presente, el Pod mostrará «¡Hola, Mundo!».
  4. Si el ConfigMap falta, el Pod se iniciará, pero no se mostrará ningún saludo.

Conclusión

Los valores opcionales de ConfigMap son una forma simple pero efectiva de hacer que tus despliegues de Kubernetes sean más resilientes y adaptables a diferentes entornos. Al marcar las claves de ConfigMap como opcionales, puedes prevenir fallos en el despliegue y permitir que tus aplicaciones manejen la falta de configuración de manera elegante.

📚 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.

Soporte de registro de TIBCO BW ECS

Soporte de registro de TIBCO BW ECS

El soporte de registro de TIBCO BW ECS se está convirtiendo en una característica demandada debido al uso creciente del Esquema Común de Elastic para la solución de agregación de registros basada en la pila de Elastic (anteriormente conocida como pila ELK)

Ya hemos comentado mucho sobre la importancia de las soluciones de agregación de registros y sus beneficios, especialmente al discutir la arquitectura de contenedores. Debido a eso, hoy nos centraremos en cómo podemos adaptar nuestras aplicaciones BW para soportar este nuevo formato de registro.

Porque lo primero que necesitamos saber es la siguiente afirmación: Sí, esto se puede hacer. Y se puede hacer independientemente de su modelo de implementación. Por lo tanto, la solución proporcionada aquí funciona tanto para soluciones locales como para implementaciones en contenedores utilizando BWCE.

Antecedentes del Registro de TIBCO BW

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

BW ECS Logging: Ejemplo de configuración predeterminada de Logback.xml

Logback es una biblioteca bien conocida para desarrollos basados en Java y tiene una arquitectura basada en una solución central y complementos que extienden sus capacidades actuales. Es este enfoque de complemento el que vamos a utilizar para soportar ECS.

Incluso en la documentación oficial de ECS se cubre la configuración para habilitar esta configuración de registro cuando se utiliza la solución Logback, como puede ver en la imagen a continuación y en este enlace oficial:

BW ECS Logging: Información de Dependencia de ECS Java

En nuestro caso, no necesitamos agregar la dependencia en ningún lugar, sino simplemente descargar la dependencia, ya que necesitaremos incluirla en los paquetes OSGI existentes para la instalación de TIBCO BW. Solo necesitaremos dos archivos que son los siguientes:

  • ecs-logging-core-1.5.0.jar
  • logback-ecs-encoder-1.5.0.jar

En el momento de escribir este artículo, las versiones actuales son 1.5.0 para cada uno de ellos, pero manténgase atento para asegurarse de que está utilizando una versión reciente de este software para evitar problemas con el soporte y las vulnerabilidades.

Una vez que tengamos estas bibliotecas, necesitamos agregarlas a la instalación del sistema BW, y necesitamos hacerlo de manera diferente si estamos utilizando una instalación local de TIBCO o una instalación base de TIBCO BW. Para ser honesto, las cosas que necesitamos hacer son las mismas; el proceso de hacerlo es diferente.

Porque, al final, lo que necesitamos hacer es solo una tarea simple. Incluir estos archivos JAR como parte del paquete OSGI actual de logback que carga TIBCO BW. Así que, veamos cómo podemos hacer eso y comenzar con una instalación local. Usaremos la versión TIBCO BWCE 2.8.2 como ejemplo, pero se requerirán pasos similares para otras versiones.

La instalación local es la forma más fácil de hacerlo, pero solo porque tiene menos pasos que cuando lo hacemos en una imagen base de TIBCO BWCE. Así que, en este caso, iremos a la siguiente ubicación: <TIBCO_HOME>/bwce/2.8/system/shared/com.tibco.tpcl.logback_1.2.1600.002/

  • Colocaremos los JARs descargados en esa carpeta
BW ECS Logging: Ubicación del JAR
  • Abriremos el META-INF/MANIFEST.MF y haremos las siguientes modificaciones:
    • Agregar esos JARs a la sección Bundle-Classpath:
BW ECS Logging: Cambios en Bundle-Classpath
  • Incluir el siguiente paquete (co.elastic.logging.logback) como parte de los paquetes exportados agregándolo a la sección Exported-package:
BW ECS Logging: Cambios en Export-Package

Una vez hecho esto, nuestra instalación de TIBCO BW soporta el formato ECS. y solo necesitamos configurar el logback.xml para usarlo, y podemos hacerlo confiando en la documentación oficial en la página de ECS. Necesitamos incluir el siguiente codificador, como se muestra a continuación:

 <encoder class="co.elastic.logging.logback.EcsEncoder">
    <serviceName>mi-aplicación</serviceName>
    <serviceVersion>mi-versión-de-aplicación</serviceVersion>
    <serviceEnvironment>mi-entorno-de-aplicación</serviceEnvironment>
    <serviceNodeName>mi-nodo-de-clúster-de-aplicación</serviceNodeName>
</encoder>

Por ejemplo, si modificamos el archivo de configuración predeterminado logback.xml con esta información, tendremos algo como esto:

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true">
  
  <!-- *=============================================================* -->
  <!-- *  APPENDER: Console Appender                                 * -->
  <!-- *=============================================================* -->  
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="co.elastic.logging.logback.EcsEncoder">
      <serviceName>a</serviceName>
      <serviceVersion>b</serviceVersion>
      <serviceEnvironment>c</serviceEnvironment>
      <serviceNodeName>d</serviceNodeName>
  </encoder>
  </appender>



  <!-- *=============================================================* -->
  <!-- * LOGGER: Thor Framework loggers                              * -->
  <!-- *=============================================================* -->
  <logger name="com.tibco.thor.frwk">
    <level value="INFO"/>
  </logger>
  
  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Framework loggers                     * -->
  <!-- *=============================================================* -->
  <logger name="com.tibco.bw.frwk">
    <level value="WARN"/>
  </logger>  
  
  <logger name="com.tibco.bw.frwk.engine">
    <level value="INFO"/>
  </logger>   
  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Engine loggers                        * -->
  <!-- *=============================================================* --> 
  <logger name="com.tibco.bw.core">
    <level value="WARN"/>
  </logger>
  
  <logger name="com.tibco.bx">
    <level value="ERROR"/>
  </logger>

  <logger name="com.tibco.pvm">
    <level value="ERROR"/>
  </logger>
  
  <logger name="configuration.management.logger">
    <level value="INFO"/>
  </logger>
  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Palette and Activity loggers          * -->
  <!-- *=============================================================* -->
  
  <!-- Default Log activity logger -->
  <logger name="com.tibco.bw.palette.generalactivities.Log">
    <level value="DEBUG"/>
  </logger>
  
  <logger name="com.tibco.bw.palette">
    <level value="ERROR"/>
  </logger>

  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Binding loggers                       * -->
  <!-- *=============================================================* -->
  
  <!-- SOAP Binding logger -->
  <logger name="com.tibco.bw.binding.soap">
    <level value="ERROR"/>
  </logger>
  
  <!-- REST Binding logger -->
  <logger name="com.tibco.bw.binding.rest">
    <level value="ERROR"/>
  </logger>
  
  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Shared Resource loggers               * -->
  <!-- *=============================================================* --> 
  <logger name="com.tibco.bw.sharedresource">
    <level value="ERROR"/>
  </logger>
  
  
   
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Schema Cache loggers                  * -->
  <!-- *=============================================================* -->
  <logger name="com.tibco.bw.cache.runtime.xsd">
    <level value="ERROR"/>
  </logger> 
  
  <logger name="com.tibco.bw.cache.runtime.wsdl">
    <level value="ERROR"/>
  </logger> 
  
    
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Governance loggers                    * -->
  <!-- *=============================================================* -->  
  <!-- Governance: Policy Director logger1 --> 
  <logger name="com.tibco.governance">
    <level value="ERROR"/>
  </logger>
   
  <logger name="com.tibco.amx.governance">
    <level value="WARN"/>
  </logger>
   
  <!-- Governance: Policy Director logger2 -->
  <logger name="com.tibco.governance.pa.action.runtime.PolicyProperties">
    <level value="ERROR"/>
  </logger>
  
  <!-- Governance: SPM logger1 -->
  <logger name="com.tibco.governance.spm">
    <level value="ERROR"/>
  </logger>
  
  <!-- Governance: SPM logger2 -->
  <logger name="rta.client">
    <level value="ERROR"/>
  </logger>
  
  
    
  <!-- *=============================================================* -->
  <!-- * LOGGER: BusinessWorks Miscellaneous Loggers                 * -->
  <!-- *=============================================================* --> 
  <logger name="com.tibco.bw.platformservices">
    <level value="INFO"/>
  </logger>
  
  <logger name="com.tibco.bw.core.runtime.statistics">
    <level value="ERROR"/>
  </logger>
  

  
  <!-- *=============================================================* -->
  <!-- * LOGGER: Other loggers                                       * -->
  <!-- *=============================================================* -->  
  <logger name="org.apache.axis2">
    <level value="ERROR"/>
  </logger>

  <logger name="org.eclipse">
    <level value="ERROR"/>
  </logger>
  
  <logger name="org.quartz">
    <level value="ERROR"/>
  </logger>
  
  <logger name="org.apache.commons.httpclient.util.IdleConnectionHandler">
    <level value="ERROR"/>
  </logger>
  
  
  
  <!-- *=============================================================* -->
  <!-- * LOGGER: User loggers.  User's custom loggers should be      * -->
  <!-- *         configured in this section.                         * -->
  <!-- *=============================================================* -->

  <!-- *=============================================================* -->
  <!-- * ROOT                                                        * -->
  <!-- *=============================================================* --> 
  <root level="ERROR">
   <appender-ref ref="STDOUT" />
  </root>
  
</configuration>

También puede hacer configuraciones más personalizadas basadas en la información disponible en la página de configuración del codificador ECS aquí.

¿Cómo habilitar el soporte de registro de TIBCO BW ECS?

Para BWCE, los pasos son similares, pero debemos tener en cuenta que todos los componentes de tiempo de ejecución están empaquetados dentro del base-runtime-version.zip que descargamos de nuestro sitio de eDelivery de TIBCO, por lo que necesitaremos usar una herramienta para abrir ese ZIP y hacer las siguientes modificaciones:

  • Colocaremos los JARs descargados en esa carpeta /tibco.home/bwce/2.8/system/shared/com.tibco.tpcl.logback_1.2.1600.004
BW ECS Logging: Ubicación del JAR
  • Abriremos el META-INF/MANIFEST.MF y haremos las siguientes modificaciones:
    • Agregar esos JARs a la sección Bundle-Classpath:
BW ECS Logging: Cambios en Bundle-Classpath
  • Incluir el siguiente paquete (co.elastic.logging.logback) como parte de los paquetes exportados agregándolo a la sección Exported-package:
BW ECS Logging: Cambios en Export-package
  • Además, necesitaremos modificar el bwappnode en la ubicación /tibco.home/bwce/2.8/bin para agregar los archivos JAR también al classpath que la imagen base de BWCE usa para ejecutar y asegurar que esto se esté cargando:
BW ECS Logging: cambio en bwappnode

Ahora podemos construir nuestra imagen base de BWCE como de costumbre y modificar el logback.xml como se explicó anteriormente. Aquí puede ver una aplicación de ejemplo utilizando esta configuración:

{"@timestamp":"2023-08-28T12:49:08.524Z","log.level": "INFO","message":"TIBCO BusinessWorks version 2.8.2, build V17, 2023-05-19","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"main","log.logger":"com.tibco.thor.frwk"}

<>@BWEclipseAppNode> {"@timestamp":"2023-08-28T12:49:25.435Z","log.level": "INFO","message":"Started by BusinessStudio.","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"main","log.logger":"com.tibco.thor.frwk.Deployer"}
{"@timestamp":"2023-08-28T12:49:32.795Z","log.level": "INFO","message":"TIBCO-BW-FRWK-300002: BW Engine [Main] started successfully.","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"main","log.logger":"com.tibco.bw.frwk.engine.BWEngine"}
{"@timestamp":"2023-08-28T12:49:34.338Z","log.level": "INFO","message":"TIBCO-THOR-FRWK-300001: Started OSGi Framework of AppNode [BWEclipseAppNode] in AppSpace [BWEclipseAppSpace] of Domain [BWEclipseDomain]","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"Framework Event Dispatcher: Equinox Container: 1395256a-27a2-4e91-b774-310e85b0b87c","log.logger":"com.tibco.thor.frwk.Deployer"}
{"@timestamp":"2023-08-28T12:49:34.456Z","log.level": "INFO","message":"TIBCO-THOR-FRWK-300018: Deploying BW Application [t3:1.0].","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"Framework Event Dispatcher: Equinox Container: 1395256a-27a2-4e91-b774-310e85b0b87c","log.logger":"com.tibco.thor.frwk.Application"}
{"@timestamp":"2023-08-28T12:49:34.524Z","log.level": "INFO","message":"TIBCO-THOR-FRWK-300021: All Application dependencies are resolved for Application [t3:1.0]","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"Framework Event Dispatcher: Equinox Container: 1395256a-27a2-4e91-b774-310e85b0b87c","log.logger":"com.tibco.thor.frwk.Application"}
{"@timestamp":"2023-08-28T12:49:34.541Z","log.level": "INFO","message":"Started by BusinessStudio, ignoring .enabled settings.","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"Framework Event Dispatcher: Equinox Container: 1395256a-27a2-4e91-b774-310e85b0b87c","log.logger":"com.tibco.thor.frwk.Application"}
{"@timestamp":"2023-08-28T12:49:35.842Z","log.level": "INFO","message":"TIBCO-THOR-FRWK-300006: Started BW Application [t3:1.0]","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"EventAdminThread #1","log.logger":"com.tibco.thor.frwk.Application"}
{"@timestamp":"2023-08-28T12:49:35.954Z","log.level": "INFO","message":"aaaaaaa
","ecs.version": "1.2.0","service.name":"a","service.version":"b","service.environment":"c","service.node.name":"d","event.dataset":"a","process.thread.name":"bwEngThread:In-Memory Process Worker-1","log.logger":"com.tibco.bw.palette.generalactivities.Log.t3.module.Log"}
gosh: stopping shell

Impulsando la seguridad de Kubernetes: Explorando KubeSec – Una herramienta imprescindible para proteger tu clúster

Impulsando la seguridad de Kubernetes: Explorando KubeSec - Una herramienta imprescindible para proteger tu clúster

KubeSec es otra herramienta para ayudar a mejorar la seguridad de nuestro clúster de Kubernetes. Y estamos viendo a muchas agencias centrarse en la seguridad para resaltar la importancia de este tema en arquitecturas y despliegues modernos. La seguridad es ahora un componente clave, probablemente el más crucial. Todos necesitamos mejorar nuestro desempeño en ese tema, y por eso es esencial tener herramientas en nuestro conjunto de herramientas que nos ayuden en esa tarea sin ser expertos en seguridad en cada una de las tecnologías, como Kubernetes en este caso.

KubeSec es una herramienta de código abierto desarrollada por una consultoría de seguridad nativa de la nube y de código abierto llamada ControlPlane que nos ayuda a realizar un análisis de riesgo de seguridad en los recursos de Kubernetes.

¿Cómo Funciona KubeSec?

KubeSec funciona basado en los Archivos de Manifiesto de Kubernetes que usas para desplegar los diferentes recursos, por lo que necesitas proporcionar el archivo YAML a una de las formas de ejecución que esta herramienta soporta. Este es un tema importante, «una de las formas de ejecución», porque KubeSec soporta muchos modos de ejecución diferentes que nos ayudan a cubrir otros casos de uso.

Puedes ejecutar KubeSec en los siguientes modos:

  • Modo HTTP: KubeSec estará escuchando solicitudes HTTP con el contenido del YAML y proporcionará un informe basado en eso. Esto es útil en casos que necesitan ejecución en modo servidor, como las canalizaciones CICD, o simplemente servidores de seguridad para ser utilizados por algunos equipos, como DevOps o Ingeniería de Plataforma. Además, otro caso de uso crítico de este modo es ser parte de un Controlador de Admisión de Kubernetes en tu Clúster de Kubernetes para que puedas hacer cumplir esto cuando los desarrolladores estén desplegando recursos en la plataforma misma.
  • Modo SaaS: Similar al modo HTTP pero sin necesidad de alojarlo tú mismo, todo disponible detrás de kubesec.io cuando el modo SaaS es de tu preferencia, y no estás manejando información sensible en esos componentes.
  • Modo CLI: Solo para ejecutarlo tú mismo como parte de tus pruebas locales, tendrás disponible otro comando CLI aquí: kubesec scan k8s-deployment.yaml
  • Modo Docker: Similar al modo CLI pero como parte de una imagen de docker, también puede ser compatible con las canalizaciones CICD basadas en cargas de trabajo contenedorizadas.

Informe de Salida de KubeScan

Lo que obtendrás de la ejecución de KubeScan en cualquiera de sus formas es un informe JSON que puedes usar para mejorar y calificar el nivel de seguridad de tus recursos de Kubernetes y algunas formas de mejorarlo. La razón detrás de usar JSON como salida también simplifica el uso de la herramienta en cargas de trabajo automatizadas como las canalizaciones CICD. Aquí puedes ver un ejemplo del informe de salida que obtendrás:

kubesec sample output

Lo importante sobre la salida es el tipo de información que recibirás de ella. Como puedes ver en la imagen de arriba, está separada en dos secciones diferentes por objeto. La primera es el «puntaje», que son las cosas implementadas relacionadas con la seguridad que proporcionan algún puntaje para la seguridad del objeto. Pero también tendrás una sección de consejos que proporciona algunas cosas y configuraciones que puedes hacer para mejorar ese puntaje, y debido a eso, también la seguridad global del objeto de Kubernetes en sí.

Kubescan también aprovecha otra herramienta que hemos comentado no hace mucho en este sitio, Kubeconform, por lo que también puedes especificar la versión de Kubernetes objetivo a la que estás apuntando para tener un informe mucho más preciso de tu Manifiesto de Kubernetes específico. Para hacer eso, puedes especificar el argumento --kubernetes-version cuando estés lanzando el comando, como puedes ver en la imagen a continuación:

kubesec command with kubernetes-version option

 ¿Cómo Instalar KubeScan?

La instalación también proporciona diferentes formas y sabores para ver qué es lo mejor para ti. Aquí hay algunas de las opciones disponibles en el momento de escribir este artículo:

Conclusión

Enfatizando la importancia primordial de la seguridad en las arquitecturas intrincadas de hoy en día, KubeSec emerge como un activo vital para fortalecer la protección de los clústeres de Kubernetes. Desarrollada por ControlPlane, esta herramienta de código abierto facilita evaluaciones de riesgo de seguridad exhaustivas de los recursos de Kubernetes. Ofreciendo versatilidad a través de múltiples modos operativos—como HTTP, SaaS, CLI y Docker—KubeSec proporciona soporte adaptado para diversos escenarios. Su salida basada en JSON simplifica la integración en flujos de trabajo automatizados, mientras que su sinergia con Kubeconform asegura un análisis preciso de los Manifiestos de Kubernetes. El enfoque amigable de KubeSec empodera tanto a expertos en seguridad como a novatos, catalizando un estándar elevado de seguridad en Kubernetes en todos los ámbitos.

📚 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.

Cómo habilitar SwaggerUI TIBCO BusinessWorks al descargar el certificado SSL

Cómo habilitar SwaggerUI TIBCO BusinessWorks al descargar el certificado SSL

SwaggerUI TIBCO BusinessWorks es una de las características disponibles por defecto para todos los servicios REST de TIBCO BusinessWorks desarrollados. Como probablemente sepas, SwaggerUI es solo una página HTML con una representación gráfica del archivo de definición de Swagger (o especificación OpenAPI para ser más precisos con la versión actual de los estándares en uso) que ayuda a entender la operación y capacidades expuestas por el servicio y también proporciona una manera fácil de probar el servicio como puedes ver en la imagen a continuación:

Cómo habilitar SwaggerUI TIBCO BusinessWorks al descargar el certificado SSL: vista de SwaggerUI desde la aplicación TIBCO BWCE

Esta interfaz se proporciona de manera predeterminada para cualquier servicio REST desarrollado usando TIBCO BusinessWorks que utiliza un puerto diferente (7777 por defecto) en caso de que estemos hablando de una implementación local o en el endpoint /swagger en caso de que estemos hablando de una edición de contenedor de TIBCO BusinessWorks.

¿Cómo funciona SwaggerUI para cargar la especificación de Swagger?

SwaggerUI funciona de una manera particular. Cuando llegas a la URL de SwaggerUI, hay otra URL que generalmente es parte de un campo de texto dentro de la página web que contiene el enlace al documento JSON o YAML que almacena la especificación real, como puedes ver en la imagen a continuación:

Cómo habilitar SwaggerUI TIBCO BusinessWorks al descargar el certificado SSL: SwaggerUI destacando las 2 URL cargadas en el proceso

Entonces, puedes pensar que este es un proceso de 2 llamadas:

  • La primera llamada carga SwaggerUI como un contenedor gráfico
  • Luego, basado en la URL interna proporcionada allí, realiza una segunda llamada para recuperar la especificación del documento
  • Y con esa información, renderiza la información en el formato de SwaggerUI.

El problema surge cuando SwaggerUI se expone detrás de un balanceador de carga porque la segunda URL necesita usar la URL anunciada ya que el servidor backend no es alcanzado directamente por el cliente que navega por SwaggerUI. Esto se resuelve de manera predeterminada con las capacidades de Kubernetes en el caso de TIBCO BWCE, y para la implementación local, ofrece dos propiedades para manejar eso de la siguiente manera:

# ------------------------------------------------------------------------------
# Sección: Configuración de Swagger REST de BW. Las propiedades en esta sección
# son aplicables al marco de Swagger que es utilizado por el enlace REST de BW.
#
# Nota: Hay propiedades adicionales de configuración de Swagger REST de BW que
# se pueden especificar en el archivo de configuración de BW AppNode "config.ini". Consulta
# la sección "Configuración de Swagger REST de BW" del archivo de configuración de BW AppNode
# para más detalles.
# ------------------------------------------------------------------------------
# Nombre de host del proxy inverso del marco de Swagger. Esta propiedad es opcional y
# especifica el nombre de host del proxy inverso en el que el marco de Swagger sirve
# los API's, el endpoint de documentación, api-docs, etc.
bw.rest.docApi.reverseProxy.hostName=localhost

# Puerto del marco de Swagger. Esta propiedad es opcional y especifica el
# puerto del proxy inverso en el que el marco de Swagger sirve los API's, el endpoint de documentación,
# api-docs, etc.
bw.rest.docApi.reverseProxy.port=0000

Puedes navegar por la página de documentación oficial para obtener información más detallada.

Eso resuelve el problema principal con respecto al nombre de host y el puerto que debe ser alcanzado como lo requiere el usuario final. Aún así, hay un componente pendiente en la URL que podría generar un problema, y ese es el protocolo, así que, en resumen, si esto se expone usando HTTP o HTTPS.

¿Cómo manejar la URL de Swagger al descargar SSL?

Hasta el lanzamiento de TIBCO BWCE 2.8.3, el protocolo dependía de la configuración del conector HTTP que usabas para exponer el componente swagger. Entonces, si usas un conector HTTP sin configuración SSL, intentará alcanzar el endpoint usando una conexión HTTP. En el otro caso, si usas un conector HTTP con una conexión SSL, intentará usar una conexión HTTPS. Eso parece bien, pero algunos casos de uso podrían generar un problema:

Certificado SSL descargado en el balanceador de carga: Si descargamos la configuración SSL en el balanceador de carga como se usa en implementaciones tradicionales locales y algunas de las configuraciones de Kubernetes, el consumidor establecerá una conexión HTTPS con el balanceador de carga, pero internamente la comunicación con el BWCE se realizará usando HTTP, por lo que, en este caso, generará una discrepancia, porque en la segunda llamada de las solicitudes adivinará que como el conector HTTP de BWCE no está usando HTTPS, la URL debería ser alcanzada usando HTTP pero ese no es el caso ya que la comunicación pasa por el balanceador de carga que maneja la seguridad.

Exposición de servicio de malla de servicios: Similar al caso anterior, pero en ese caso, cerca de la implementación de Kubernetes. Supongamos que estamos usando malla de servicios como Istio u otros. En ese caso, la seguridad es una de las cosas que necesita ser manejada. Por lo tanto, la situación es la misma que el escenario anterior porque el BWCE no conoce la configuración de seguridad pero está impactando el endpoint predeterminado generado.

¿Cómo habilitar SwaggerUI TIBCO BusinessWorks al descargar certificados SSL?

Desde BWCE 2.8.3, hay una nueva propiedad JVM que podemos usar para forzar que el endpoint generado sea HTTPS incluso si el conector HTTP utilizado por la aplicación BWCE no tiene ninguna configuración de seguridad que nos ayude a resolver este problema en los casos anteriores y en un escenario similar. La propiedad se puede agregar como cualquier otra propiedad JVM usando la propiedad de entorno BW_JAVA_OPTS, y el valor es este: bw.rest.enable.secure.swagger.url =true

Aumentar los registros HTTP en TIBCO BusinessWorks en 5 minutos

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.

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

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.