Problemas con los Ingress en Kubernetes: limitaciones reales y por qué Gateway API es el futuro

Problemas con los Ingress en Kubernetes: limitaciones reales y por qué Gateway API es el futuro

Introducción

Los Ingress han sido, desde las primeras versiones de Kubernetes, la forma más habitual de exponer aplicaciones al exterior. Aunque su diseño inicial era sencillo y elegante, el éxito de Kubernetes y la creciente complejidad de los casos de uso han convertido al Ingress en una pieza problemática: limitado, inconsistente entre vendors y difícil de gobernar en entornos empresariales.

En este artículo analizamos por qué los Ingress se han convertido en una fuente constante de fricción, cómo han influido los distintos Ingress Controllers en esta situación y por qué cada vez más organizaciones están considerando alternativas como Gateway API.

Qué son los Ingress y por qué fueron diseñados así

El ecosistema de Ingress gira en torno a dos recursos principales:

🏷️ IngressClass

Define qué controlador gestionará los Ingress asociados. Su alcance es global al clúster, por lo que suele ser administrado por el equipo de plataforma.

🌐 Ingress

Es el recurso que los desarrolladores usan para exponer un servicio. Permite definir rutas, dominios, certificados TLS y poco más.

Su especificación es mínima por diseño, lo que permitió una adopción rápida, pero también sembró las bases de los problemas actuales.

El problema: un estándar demasiado simple para necesidades complejas

A medida que Kubernetes se convirtió en estándar empresarial, los usuarios querían replicar configuraciones avanzadas de proxies tradicionales: re-escrituras, timeouts, cabeceras personalizadas, CORS, etc.
Pero Ingress no daba soporte nativo a todo esto.

Los vendors reaccionaron… y ahí nació el caos.

Anotaciones vs CRDs: dos caminos incompatibles

Los distintos Ingress Controllers han tomado caminos muy diferentes para añadir capacidades avanzadas:

📝 Anotaciones (NGINX, HAProxy…)

Ventajas:

  • Flexibles y fáciles de usar
  • Directamente en el recurso Ingress

Desventajas:

  • Cientos de anotaciones propietarias
  • Documentación fragmentada
  • Configuraciones no portables entre vendors

📦 CRDs personalizados (Traefik, Kong…)

Ventajas:

  • Más estructurado y potente
  • Mejor validación y control

Desventajas:

  • Añade nuevos objetos no estándar
  • Requiere instalarlos y gestionarlos
  • Menor interoperabilidad

¿Resultado?
Infraestructuras profundamente acopladas a un vendor, lo que complica migraciones, auditorías y automatización.

La complejidad para los equipos de desarrollo

El diseño de Ingress implica dos responsabilidades muy diferenciadas:

  • Plataforma: define IngressClass
  • Aplicación: define Ingress

Pero la realidad es que el desarrollador acaba tomando decisiones que deberían ser responsabilidad del área de plataforma:

  • Certificados
  • Políticas de seguridad
  • Reglas de reescritura
  • CORS
  • Timeouts
  • Prácticas corporativas de naming

Esto provoca:

  • Configuraciones inconsistentes
  • Cuellos de botella en revisiones
  • Dependencia constante entre equipos
  • Falta de estandarización efectiva

En empresas grandes, donde la seguridad y la gobernanza son críticas, esto es especialmente problemático.

NGINX Ingress: la descomisión que reavivó el debate

La reciente descontinuación del NGINX Ingress Controller ha puesto en evidencia lo frágil del ecosistema:

  • Miles de clústeres dependen de él
  • Múltiples proyectos usan sus anotaciones
  • Migrar implica reescribir configuraciones enteras

Esto ha reactivado la conversación sobre la necesidad de un estándar real… y ahí aparece Gateway API.

Gateway API: una alternativa prometedora (pero no perfecta)

