Extender políticas de Kyverno: cómo crear reglas personalizadas para reforzar la seguridad en Kubernetes

Extender políticas de Kyverno: cómo crear reglas personalizadas para reforzar la seguridad en Kubernetes

Kyverno ofrece un enfoque robusto y declarativo para hacer cumplir los estándares de seguridad y cumplimiento dentro de los clústeres de Kubernetes al permitir a los usuarios definir y hacer cumplir políticas personalizadas. Para una mirada en profundidad a la funcionalidad de Kyverno, incluidos los conceptos y beneficios principales, vea mi artículo detallado aquí. En esta guía, nos centraremos en extender las políticas de Kyverno, proporcionando un recorrido estructurado de su modelo de datos e ilustrando casos de uso para aprovechar al máximo Kyverno en un entorno de Kubernetes.

Comprendiendo el Modelo de Datos de Políticas de Kyverno

Las políticas de Kyverno consisten en varios componentes que definen cómo debe comportarse la política, qué recursos debe afectar y las reglas específicas que se aplican. Vamos a profundizar en las partes principales del modelo de políticas de Kyverno:

  1. Definición de Política: Esta es la configuración raíz donde defines los metadatos de la política, incluyendo nombre, tipo y alcance. Las políticas pueden crearse a nivel de espacio de nombres para áreas específicas o como reglas a nivel de clúster para hacer cumplir estándares uniformes en todo el clúster de Kubernetes.
  2. Reglas: Las políticas están compuestas por reglas que dictan qué condiciones debe hacer cumplir Kyverno. Cada regla puede incluir lógica para validación, mutación o generación según tus necesidades.
  3. Bloques de Coincidencia y Exclusión: Estas secciones permiten un control detallado sobre qué recursos se aplica la política. Puedes especificar recursos por sus tipos (por ejemplo, Pods, Despliegues), espacios de nombres, etiquetas e incluso nombres específicos. Esta flexibilidad es crucial para crear políticas dirigidas que impacten solo en los recursos que deseas gestionar.
    1. Bloque de coincidencia: Define las condiciones bajo las cuales la regla se aplica a recursos específicos.
    2. Bloque de exclusión: Se utiliza para omitir explícitamente recursos que coinciden con ciertas condiciones, asegurando que los recursos no afectados no se incluyan inadvertidamente.
  4. Acciones de Validación, Mutación y Generación: Cada regla puede tomar diferentes tipos de acciones:
    1. Validación: Asegura que los recursos cumplan con criterios específicos y bloquea el despliegue si no lo hacen.
    2. Mutación: Ajusta las configuraciones de recursos para alinearse con estándares predefinidos, lo cual es útil para la autorremediación.
    3. Generación: Crea o gestiona recursos adicionales basados en configuraciones de recursos existentes.

Ejemplo: Restringir Fuentes de Imágenes de Contenedores a Docker Hub

Un requisito común de seguridad es limitar las imágenes de contenedores a registros de confianza. El ejemplo a continuación demuestra una política que solo permite imágenes de Docker Hub.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-dockerhub-images
spec:
  rules:
    - name: only-dockerhub-images
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Solo se permiten imágenes de Docker Hub."
        pattern:
          spec:
            containers:
              - image: "docker.io/*"

Esta política apunta a todos los recursos Pod en el clúster y hace cumplir una regla de validación que restringe la fuente de la imagen a docker.io. Si un Pod utiliza una imagen fuera de Docker Hub, Kyverno niega su despliegue, reforzando prácticas de aprovisionamiento seguro.

Casos de Uso Prácticos para Políticas de Kyverno

Las políticas de Kyverno pueden manejar una variedad de tareas de gestión de Kubernetes a través de validación, mutación y generación. Vamos a explorar ejemplos para cada tipo para ilustrar la versatilidad de Kyverno:

1. Políticas de Validación

Las políticas de validación en Kyverno aseguran que los recursos cumplan con configuraciones específicas o estándares de seguridad, deteniendo cualquier recurso no conforme de desplegarse.

Caso de Uso: Hacer Cumplir Límites de Recursos para Contenedores

Este ejemplo previene despliegues que carecen de límites de recursos, asegurando que todos los Pods especifiquen restricciones de CPU y memoria.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-resource-limits
spec:
  rules:
    - name: require-resource-limits
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Se requieren límites de recursos (CPU y memoria) para todos los contenedores."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

Al hacer cumplir los límites de recursos, esta política ayuda a prevenir la contención de recursos en el clúster, fomentando un rendimiento estable y predecible.

2. Políticas de Mutación

Las políticas de mutación permiten a Kyverno ajustar automáticamente configuraciones en recursos para cumplir con requisitos de cumplimiento. Este enfoque es beneficioso para configuraciones consistentes sin intervención manual.

Caso de Uso: Agregar Etiquetas Predeterminadas a Pods

