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

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.

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

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.

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.

Aplicación de Políticas en Kubernetes: Entendiendo la Admisión de Seguridad de Pods (PSA)

Aplicación de Políticas en Kubernetes: Entendiendo la Admisión de Seguridad de Pods (PSA)

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.

Kyverno: Una forma detallada de aplicar políticas estándar y personalizadas

Kyverno: Una forma detallada de aplicar políticas estándar y personalizadas

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.

              Talos: Una distribución de Linux moderna optimizada para Kubernetes

              Talos: Una distribución de Linux moderna optimizada para Kubernetes

              Introducción

              Gestionar un clúster de Kubernetes puede volverse rápidamente abrumador, especialmente cuando tu sistema operativo agrega complejidad innecesaria. Entra Talos Linux: un sistema operativo innovador, optimizado para contenedores e inmutable, diseñado explícitamente para entornos de Kubernetes. Es impulsado por API, completamente seguro y elimina los métodos de gestión tradicionales, incluidos SSH y los gestores de paquetes.

              Talos Linux revoluciona la gestión de nodos simplificando drásticamente las operaciones y mejorando la seguridad. En este análisis profundo, exploraremos por qué Talos está captando atención, su arquitectura central y las implicaciones prácticas para los equipos de Kubernetes.

              ¿Qué es Talos Linux?

              Talos Linux es una distribución de Linux de código abierto especializada, meticulosamente diseñada para ejecutar Kubernetes de manera segura y eficiente. A diferencia de los sistemas operativos de propósito general, Talos descarta todas las características irrelevantes y se enfoca exclusivamente en Kubernetes, asegurando:

              • Diseño Inmutable: Los cambios se manejan a través de actualizaciones atómicas en lugar de intervenciones manuales.
              • Gestión Impulsada por API: Los administradores usan talosctl, una CLI que interactúa de manera segura con los nodos a través de una API gRPC.
              • Seguridad por Defecto: Sin acceso SSH, endurecimiento integral del kernel, integración TPM, cifrado de disco y características de arranque seguro.
              • Mínimo y Predecible: Talos minimiza el uso de recursos y reduce la sobrecarga operativa al eliminar servicios y procesos innecesarios.

              Mantenedores y Respaldo

              Talos es mantenido por Sidero Labs, reconocidos por su experiencia en herramientas de Kubernetes y aprovisionamiento de hardware. La comunidad activa y de código abierto de ingenieros nativos de la nube y SREs contribuye continuamente a su crecimiento y evolución.

              Análisis Profundo de la Arquitectura de Talos

              Talos Linux emplea un diseño radical que prioriza la seguridad, la simplicidad y el rendimiento:

              • Interacción Solo por API: No hay acceso tradicional a la shell, eliminando muchas vulnerabilidades comunes asociadas con SSH.
              • Actualizaciones Atómicas: Las actualizaciones del sistema son atómicas: las nuevas versiones arrancan directamente en un estado estable y validado.
              • Eficiencia de Recursos: El diseño simplificado de Talos reduce significativamente su huella, asegurando una utilización óptima de recursos y tiempos de inicio más rápidos.
              • Medidas de Seguridad Mejoradas: Incorpora protecciones a nivel de kernel, arranque seguro, cifrado de disco y seguridad basada en TPM, alineándose con requisitos de cumplimiento estrictos.

              Distribución de Kubernetes basada en Talos Linux

              Sidero Labs también ofrece una distribución completa de Kubernetes construida directamente sobre Talos Linux, conocida como «Talos Kubernetes». Esta distribución simplificada combina los beneficios de Talos Linux con componentes de Kubernetes preconfigurados, facilitando y acelerando el despliegue de clústeres de Kubernetes altamente seguros y listos para producción. Esto simplifica aún más la gestión de clústeres al reducir la sobrecarga y la complejidad típicamente asociadas con la instalación y el mantenimiento de Kubernetes por separado.

              Casos de Uso en el Mundo Real

              Talos brilla particularmente bien en escenarios que demandan mayor seguridad, predictibilidad y operaciones simplificadas:

              • Clústeres Conscientes de la Seguridad: Las arquitecturas de confianza cero se benefician enormemente del modelo inmutable y de acceso restringido de Talos.
              • Computación en el Borde e IoT: Su consumo mínimo de recursos y su gestión robusta a través de API lo hacen ideal para implementaciones en el borde, donde la gestión remota es esencial.
              • Pipelines de CI/CD y GitOps: La configuración declarativa, compatible con metodologías YAML y GitOps, permite entornos de Kubernetes automatizados y reproducibles.

              Cómo Descargar y Probar Talos Linux

              Talos Linux es fácil de probar y evaluar. Puedes descargarlo directamente desde los lanzamientos oficiales de Talos en GitHub. Sidero Labs proporciona documentación completa y guías de inicio rápido para desplegar Talos Linux en varias plataformas, incluidos servidores bare-metal, máquinas virtuales y entornos en la nube como AWS, Azure y GCP. Para una prueba rápida, ejecutarlo dentro de una máquina virtual local o contenedor es una opción conveniente.

              Talos Comparado con Opciones de SO Tradicionales

              Talos presenta ventajas distintas en comparación con opciones más familiares como Ubuntu, CoreOS o Flatcar:

              Característica Talos Ubuntu Flatcar
              Acceso SSH
              Gestor de Paquetes ✅ (apt) ✅ (rpm)
              Nativo de Kubernetes ✅ Incorporado ✅ (a través de herramientas)
              Seguridad por Defecto 🔒 Alta Moderada Alta
              SO Inmutable
              Eficiencia de Recursos ✅ Alta Moderada Alta
              Gestión Impulsada por API Limitada

              Lo que No Puedes Hacer con Talos Linux

              El diseño especializado de Talos Linux restringe intencionalmente ciertas funcionalidades tradicionales del sistema operativo. Notablemente:

              • Sin Acceso SSH: El acceso directo a la shell de los nodos está deshabilitado. Todas las interacciones deben ocurrir a través de talosctl.
              • Sin Gestores de Paquetes: Las herramientas tradicionales como apt, yum o similares están ausentes; los cambios se realizan a través de actualizaciones inmutables.
              • Sin Aplicaciones Adicionales: No admite la ejecución de servicios o cargas de trabajo adicionales, no relacionados con Kubernetes, directamente en los nodos de Talos.

              Estas restricciones refuerzan las mejores prácticas, mejoran significativamente la seguridad y aseguran un entorno operativo predecible y consistente.

              Conclusión

              Talos Linux representa un cambio sustancial en la gestión de nodos de Kubernetes: seguro, ligero y completamente enfocado en Kubernetes. Para las organizaciones que priorizan la seguridad, el cumplimiento, la simplicidad operativa y la eficiencia, Talos proporciona una base robusta y preparada para el futuro.

              Si tu estrategia de Kubernetes valora el minimalismo, la seguridad y la simplicidad, Talos Linux ofrece razones convincentes para considerar su adopción.

              Referencias
              Documentación de Talos
              Sidero Labs
              Repositorio de Talos en GitHub

              Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una

              Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una

              Introducción
              OpenShift, la plataforma de Kubernetes de Red Hat, tiene su propia forma de exponer servicios a clientes externos. En Kubernetes estándar, normalmente usarías un recurso de Ingreso junto con un controlador de ingreso para enrutar el tráfico externo a los servicios. Sin embargo, OpenShift introdujo el concepto de un Ruta y un Enrutador integrado (construido sobre HAProxy) desde el principio, antes de que el Ingreso de Kubernetes siquiera existiera. Hoy en día, OpenShift admite tanto Rutas como objetos de Ingreso estándar, lo que a veces puede llevar a confusión sobre cuándo usar cada uno y cómo se relacionan.

              Este artículo explora cómo OpenShift maneja los recursos de Ingreso de Kubernetes, cómo se traducen en Rutas, las limitaciones de este enfoque y orientación sobre cuándo usar Ingreso versus Rutas.

              Rutas de OpenShift y el Enrutador: Una Visión Rápida


              Las Rutas de OpenShift son recursos específicos de OpenShift diseñados para exponer servicios externamente. Son servidas por el Enrutador de OpenShift, que es un proxy basado en HAProxy que se ejecuta dentro del clúster. Las Rutas admiten características avanzadas como:

              • Backends ponderados para división de tráfico
              • Sesiones persistentes (afinidad de sesión)
              • Múltiples modos de terminación TLS (borde, paso a través, re-encriptar)
              • Subdominios comodín
              • Certificados personalizados y SNI
              • Enrutamiento basado en rutas

              Debido a que las Rutas son nativas de OpenShift, el Enrutador entiende estas características de manera nativa y puede configurarse en consecuencia. Esta integración estrecha permite capacidades de enrutamiento poderosas y flexibles adaptadas a los entornos de OpenShift.

              Uso de Ingreso de Kubernetes en OpenShift (Comportamiento Predeterminado)


              A partir de OpenShift Container Platform (OCP) 3.10, se admiten los recursos de Ingreso de Kubernetes. Cuando creas un Ingreso, OpenShift lo traduce automáticamente en una Ruta equivalente detrás de escena. Esto significa que puedes usar manifiestos estándar de Ingreso de Kubernetes, y OpenShift se encargará de exponer tus servicios externamente creando Rutas en consecuencia.

              Ejemplo: Ingreso de Kubernetes y Ruta Resultante

              Aquí hay un manifiesto de Ingreso simple:

              apiVersion: networking.k8s.io/v1
              kind: Ingress
              metadata:
                name: example-ingress
                annotations:
                  nginx.ingress.kubernetes.io/rewrite-target: /
              spec:
                rules:
                - host: www.example.com
                  http:
                    paths:
                    - path: /testpath
                      pathType: Prefix
                      backend:
                        service:
                          name: test-service
                          port:
                            number: 80
              

              OpenShift creará una Ruta similar a:

              apiVersion: route.openshift.io/v1
              kind: Route
              metadata:
                name: example-route
              spec:
                host: www.example.com
                path: /testpath
                to:
                  kind: Service
                  name: test-service
                  weight: 100
                port:
                  targetPort: 80
                tls:
                  termination: edge
              

              Esta traducción automática simplifica la migración y admite casos de uso básicos sin requerir manifiestos específicos de Ruta.

              Ajuste del Comportamiento con Anotaciones (Ingreso ➝ Ruta)

              Cuando usas Ingreso en OpenShift, solo se respetan las anotaciones conscientes de OpenShift durante la traducción de Ingreso ➝ Ruta. Las anotaciones específicas del controlador para otros controladores de ingreso (por ejemplo, nginx.ingress.kubernetes.io/*) son ignoradas por el Enrutador de OpenShift. Las siguientes anotaciones son comúnmente usadas y admitidas por el enrutador de OpenShift para ajustar la Ruta generada:

              Propósito Anotación Valores Típicos Efecto en la Ruta Generada
              Terminación TLS route.openshift.io/termination edge · reencrypt · passthrough Establece spec.tls.termination de la Ruta al modo elegido.
              Redirección HTTP→HTTPS (borde) route.openshift.io/insecureEdgeTerminationPolicy Redirect · Allow · None Controla spec.tls.insecureEdgeTerminationPolicy (comúnmente Redirect).
              Balanceo de carga del backend haproxy.router.openshift.io/balance roundrobin · leastconn · source Establece el algoritmo de balanceo de HAProxy para la Ruta.
              Timeout por ruta haproxy.router.openshift.io/timeout duración como 60s, 5m Configura el timeout de HAProxy para solicitudes en esa Ruta.
              Cabecera HSTS haproxy.router.openshift.io/hsts_header por ejemplo, max-age=31536000;includeSubDomains;preload Inyecta la cabecera HSTS en las respuestas (borde/re-encriptar).

              Nota: Las características avanzadas como backends ponderados/canario o hosts comodín no son expresables a través de Ingreso estándar. Usa una Ruta directamente para esos casos.

              Ejemplo: Ingreso con anotaciones del enrutador de OpenShift

              apiVersion: networking.k8s.io/v1
              kind: Ingress
              metadata:
                name: example-ingress-https
                annotations:
                  route.openshift.io/termination: edge
                  route.openshift.io/insecureEdgeTerminationPolicy: Redirect
                  haproxy.router.openshift.io/balance: leastconn
                  haproxy.router.openshift.io/timeout: 60s
                  haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload
              spec:
                rules:
                - host: www.example.com
                  http:
                    paths:
                    - path: /
                      pathType: Prefix
                      backend:
                        service:
                          name: test-service
                          port:
                            number: 80
              

              Este Ingreso se realizará como una Ruta con TLS de borde y una redirección automática de HTTP→HTTPS, usando balanceo de menos conexiones y un timeout de ruta de 60s. La cabecera HSTS será añadida por el enrutador en las respuestas HTTPS.

              Limitaciones de Usar Ingreso para Generar Rutas
              Aunque conveniente, usar Ingreso para generar Rutas tiene limitaciones:

              • Falta de características avanzadas: Los backends ponderados y las sesiones persistentes requieren anotaciones específicas de Ruta y no son compatibles a través de Ingreso.
              • Modos de paso a través y re-encriptar TLS: Estos requieren anotaciones específicas de OpenShift en las Rutas y no son compatibles a través de Ingreso estándar.
              • Ingreso sin host: Un Ingreso sin un nombre de host no creará una Ruta; las Rutas requieren un host.
              • Hosts comodín: Los hosts comodín (por ejemplo, *.example.com) solo son compatibles a través de Rutas, no Ingreso.
              • Compatibilidad de anotaciones: Algunas anotaciones de Ruta de OpenShift no tienen equivalentes en Ingreso, lo que lleva a brechas de configuración.
              • Soporte de protocolo: Ingreso solo admite protocolos HTTP/HTTPS, mientras que las Rutas pueden manejar protocolos no HTTP con TLS de paso a través.
              • Riesgo de deriva de configuración: Debido a que las Rutas creadas a partir de Ingreso son gestionadas por OpenShift, las ediciones manuales a la Ruta generada pueden ser sobrescritas o causar inconsistencias.

              Estas limitaciones significan que para configuraciones de enrutamiento avanzadas o características específicas de OpenShift, es preferible usar Rutas directamente.

              Cuándo Usar Ingreso vs. Cuándo Usar Rutas
              Elegir entre Ingreso y Rutas depende de tus requisitos:

              • Usa Ingreso si:
              • Quieres portabilidad entre plataformas de Kubernetes.
              • Tienes manifiestos de Ingreso existentes y quieres minimizar los cambios.
              • Tu aplicación usa solo enrutamiento básico HTTP o HTTPS.
              • Prefieres manifiestos neutrales a la plataforma para pipelines de CI/CD.
              • Usa Rutas si:
              • Necesitas características avanzadas de enrutamiento como backends ponderados, sesiones persistentes o múltiples modos de terminación TLS.
              • Tu implementación es específica de OpenShift y puede aprovechar las características nativas de OpenShift.
              • Requieres estabilidad y soporte completo para las capacidades de enrutamiento de OpenShift.
              • Necesitas exponer protocolos no HTTP o usar modos de paso a través/re-encriptar TLS.
              • Quieres usar hosts comodín o anotaciones personalizadas no compatibles con Ingreso.

              En muchos casos, los equipos usan una combinación: Ingreso para portabilidad y Rutas para necesidades avanzadas o específicas de OpenShift.

              Conclusión


              En OpenShift, los recursos de Ingreso de Kubernetes se convierten automáticamente en Rutas, permitiendo la exposición básica de servicios externos con un esfuerzo mínimo. Esto permite a los usuarios aprovechar los manifiestos existentes de Kubernetes y mantener la portabilidad. Sin embargo, para escenarios de enrutamiento avanzados y para utilizar completamente las potentes características del Enrutador de OpenShift, se recomienda usar Rutas directamente.

              Ambos, Ingreso y Rutas, coexisten sin problemas en OpenShift, permitiéndote elegir la herramienta adecuada para los requisitos de tu aplicación.