Helm Kubernetes Charts GitOps
El empaquetado Kubernetes con Helm se apoya en el gestor de paquetes de facto de Kubernetes, pero los charts mal estructurados generan dispersión de secretos, deriva entre entornos y riesgo en la cadena de suministro. Diseñamos bibliotecas de charts, jerarquías de valores gestionadas con helmfile y flujos con registros OCI que hacen que cada despliegue en Kubernetes sea reproducible, auditable y seguro de actualizar. Lo entregamos a equipos de ingeniería de EE. UU. y la UE que ejecutan cargas reguladas en EKS, AKS y GKE.
El empaquetado Kubernetes con Helm se apoya en el gestor de paquetes de facto de Kubernetes, pero los charts mal estructurados generan dispersión de secretos, deriva entre entornos y riesgo en la cadena de suministro. Diseñamos bibliotecas de charts, jerarquías de valores gestionadas con helmfile y flujos con registros OCI que hacen que cada despliegue en Kubernetes sea reproducible, auditable y seguro de actualizar. Lo entregamos a equipos de ingeniería de EE. UU. y la UE que ejecutan cargas reguladas en EKS, AKS y GKE.
Retos
Es habitual que los equipos suban contraseñas y claves de API a values.yaml o a archivos de sobrescritura, donde permanecen indefinidamente en el historial de Git. Aplicamos External Secrets Operator o el cifrado con SOPS en todos los entornos, con un control de CI de análisis de secretos que hace fallar cualquier commit con credenciales en texto plano.
A medida que crece el número de microservicios, decenas de charts casi idénticos divergen en silencio: distintas convenciones de etiquetas, distintos tiempos de espera de las probes, distintos límites de recursos. Consolidamos la lógica compartida en un library chart para que los charts de aplicación hereden valores por defecto coherentes y solo sobrescriban lo que realmente es distinto.
Los archivos de valores separados de dev, staging y producción divergen con el tiempo, y provocan despliegues en staging que no reflejan lo que acabará en producción. Usamos helmfile con sobrescrituras específicas de cada entorno sobre una base compartida, de modo que la deriva sea visible en la revisión de código y no haya desajustes silenciosos.
Las actualizaciones de Helm que cambian CRD, ejecutan migraciones de esquema o modifican cargas con estado pueden dejar los clústeres a medio actualizar. Diseñamos hooks previos y posteriores a la actualización, probamos las rutas de actualización en staging con volúmenes de datos equivalentes a los de producción y validamos los procedimientos de rollback antes de tocar producción.
Los umbrella charts que incorporan subcharts de Bitnami o charts de servicios internos crean árboles de dependencias transitivas difíciles de auditar y de actualizar. Establecemos una política clara de fijación de versiones de subcharts, usamos Renovate para generar PR de dependencias automáticos y limitamos la profundidad de anidamiento de subcharts para que el grafo de dependencias siga siendo comprensible.
Las referencias a charts sin firmar o sin fijar permiten una sustitución arbitraria si se compromete un registro o se sobrescribe un chart bajo la misma etiqueta. Aplicamos la fijación por digest OCI y la verificación de firmas con cosign tanto en el pipeline de CI como en las políticas de admisión del clúster, de modo que solo los charts verificados puedan llegar a producción.
Soluciones
Un library chart compartido recoge los estándares de etiquetas de su organización, los valores por defecto de límites de recursos, las plantillas de probes y las políticas de contexto de seguridad: los charts de aplicación pasan a ser sobrescrituras ligeras y el mantenimiento de charts se reduce a una fracción del esfuerzo original.
Cada chart se firma con cosign y se almacena en un registro OCI por digest inmutable. El CI y los controladores de admisión del clúster verifican la firma antes de instalar cualquier chart, con lo que obtiene una cadena de custodia completa y a prueba de manipulaciones desde el desarrollo hasta producción.
Helmfile orquesta la superposición de valores específicos de cada entorno en dev, staging y producción. Una única pull request muestra exactamente qué valores cambian entre entornos, lo que elimina la deriva silenciosa y hace predecible la promoción.
Los manifiestos renderizados por Helm pasan por Conftest (OPA) o Kyverno en el CI antes del despliegue. Las políticas imponen límites de recursos, registros de imágenes, contextos de seguridad y políticas de red, y las versiones que no las cumplen se bloquean automáticamente.
Las releases de Helm se declaran como Applications de ArgoCD o HelmReleases de Flux: cada despliegue es un commit de Git, cada diff se puede revisar y un estado desincronizado genera una alerta en lugar de una divergencia silenciosa respecto al estado deseado.
Diseñamos hooks de Helm para las migraciones de base de datos previas a la actualización y para las pruebas de humo posteriores. Los procedimientos de rollback están documentados, probados con snapshots de staging y automatizados cuando el rollback nativo de Helm no basta para las cargas con estado.
Stack
Helm 3, plantillas de charts (Go templates), library charts, subcharts y dependencias, helmfile, Chart Museum, registros de charts OCI, cosign (charts firmados), hooks de Helm, esquema JSON de valores, post-render con Kustomize, ArgoCD, Flux, Renovate.
Cumplimiento
Sin secretos en los valores · Cadena de suministro firmada · Dependencias de charts fijadas · Controles de políticas como código
Casos
App multiplataforma de noticias deportivas y portal web: CMS mediante un bot de Telegram en lugar de un panel de administración a medida y un pipeline de publicación en Markdown.
Plataforma de transporte con conductor con tres apps (conductor, pasajero y despachador), con GPS en tiempo real, verificación de documentos y doble método de pago en efectivo y con tarjeta.
Plataforma social en producción, en App Store y Google Play, activa en EE. UU. y la UE, con Radar geolocalizado, mensajería cifrada y economía virtual.
Por qué YuSMP
Todos los charts que entregamos incluyen un esquema JSON de valores, una prueba de snapshot del manifiesto renderizado y un artefacto OCI firmado. Sus equipos de seguridad y cumplimiento pueden verificar la procedencia, validar el cumplimiento de las políticas y revisar los diffs sin necesidad de entender los entresijos de Helm.
La firma con cosign, la fijación por digest OCI y la verificación en el controlador de admisión no son complementos: forman parte de nuestra entrega estándar de charts. Los clientes regulados obtienen una cadena de despliegue a prueba de manipulaciones lista para auditorías de SOC 2 y SLSA.
Estructuramos las releases de Helm como recursos de primera clase de ArgoCD o Flux desde el principio, para que la reconciliación GitOps, la detección de deriva y el rollback automático funcionen correctamente, y no como un parche posterior sobre releases de Helm gestionadas a mano.
Preguntas frecuentes
Resuelven problemas distintos y a menudo se usan juntos. Helm empaqueta definiciones de aplicaciones de Kubernetes reutilizables, con valores parametrizados y hooks de ciclo de vida: es la opción adecuada cuando se necesitan paquetes de aplicación versionados y distribuibles. Kustomize aplica parches puntuales a manifiestos existentes sin plantillas, algo útil para sobrescrituras específicas de cada entorno sobre la salida de Helm de terceros. Solemos combinar ambos: Helm para empaquetar la aplicación y Kustomize como post-renderer de Helm para los ajustes específicos del clúster que no deben vivir dentro del chart.
Nunca ponemos secretos en values.yaml ni en archivos de sobrescritura. Para los equipos que usan GitOps, External Secrets Operator obtiene los secretos de AWS Secrets Manager, Azure Key Vault o HashiCorp Vault al arrancar el pod: el chart hace referencia a un SecretStore, no al valor del secreto. Para los equipos que necesitan almacenamiento cifrado en Git, SOPS cifra los archivos de valores con una clave de KMS; el texto plano nunca toca el disco sin cifrar fuera de un entorno de compilación de confianza. Ambos enfoques son compatibles con ArgoCD y Flux.
Publicamos los charts en registros OCI (ECR, ACR, GHCR) con versionado semántico y referencias por digest inmutable, sin etiquetas latest mutables. Renovate vigila las versiones de charts de origen y abre pull requests cuando hay una versión nueva, de modo que las actualizaciones pasan por revisión de código y no ocurren en silencio. Chart Museum se reserva para los equipos con registros aislados (air-gapped); OCI es el estándar preferido para los proyectos nuevos.
Un chart firmado combina una firma de cosign y una atestación de procedencia almacenadas junto al artefacto del chart en el registro OCI. La firma demuestra que el chart lo construyó su pipeline de CI y que no se modificó en tránsito ni en el registro. Los controladores de admisión del clúster (Kyverno u OPA Gatekeeper) pueden verificar la firma antes de permitir la instalación, lo que bloquea los ataques a la cadena de suministro en los que se despliega en producción un chart comprometido o sustituido. También satisface los requisitos de procedencia de SLSA nivel 2.
ArgoCD admite Helm de forma nativa mediante el bloque helm de la especificación Application: renderiza el chart en el lado del controlador y aplica el diff al clúster. Flux usa los recursos personalizados HelmRelease y HelmRepository para gestionar de forma declarativa las releases de Helm. En ambos casos, la versión del chart y los valores se suben a Git y el controlador GitOps reconcilia el clúster para que coincida. Configuramos ApplicationSets de ArgoCD para los despliegues multiclúster o multi-tenant y Kustomizations de Flux para la promoción por capas entre entornos.
Un umbrella chart es un chart de nivel superior que declara otros charts como dependencias en Chart.yaml; se usa para desplegar un conjunto de servicios relacionados (por ejemplo, una aplicación de microservicios junto con sus subcharts de Postgres y Redis) como una única release de Helm. Los subcharts heredan los valores que se pasan desde el values.yaml del chart padre. Usamos umbrella charts cuando el orden de despliegue y el ciclo de vida deben gestionarse conjuntamente. Para los servicios que se despliegan de forma independiente preferimos releases separadas gestionadas con helmfile o ApplicationSets de ArgoCD, lo que da una granularidad más limpia en las actualizaciones y los rollbacks.
Las actualizaciones seguras requieren tres cosas: una ruta de rollback probada, un entorno de staging que reproduzca la topología de recursos de producción y una secuenciación basada en hooks para las migraciones de esquema. Usamos hooks previos a la actualización para las migraciones de base de datos y hooks posteriores para las pruebas de humo; si una prueba de humo falla, la opción --atomic de Helm activa el rollback automático. Las actualizaciones de CRD se gestionan aparte de los charts de aplicación porque Helm no revierte los cambios de CRD: las aplicamos mediante un paso de CI dedicado con un procedimiento de rollback independiente.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.