Esta política agrega una etiqueta predeterminada, environment: production, a todos los nuevos Pods que carecen de esta etiqueta, asegurando que los recursos se alineen con los estándares de etiquetado de toda la organización.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-label
spec:
  rules:
    - name: add-environment-label
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              environment: "production"

Esta política de mutación es un ejemplo de cómo Kyverno puede estandarizar configuraciones de recursos a escala al agregar dinámicamente información faltante, reduciendo el error humano y asegurando la consistencia en el etiquetado.

3. Políticas de Generación

Las políticas de generación en Kyverno se utilizan para crear o actualizar recursos relacionados, mejorando la automatización de Kubernetes al responder a configuraciones o necesidades específicas en tiempo real.

Caso de Uso: Creación Automática de un ConfigMap para Cada Nuevo Espacio de Nombres

Este ejemplo de política genera un ConfigMap en cada nuevo espacio de nombres, estableciendo valores de configuración predeterminados para todos los recursos en ese espacio de nombres.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-configmap
spec:
  rules:
    - name: add-default-configmap
      match:
        resources:
          kinds:
            - Namespace
      generate:
        kind: ConfigMap
        name: default-config
        namespace: "{{request.object.metadata.name}}"
        data:
          default-key: "default-value"

Esta política de generación se activa cada vez que se crea un nuevo espacio de nombres, aprovisionando automáticamente un ConfigMap con configuraciones predeterminadas. Este enfoque es especialmente útil en entornos multi-tenant, asegurando que los nuevos espacios de nombres tengan configuraciones esenciales en su lugar.

Conclusión

Extender las políticas de Kyverno permite a los administradores de Kubernetes establecer y hacer cumplir prácticas de seguridad y operativas personalizadas dentro de sus clústeres. Al aprovechar las capacidades de Kyverno en validación, mutación y generación, puedes automatizar el cumplimiento, agilizar las operaciones y reforzar los estándares de seguridad sin problemas.

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

Kyverno en Kubernetes: aplicar políticas estándar y personalizadas paso a paso (vs PSA)

Kyverno en Kubernetes: aplicar políticas estándar y personalizadas paso a paso (vs PSA)

En el ecosistema de Kubernetes, la seguridad y la gobernanza son aspectos clave que requieren atención continua. Aunque Kubernetes ofrece algunas características de seguridad listas para usar (OOTB) como la Admisión de Seguridad de Pods (PSA), estas pueden no ser suficientes para entornos complejos con requisitos de cumplimiento variables. Aquí es donde Kyverno entra en juego, proporcionando una solución poderosa pero flexible para gestionar y hacer cumplir políticas en todo tu clúster.

En esta publicación, exploraremos las diferencias clave entre Kyverno y PSA, explicaremos cómo se puede usar Kyverno en diferentes casos de uso y te mostraremos cómo instalar y desplegar políticas con él. Aunque la creación de políticas personalizadas se cubrirá en una publicación separada, haremos referencia a algunas políticas preconstruidas que puedes usar de inmediato.

¿Qué es la Admisión de Seguridad de Pods (PSA)?

Kubernetes introdujo Admisión de Seguridad de Pods (PSA) como un reemplazo para la ahora obsoleta Política de Seguridad de Pods (PSP). PSA se centra en hacer cumplir tres niveles de seguridad predefinidos: Privilegiado, Básico y Restringido. Estos niveles controlan qué pods pueden ejecutarse en un espacio de nombres según sus configuraciones de contexto de seguridad.

  • Privilegiado: Restricciones mínimas, permitiendo contenedores privilegiados y acceso al host.
  • Básico: Aplica restricciones estándar, no permitiendo contenedores privilegiados y limitando el acceso al host.
  • Restringido: El nivel más estricto, asegurando configuraciones seguras por defecto y aplicando las mejores prácticas para ejecutar contenedores.

Si bien PSA es efectivo para requisitos de seguridad básicos, carece de flexibilidad al aplicar políticas personalizadas o de grano fino. Tenemos un artículo completo que cubre este tema que puedes leer aquí.

Kyverno vs. PSA: Diferencias Clave

