Helm 4.0 explicado: novedades clave, cambios importantes y cómo prepararte para la migración

Helm 4.0 explicado: novedades clave, cambios importantes y cómo prepararte para la migración

Helm es uno de las principales utilidades dentro del ecosistema de Kubernetes y por tanto la release de una nueva version major, como es Helm 4.0 es algo a tener en consideración porqué sin dudas es algo que se va a tener que analizar, valorar y gestionar en los próximos meses.

Debido a eso, veremos muchos comentarios y artículos alrededor de este tema, por lo que vamos a intentar mostrar algo de luz.

Principales novedades de Helm 4.0

Según el propio proyecto en su anuncio, Helm 4 introduce tres grandes bloques de cambios: nuevo sistema de plugins, mejor integración con Kubernetes ** y modernización interna de SDK y rendimiento**.

Nuevo sistema de plugins (incluye WebAssembly)

Se ha rediseñado por completo del sistema de plugins, haciendo un enfoque especial en la seguridad mediante la introducción de un nuevo runtime WebAssembly que si bien es opcional, es recomendado dado que se ejecutan en un modo «sandbox» que ofrece limites y garantías desde el punto de vista de la seguridad

De todos modos, no hay que preocuparse en exceso, ya que los plugins “clásicos” siguen funcionando, pero el mensaje es claro: para seguridad y extensibilidad, la dirección es Wasm.

Server-Side Apply y mejor integración con otros controladores

Desde esta versión Helm 4 a través del flag --server-side se soporta Server-Side Apply (SSA) que ya se ha convertido en estable desde la versión v1.22 de Kubernetes y permite llevar al lado del servidor las actualizaciones sobre los objetos para evitar conflictos entre diferentes controladores que gestionan los mismos recursos.

También incorporar integración con kstatus para asegurar el estado de un componente de na una manera más fiable que lo que ocurre actualmente con el uso del parámetro --wait

Otras Mejoras Adicionales