Gateway API nace para resolver muchas de las limitaciones de Ingress:

  • Separación clara entre responsabilidades (infraestructura vs aplicación)
  • Extensibilidad estandarizada
  • Más tipos de rutas (HTTPRoute, TCPRoute…)
  • Mayor expresividad sin depender de anotaciones propietarias

Pero también trae desafíos:

  • Requiere adopción gradual
  • No todos los vendors implementan lo mismo
  • La migración no es trivial

Aun así, se perfila como el futuro de la gestión de tráfico en Kubernetes.

Conclusión

Los Ingress han sido fundamentales para el éxito de Kubernetes, pero su propia simplicidad los ha llevado a convertirse en un cuello de botella. La falta de interoperabilidad, las diferencias entre vendors y la compleja gobernanza en entornos empresariales hacen evidente que es momento de adoptar modelos más maduros.

Gateway API no es perfecto, pero avanza en la dirección correcta.
Las organizaciones que quieran estabilidad a futuro deberían empezar a planificar su transición.

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

Ingress vs Routes en OpenShift: Diferencias, Traducción y Cuándo Usar Cada Uno

Ingress vs Routes en OpenShift: Diferencias, Traducción y Cuándo Usar Cada Uno

Introducción: OpenShift, la plataforma de Kubernetes empresarial de Red Hat, tiene su propia forma de exponer servicios a clientes externos mediante Routes. Comprender la relación entre Ingress de Kubernetes y Routes de OpenShift es crucial para arquitectos y SREs que gestionan cargas de trabajo en esta plataforma. En Kubernetes estándar, normalmente se usa un recurso Ingress junto con un controlador de Ingress para enrutar el tráfico externo a los servicios. Sin embargo, OpenShift introdujo el concepto de Route y un router integrado (basado en HAProxy) mucho antes de que existiera Ingress en Kubernetes. Hoy OpenShift admite tanto Routes como objetos Ingress estándar, lo que a veces puede generar confusión sobre cuándo usar cada uno y cómo se relacionan. Este artículo explora cómo OpenShift maneja los recursos Ingress, cómo se traducen en Routes, las limitaciones de este enfoque y ofrece orientación sobre cuándo utilizar Ingress frente a Routes.

Routes de OpenShift: Capacidades Avanzadas del Router HAProxy Las Routes son recursos específicos de OpenShift diseñados para exponer servicios externamente. Son atendidas por el router de OpenShift, un proxy basado en HAProxy que se ejecuta dentro del clúster. Las Routes admiten funciones avanzadas como:

  • Balanceo de carga con backends ponderados para dividir el tráfico.
  • Sesiones persistentes (afinidad de sesión).
  • Varios modos de terminación TLS (edge, passthrough, re‑encrypt).
  • Subdominios comodín.
  • Certificados personalizados y SNI.
  • Enrutamiento basado en rutas. Debido a que las Routes son nativas de OpenShift, el router comprende estas funciones de forma nativa y puede configurarse en consecuencia. Esta integración estrecha permite capacidades de enrutamiento potentes y flexibles adaptadas a entornos de OpenShift.

OpenShift admite los recursos Ingress estándar de Kubernetes. Cuando se crea un Ingress, la plataforma lo traduce internamente en una Route equivalente. Cuando creas un Ingress, OpenShift lo traduce automáticamente en una Route equivalente tras bastidores. Esto significa que puedes usar manifiestos Ingress estándar y OpenShift se encargará de exponer tus servicios externamente creando Routes en consecuencia. Esta traducción automática simplifica la migración y admite casos de uso básicos sin necesidad de manifestos específicos de Route. El comportamiento se puede ajustar con anotaciones compatibles con el router de OpenShift (por ejemplo, route.openshift.io/termination, haproxy.router.openshift.io/balance, etc.).