Kyverno va más allá de las capacidades de PSA al ofrecer un control más granular y flexibilidad. Así es como se compara:

  1. Tipos de Políticas: Mientras que PSA se centra únicamente en la seguridad, Kyverno permite la creación de políticas para validación, mutación y generación de recursos. Esto significa que puedes modificar o generar nuevos recursos, no solo aplicar reglas de seguridad.
  2. Personalización: Kyverno admite políticas personalizadas que pueden hacer cumplir los requisitos de cumplimiento de tu organización. Puedes escribir políticas que gobiernen tipos de recursos específicos, como asegurar que todos los despliegues tengan ciertas etiquetas o que las imágenes de los contenedores provengan de un registro de confianza.
  3. Política como Código: Las políticas de Kyverno están escritas en YAML, lo que permite una fácil integración con pipelines de CI/CD y flujos de trabajo de GitOps. Esto hace que la gestión de políticas sea declarativa y controlada por versiones, lo cual no es el caso con PSA.
  4. Auditoría e Informes: Con Kyverno, puedes generar registros de auditoría detallados e informes sobre violaciones de políticas, dando a los administradores una visión clara de cómo se aplican las políticas y dónde ocurren las violaciones. PSA carece de esta capacidad de informes integrada.
  5. Aplicación y Mutación: Mientras que PSA principalmente aplica restricciones en los pods, Kyverno permite no solo la validación de configuraciones sino también la modificación de recursos (mutación) cuando sea necesario. Esto añade una capa adicional de flexibilidad, como agregar automáticamente anotaciones o etiquetas.

Cuándo Usar Kyverno en Lugar de PSA

Si bien PSA podría ser suficiente para entornos más simples, Kyverno se convierte en una herramienta valiosa en escenarios que requieren:

  • Reglas de Cumplimiento Personalizadas: Por ejemplo, hacer cumplir que todos los contenedores usen una imagen base específica o restringir capacidades específicas de contenedores en diferentes entornos.
  • Integraciones CI/CD: Kyverno puede integrarse en tus pipelines de CI/CD, asegurando que los recursos cumplan con las políticas organizacionales antes de ser desplegados.
  • Gobernanza Compleja: Al gestionar grandes clústeres con múltiples equipos, la jerarquía de políticas y el alcance de Kyverno permiten un control más fino sobre quién puede desplegar qué y cómo se configuran los recursos.

Si tu organización necesita una solución de seguridad más robusta y flexible, Kyverno es una mejor opción en comparación con el enfoque más genérico de PSA.

Instalando Kyverno

Para comenzar a usar Kyverno, necesitarás instalarlo en tu clúster de Kubernetes. Este es un proceso sencillo usando Helm, lo que facilita su gestión y actualización.

Instalación Paso a Paso

Agrega el repositorio Helm de Kyverno:

helm repo add kyverno https://kyverno.github.io/kyverno/

Actualiza los repositorios de Helm:

helm repo update

Instala Kyverno en tu clúster de Kubernetes:

helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace

Verifica la instalación:

kubectl get pods -n kyverno

Después de la instalación, Kyverno comenzará a aplicar políticas en todo tu clúster, pero necesitarás desplegar algunas políticas para comenzar.

Desplegando Políticas con Kyverno

Las políticas de Kyverno están escritas en YAML, al igual que los recursos de Kubernetes, lo que las hace fáciles de leer y gestionar. Puedes encontrar varias políticas listas para usar en la Biblioteca de Políticas de Kyverno, o crear las tuyas propias para que se ajusten a tus requisitos.

A continuación, un ejemplo de una política de validación simple que asegura que todos los pods usen imágenes de contenedores de confianza de un registro específico:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-trusted-registry
spec:
  validationFailureAction: enforce
  rules:
  - name: check-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Solo se permiten imágenes de 'myregistry.com'."
      pattern:
        spec:
          containers:
          - image: "myregistry.com/*"

Esta política bloqueará automáticamente el despliegue de cualquier pod que use una imagen de un registro diferente a myregistry.com.

Aplicando la Política

Para aplicar la política anterior, guárdala en un archivo YAML (por ejemplo, trusted-registry-policy.yaml) y ejecuta el siguiente comando:

kubectl apply -f trusted-registry-policy.yaml

Una vez aplicada, Kyverno hará cumplir esta política en todo tu clúster.

Visualizando Informes de Políticas de Kyverno

Kyverno genera informes detallados sobre violaciones de políticas, que son útiles para auditorías y seguimiento del cumplimiento de políticas. Para verificar los informes, puedes usar los siguientes comandos:

Lista todos los informes de políticas de Kyverno:

kubectl get clusterpolicyreport

Describe un informe de política específico para obtener más detalles:

kubectl describe clusterpolicyreport <report-name>

Estos informes pueden integrarse en tus herramientas de monitoreo para activar alertas cuando ocurran violaciones críticas.

Conclusión

Kyverno ofrece una forma flexible y poderosa de hacer cumplir políticas en Kubernetes, convirtiéndose en una herramienta esencial para organizaciones que necesitan más que las capacidades básicas proporcionadas por PSA. Ya sea que necesites asegurar el cumplimiento con estándares de seguridad internos, automatizar modificaciones de recursos o integrar políticas en pipelines de CI/CD, el extenso conjunto de características de Kyverno lo convierte en una opción preferida para la gobernanza de Kubernetes.

Por ahora, comienza con las políticas listas para usar disponibles en la biblioteca de Kyverno. En publicaciones futuras, profundizaremos en la creación de políticas personalizadas adaptadas a tus necesidades específicas.

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

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

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

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

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