Adicionalmente hay otro listado de mejores que siendo de menor calado son saltos cualitativos de importancia como puede ser los siguiente:

  • Instalación por digest en registries OCI: (helm install myapp oci://...@sha256:<digest>)
  • Valores multi-document: puedes pasar varios YAML de values en un único fichero multi-doc, facilitando entornos / overlays complejos.
  • Nuevo argumento --set-json que permite de una manera sencilla pasar estructuras complejas comparado con la solución actual mediante uso del parámetro --set

¿Por qué una major (v4) y no otra minor de la 3.x?

Tal y como explican en la entrada oficial de lanzamiento había features que el equipo no podía introducir en v3 sin romper APIs públicas del SDK y arquitectura interna:

  • Cambio fuerte en el sistema de plugins (WebAssembly, nuevos tipos, integración profunda con el core).
  • Reestructuración de paquetes Go y establecimiento de un SDK estable en helm.sh/helm/v4, incompatible a nivel de código con v3.
  • Introducción y futura evolución de Charts v3, que requieren que el SDK soporte múltiples versiones de API de charts.

Con todo esto, seguir en la rama 3.x habría violado SemVer: el cambio de número mayor está básicamente “pagando” la deuda técnica acumulada para poder avanzar.

Adicionalmente se espera en el futuro una nueva evolución de las charts, pasando de una v2 a una futura v3 que aun no esta completamente definida y actualmente las charts v2 se ejecutan correctamente en esta nueva versión.

¿Tengo que migrar a esta nueva versión?

La respuesta corta es: si. Y posiblemente la respuesta larga sea: sí, y rápido. En el anuncio oficial de Helm 4 especifican el calendario de soporte de Helm 3:

  • Bugfixes de Helm 3 hasta el 8 de julio de 2026.
  • Security fixes de Helm 3 hasta el 11 de noviembre de 2026.
  • No se backportearán nuevas features a Helm 3 durante ese periodo; únicamente se actualizarán librerías de cliente de Kubernetes para soportar nuevas versiones de K8s.

Traducción práctica:

  • Tienes ~1 año para planificar migración tranquila a Helm 4 con soporte de bugs.
  • Después de noviembre de 2026, seguir usando Helm 3 será cada vez más arriesgado desde el punto de vista de seguridad y compatibilidad.

Buenas prácticas para migración

Para realizar la migración hay que recordar que es perfectamente posible y factible tener instaladas ambas versiones en un misma máquina o agente, por lo que se puede hacer una migración «paulatina» para asegurar que se llega al final del soporte de la versión v3 con todo migrado correctamente, y para eso se recomiendan lo siguientes pasos:

  • Realizar un análisis de todos los comandos y uso de Helm tanto desde el punto de vista de pipelines de integración, scripts de upgrade o incluso la importación de librerías cliente de helm en desarrollos basados en Helm.
  • Especialmente revisar con cautela todos los usos de --post-renderer, helm registry login, --atomic, --force.
  • Posteriormente al análisis empezar a probar Helm 4 primero en entornos no productivos, reutilizando los mismos charts y values, revirtiendo a Helm 3 en caso de que se detecte un problema hasta que este sea sub
  • Si tienes plugins críticos, probarlos explícitamente con Helm 4 antes de hacer el cambio global.

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.

XSLTPlayground.com: la herramienta moderna para probar, optimizar y depurar XSLT en tiempo real

XSLTPlayground.com: la herramienta moderna para probar, optimizar y depurar XSLT en tiempo real

Trabajar con XSLT en flujos de datos modernos y sistemas impulsados por XML siempre ha sido poderoso… pero no siempre fácil. Las herramientas a menudo son pesadas, obsoletas o requieren configuración local y entornos complejos. Por eso estoy emocionado de anunciar el lanzamiento de XSLTPlayground.com, un editor de XSLT gratuito, de código abierto, basado en el navegador y diseñado específicamente para casos de uso del mundo real.

Sin instalaciones. Sin complejidad. Solo abre tu navegador y transforma.

🚀 ¿Por qué XSLT Playground?

🔁 Transformaciones XSLT en Tiempo Real para Escenarios del Mundo Real

A diferencia de las herramientas heredadas o las demostraciones web limitadas, XSLT Playground admite transformaciones complejas que involucran múltiples fuentes XML, plantillas parametrizadas y retroalimentación real. Ya sea que trabajes en integración de datos, puertas de enlace API, informes basados en XML o actualizaciones de sistemas heredados, esta herramienta te ayuda a probar e iterar rápidamente.

🧩 Soporte de Parámetros de Entrada Múltiple

Uno de los mayores puntos de dolor en las pruebas de XSLT es simular entornos reales. Con XSLTPlayground.com, puedes definir múltiples fuentes de entrada (por ejemplo, flujos de datos, configuración o metadatos) y pasarlos a tu XSLT de manera sincronizada, tal como en un flujo de datos de producción.

⚙️ Sincronización Automática de Parámetros

Cuando cargas una hoja de estilo con parámetros requeridos, el Playground los detecta automáticamente y crea campos de entrada para ti en el lateral. Todo lo que necesitas hacer es completar los valores. Esta función inteligente elimina las conjeturas y ayuda a evitar errores en tiempo de ejecución.

⚡ Información sobre Rendimiento y Optimización

¿Necesitas saber si tu optimización está funcionando? Mostramos el tiempo de ejecución para cada transformación, ayudándote a comparar versiones y elegir el enfoque más rápido, todo sin desplegar sistemas completos o instrumentar código. Aunque no es una herramienta de evaluación comparativa, la retroalimentación es invaluable para ajustes en tiempo real.

🌐 100% Gratis, Basado en la Web y de Código Abierto

No necesitas instalar herramientas voluminosas como Oxygen XML o ejecutar complementos de Eclipse solo para probar una hoja de estilo. XSLTPlayground.com es completamente basado en la web, gratuito y construido para ser abierto y extensible. ¿Quieres contribuir o alojar tu propia versión? El código fuente está en GitHub.

🖱️ Soporte de Arrastrar y Soltar

Sube tus archivos XML o XSLT simplemente arrastrándolos al navegador. Todos los componentes — entradas, hojas de estilo, salidas — admiten arrastrar y soltar para una iteración más rápida.

🎨 Opciones de Impresión Bonita y Exportación

Tu salida se imprime automáticamente de manera bonita para facilitar la lectura, y con solo un clic puedes descargar tu XSLT y el resultado de la transformación, lo que facilita compartir, archivar o importar en proyectos más grandes.

🔗 Pruébalo ahora: https://xsltplayground.com

Ya seas un desarrollador, ingeniero de datos o trabajes con sistemas heredados, esta es la herramienta que has estado esperando. Di adiós a la complejidad de configurar pruebas de XSLT y di hola a las transformaciones instantáneas, en cualquier lugar y en cualquier momento.

¿Quieres contribuir o seguir el desarrollo? Dale una estrella al proyecto en GitHub o envía comentarios directamente desde el sitio.

Helm v3.17 y el flag –take-ownership: qué problema resuelve y cuándo deberías usarlo

Helm v3.17 y el flag --take-ownership: qué problema resuelve y cuándo deberías usarlo

Helm ha sido durante mucho tiempo el estándar para gestionar aplicaciones de Kubernetes utilizando gráficos empaquetados, aportando un nivel de reproducibilidad y automatización al proceso de implementación. Sin embargo, algunas tareas operativas, como renombrar una versión o migrar objetos entre gráficos, tradicionalmente han requerido soluciones complicadas. Con la introducción del flag --take-ownership en Helm v3.17 (lanzado en enero de 2025), finalmente se aborda un punto de dolor de larga data, al menos parcialmente.

En esta publicación, exploraremos:

  • Qué hace el flag --take-ownership
  • Por qué era necesario
  • Las advertencias y limitaciones
  • Casos de uso del mundo real donde ayuda
  • Cuándo no usarlo

Entendiendo la Propiedad de Objetos en Helm

Cuando Helm instala o actualiza un gráfico, inyecta metadatos—etiquetas y anotaciones—en cada objeto de Kubernetes gestionado. Estos incluyen:

app.kubernetes.io/managed-by: Helm
meta.helm.sh/release-name: my-release
meta.helm.sh/release-namespace: default

Estos metadatos cumplen un papel importante: Helm los utiliza para rastrear y gestionar recursos asociados con cada versión. Como medida de seguridad, Helm no permite que otra versión modifique objetos que no posee y cuando intentas hacerlo verás mensajes como el siguiente:

Error: Unable to continue with install: Service "provisioner-agent" in namespace "test-my-ns" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "dp-core-infrastructure11": current value is "dp-core-infrastructure"

Si bien esto protege a los usuarios de sobrescrituras accidentales, crea limitaciones para casos de uso avanzados.

Por Qué Se Necesitaba --take-ownership

Supongamos que quieres:

  • Renombrar una versión existente de Helm de api-v1 a api.
  • Mover un ConfigMap o Service de un gráfico a otro.
  • Reconstruir el estado durante la reconciliación de GitOps cuando los metadatos anteriores de Helm se han desviado.

Anteriormente, tu única opción era:

  1. Desinstalar la versión existente.
  2. Reinstalar con el nuevo nombre.

Este enfoque introduce tiempo de inactividad, y en sistemas de producción, eso a menudo no es aceptable.

Qué Hace el Flag

helm upgrade my-release ./my-chart --take-ownership

Cuando se pasa este flag, Helm:

  • Omitirá la validación de propiedad para objetos existentes.
  • Sobrescribirá las etiquetas y anotaciones para asociar el objeto con la versión actual.

En la práctica, esto te permite reclamar la propiedad de recursos que anteriormente pertenecían a otra versión, permitiendo transferencias sin problemas.

⚠️ Lo Que No Hace

Este flag no:

  • Limpia referencias de la versión anterior.
  • Te protege de futuras desinstalaciones de la versión original (que aún podrían eliminar recursos compartidos).
  • Te permite adoptar recursos de Kubernetes completamente no gestionados (aquellos no creados inicialmente por Helm).

En resumen, es un mecanismo para eludir las verificaciones de propiedad de Helm, no un gestor de ciclo de vida completo.

Casos de Uso del Mundo Real

Veamos escenarios comunes donde esta característica es útil.

✅ 1. Renombrar una Versión Sin Tiempo de Inactividad

Antes:

helm uninstall old-name
helm install new-name ./chart

Ahora:

helm upgrade new-name ./chart --take-ownership

✅ 2. Migrar Objetos Entre Gráficos

Estás refactorizando un gráfico grande en otros más pequeños y modulares y necesitas reasignar ciertos objetos Service o Secret.

Este flag permite que la nueva versión tome control del objeto sin eliminarlo o recrearlo.

✅ 3. Reconciliación de Desviaciones en GitOps

Si los objetos fueron desplegados fuera de banda o sus metadatos cambiaron sin intención, las herramientas de GitOps que usan Helm pueden recuperarse sin intervención manual usando --take-ownership.

Mejores Prácticas y Recomendaciones

  • Usa este flag intencionalmente, y documenta dónde se aplica.
  • Si es posible, elimina la versión anterior después de la migración para evitar confusiones.
  • Monitorea de cerca el comportamiento de Helm al gestionar objetos compartidos.
  • Para recursos no gestionados por Helm, continúa usando kubectl annotate o kubectl label para alinear manualmente los metadatos.

Conclusión

El flag --take-ownership es una adición bienvenida al arsenal de la CLI de Helm. Aunque no es una solución universal, suaviza muchas de las asperezas que enfrentan los desarrolladores y SREs durante la evolución de versiones y la adopción de GitOps.

Aporta una mejora sutil pero poderosa, especialmente en entornos complejos donde la propiedad de los recursos no es estática.

Mantente actualizado con las versiones de Helm, y considera este flag como tu nuevo aliado en la ingeniería avanzada de versiones.

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

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

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

Comprendiendo el Modelo de Datos de Políticas de Kyverno

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

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

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

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

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

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

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

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

1. Políticas de Validación

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

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

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

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

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

2. Políticas de Mutación

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

Caso de Uso: Agregar Etiquetas Predeterminadas a Pods

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

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

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

3. Políticas de Generación

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

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

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

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

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

Conclusión

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

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

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

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

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

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

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

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

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

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

Kyverno vs. PSA: Diferencias Clave

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

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

Cuándo Usar Kyverno en Lugar de PSA

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

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

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

Instalando Kyverno

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

Instalación Paso a Paso

Agrega el repositorio Helm de Kyverno:

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

Actualiza los repositorios de Helm:

helm repo update

Instala Kyverno en tu clúster de Kubernetes:

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

Verifica la instalación:

kubectl get pods -n kyverno

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

Desplegando Políticas con Kyverno

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

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

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

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

Aplicando la Política

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

kubectl apply -f trusted-registry-policy.yaml

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

Visualizando Informes de Políticas de Kyverno

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

Lista todos los informes de políticas de Kyverno:

kubectl get clusterpolicyreport

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

kubectl describe clusterpolicyreport <report-name>

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

Conclusión

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

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

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

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

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

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

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

¿Qué es Pod Security Admission (PSA)?

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

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

Estándares de Seguridad de Pods

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

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

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

Configuración de Pod Security Admission (PSA)

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

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

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

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

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

Modos Adicionales de PSA

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

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

Para configurar estos modos, utiliza las siguientes etiquetas:

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

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

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

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

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

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

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

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

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

Aplicación de Políticas por Defecto

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

Conclusión

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

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

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