Sin embargo, usar Ingress para generar Routes tiene limitaciones clave: muchas funciones avanzadas del router de OpenShift, como los backends ponderados y las sesiones persistentes (sticky sessions), requieren anotaciones específicas de Route (route.openshift.io) y no son compatibles a través de la especificación estándar de Ingress. Otros modos de TLS, como passthrough y re‑encrypt, también requieren anotaciones específicas de Route. Los Ingress sin host no crean una Route; las Routes requieren un nombre de host. Los hosts comodín solo son compatibles mediante Routes. Además, algunas anotaciones de Route no tienen equivalentes en Ingress. El soporte de protocolos también es más limitado en Ingress, que solo admite HTTP/HTTPS, mientras que las Routes pueden manejar protocolos no HTTP con TLS de paso.

La elección entre Ingress y Routes depende de tus requisitos: utiliza Ingress si buscas portabilidad entre plataformas Kubernetes, ya tienes manifiestos de Ingress existentes o tu aplicación usa solo enrutamiento HTTP/HTTPS básico. Utiliza Routes si necesitas funciones avanzadas como backends ponderados, sesiones persistentes o múltiples modos de terminación TLS; si tu despliegue es específico de OpenShift y puede aprovechar funciones nativas de la plataforma; si necesitas exponer protocolos no HTTP o usar hosts comodín o anotaciones personalizadas no compatibles con Ingress. Muchas veces, los equipos usan una combinación: Ingress para portabilidad y Routes para funciones avanzadas o específicas de OpenShift.

Conclusión: En OpenShift, los recursos Ingress de Kubernetes se convierten automáticamente en Routes, lo que permite exponer servicios externos con poco esfuerzo. Esto permite a los usuarios aprovechar manifiestos de Kubernetes existentes y mantener la portabilidad. Sin embargo, para escenarios de enrutamiento avanzados y para aprovechar plenamente las potentes funciones del router de OpenShift, se recomienda utilizar Routes directamente. Ambas opciones coexisten sin problemas en OpenShift, lo que te permite elegir la herramienta adecuada según los requisitos de tu aplicación.

Frequently Asked Questions

¿OpenShift crea automáticamente una Route por cada Ingress de Kubernetes?

Sí, OpenShift traduce automáticamente un recurso Ingress de Kubernetes estándar en una Route equivalente. Sin embargo, esto solo ocurre si el Ingress especifica un host. Los Ingress sin host no generarán una Route en la plataforma.

¿Cuándo debo usar Routes nativas en lugar de Ingress en OpenShift?

Debes usar Routes directamente cuando necesites: terminación TLS en modo passthrough o re-encrypt, balanceo de carga con backends ponderados, sesiones persistentes (sticky sessions), hosts comodín, o exponer protocolos no HTTP (como TCP). Estas son funciones avanzadas del router HAProxy de OpenShift.

¿Puedo usar anotaciones de Route en un objeto Ingress?

Algunas anotaciones del router de OpenShift (prefijadas con haproxy.router.openshift.io/ o route.openshift.io/) pueden funcionar si se añaden a un recurso Ingress, ya que este se convertirá en una Route. Sin embargo, no todas las funcionalidades están garantizadas. Para un control total y predecible, se recomienda usar el recurso Route directamente.

¿Es mejor usar Ingress para mantener la portabilidad entre Kubernetes y OpenShift?

Usar Ingress es una buena estrategia para mantener la portabilidad de manifiestos entre distribuciones de Kubernetes estándar y OpenShift, siempre que tus necesidades se limiten a enrutamiento HTTP/HTTPS básico. Si necesitas funciones específicas de OpenShift, deberás usar Routes, lo que reduce la portabilidad pero maximiza las capacidades de la plataforma.

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.

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

Talos Linux: Sistema Operativo Inmutable y Seguro para Kubernetes

Talos Linux: Sistema Operativo Inmutable y Seguro 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. Este SO especializado para Kubernetes representa un cambio de paradigma en la gestión de nodos. 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? Características del SO inmutable para Kubernetes

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, aunque pueden parecer limitantes, refuerzan las mejores prácticas de seguridad en Kubernetes, mejoran significativamente la postura de seguridad y aseguran un entorno operativo predecible y consistente ideal para implementaciones de producción.

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

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

Frequently Asked Questions

¿Puedo usar Talos Linux con cualquier distribución de Kubernetes?

Sí, Talos Linux es compatible con cualquier distribución estándar de Kubernetes, incluyendo Kubernetes vanilla, así como distribuciones como k3s y k0s. Sidero Labs también ofrece Talos Kubernetes, una distribución preconfigurada que combina Talos Linux con componentes de Kubernetes optimizados. La API de Talos (talosctl) gestiona el ciclo de vida del nodo independientemente de la distribución de Kubernetes que ejecutes encima.

¿Cómo soluciono problemas en Talos Linux sin acceso SSH?

Talos Linux proporciona herramientas de diagnóstico a través de su API gRPC y la CLI talosctl. Puedes usar comandos como talosctl logs para ver registros del sistema, talosctl dashboard para métricas en tiempo real, y talosctl support para generar bundles de diagnóstico. Para depuración avanzada, Talos soporta contenedores efímeros de Kubernetes que pueden ejecutarse temporalmente en el nodo para tareas de troubleshooting.

¿Es Talos Linux adecuado para entornos de desarrollo local?

Talos Linux es óptimo para producción pero puede usarse en desarrollo. Para entornos locales, considera usar Talos en máquinas virtuales o mediante Docker/Podman para pruebas. Sin embargo, para desarrollo rápido, distribuciones como Minikube o Kind con SO tradicionales pueden ser más convenientes. Talos brilla en entornos que requieren consistencia entre desarrollo, staging y producción.

¿Qué ventajas tiene Talos Linux sobre Ubuntu para Kubernetes?

Talos Linux ofrece: 1) Seguridad por defecto (sin SSH, arranque seguro, TPM), 2) Inmutabilidad (actualizaciones atómicas y rollback), 3) Minimalismo (menor superficie de ataque y uso de recursos), y 4) Gestión declarativa (API-driven vs. manual). Ubuntu es más flexible pero requiere hardening manual y tiene mayor complejidad operativa para cargas de trabajo Kubernetes puras.

¿Cómo maneja Talos Linux el almacenamiento persistente?

Talos Linux soporta volúmenes persistentes de Kubernetes estándar. Para almacenamiento local, configura Local Persistent Volumes o integra con soluciones como Ceph, Longhorn, o proveedores cloud. El sistema de archivos raíz es inmutable y de solo lectura; el almacenamiento de aplicaciones se gestiona exclusivamente a través de Kubernetes, no directamente en el SO.

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.

Exponiendo Puertos TCP Usando Istio Ingress Gateway

Exponiendo Puertos TCP Usando Istio Ingress Gateway

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

Entendiendo el Contexto

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

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

Pasos para Exponer un Puerto TCP con Istio IngressGateway

1.- Modificar el Servicio Istio IngressGateway:

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

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

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

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

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

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

3.- Crea un Servicio y VirtualService:

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

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

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

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

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

4.- Aplica la Configuración

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

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

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

Casos de Uso Prácticos

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

Conclusión

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

ConfigMap con Valores Opcionales en Kubernetes

ConfigMap con Valores Opcionales en Kubernetes

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

Entendiendo el Problema

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

Haciendo Opcionales los Valores de ConfigMap

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

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

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

En este ejemplo:

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

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

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

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

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

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

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

Aplicación de Ejemplo

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

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

Conclusión

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

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

Soporte de registro de TIBCO BW ECS

Soporte de registro de TIBCO BW ECS

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

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

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

Antecedentes del Registro de TIBCO BW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Cómo Funciona KubeSec?

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

Puedes ejecutar KubeSec en los siguientes modos:

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

Informe de Salida de KubeScan

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

kubesec sample output

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

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

kubesec command with kubernetes-version option

 ¿Cómo Instalar KubeScan?

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

Conclusión

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

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