Firma de código y flujos de trabajo de seguridad de Kubernetes: Lo que necesita saber

Gracias a la estandarización de CI/CD, las aplicaciones modernas ya no necesitan desarrollarse y distribuirse como monolitos. Atrás quedaron los días de los "días de lanzamiento" y las actualizaciones masivas de productos con largos tiempos de ejecución y esfuerzos de desarrollo aislados. La creciente popularidad y prominencia de las aplicaciones en contenedores condujo al crecimiento de plataformas de orquestación como Kubernetes, cuya seguridad se ha vuelto esencial ahora que es fundamental para muchas aplicaciones modernas.

But how do you prove that what you run in Kubernetes is what you built and intended to deploy? Container orchestration platforms greatly benefit from code signing.

La firma de código es un elemento de seguridad importante en una estrategia de desarrollo shift-left, en la que las medidas de seguridad se incorporan al producto como características antes de su lanzamiento.

La firma de código mejora la seguridad y la confianza en las canalizaciones de desarrollo de software , actuando para vincular los artefactos de software a la identidad y confirmar su integridad con firmas criptográficas. La estrategia de certificados e identidades ya no es una prerrogativa de TLS y las identidades de dispositivos; ampliarla a las identidades de desarrolladores y creadores en Kubernetes es una oportunidad clave para enriquecer la confianza digital en su organización.

Development with Kubernetes has many advantages, but also pitfalls that code signing can help address. Read on for a discussion of potential gaps in Kubernetes security, how code signing and PKI can help bridge these gaps, and the best practices for signed container security workflows.

Lagunas en la seguridad de Kubernetes 

Public key infrastructure (PKI) is a necessary part of application development and delivery. Kubernetes certainly already relies on PKI for its many components. Control plane, kubelets, client certificates, and more all use X.509 certificates and certificate signing requests (CSRs) natively.

However, the scope of typical PKI implementation is often limited to infrastructure, leaving software artifacts running in pods and containers exposed and potentially at risk if their integrity isn’t verified in other ways. A Software Bill of Materials (SBOM) can fill part of that visibility gap by providing a complete inventory of components and dependencies within container images, while code signing verifies that these images come from trusted sources.

As teams adopt more fluid and automated CI/CD pipelines and make use of container registries and Kubernetes clusters, unsigned or compromised images can slip past scanning tools to run in production. Best-case scenario: an honest mistake. Worst-case scenario: compromised assets, broken processes, and expensive fallout from the damage. Mutable image tags deepen the risk, as someone could re-push to the same tag, bypassing native checks. This is why many architecture guides emphasize the necessity of cryptographic signing and signature verification in the cluster.

En la práctica, por supuesto, los desarrolladores pueden resistirse a la fricción que los procedimientos de firma introducen en el flujo, o recurrir por defecto a guiones ad hoc al margen de la gobernanza.

This leads to signing key sprawl and weak signing practices, where code signing scripts malfunction or the signing isn’t done at all. The challenges don’t stop there: smart key management in tune with scaling processes demands not only higher security for private key storage (ideally, in HSMs or key vaults), but also automated certificate lifecycle management for cross-cluster consistency.

La aplicación de políticas en tiempo de ejecución también es un requisito para que las operaciones de Kubernetes sean más seguras. Una vez firmada una imagen, los controladores de admisión o los motores de políticas deben verificar que el entorno Kubernetes solo ejecuta imágenes con firmas válidas y verificables. Además, la infraestructura de firma en cuestión debe ser lo suficientemente ágil como para seguir el ritmo de la rápida evolución del panorama de la ciberseguridad y los avances en criptografía. La creación de una infraestructura ágil que no suponga una carga excesiva para los recursos de la organización a medida que evoluciona es uno de los principales retos de DevOps.

Cómo salvar la brecha de confianza en la seguridad de Kubernetes

Dados los retos de implementar la firma de código en Kubernetes, no es de extrañar que algunos entornos todavía no hagan uso de ella a pesar de su clara necesidad.

El flujo de trabajo inseguro típico es el siguiente: El desarrollador confirma el código; CI/CD crea una imagen de contenedor; la imagen se envía a un registro; Kubernetes la pone en producción. ¿Problemas? Unos cuantos:

1. No hay ninguna prueba criptográfica que vincule esa imagen a un proceso de construcción verificado.
2. De este modo, cualquiera con acceso al registro podría reemplazar o manipular la imagen, y Kubernetes seguiría desplegándola, ya que sólo confía en la etiqueta.
3. La tubería resultante es eficiente, pero ¿es fiable? Definitivamente, no es verificable.

Existen numerosas oportunidades para asegurar este flujo de trabajo que no se limitan exclusivamente a la firma de código.

Paso 1: Introducir la identidad verificada en el proceso de construcción

Code signing makes application workflows verifiable and tied to an auditable identity. With a certificate management tool like Keyfactor Command, a code signing certificate is issued to the build system through the same PKI framework that secures TLS and devices. Each build that automatically signs its container image and related binaries becomes part of the secure CI/CD workflow. This signature is tied to a governed, auditable identity, instead of an unmanaged key sitting on a build server. Keys can be stored in integrated HSMs or cloud key vaults, rotated automatically, and revoked if compromised, in line with PKI best practices.

Paso 2: Extender la confianza a toda la cadena de suministro

Cada imagen firmada se envía al registro de contenedores junto con su firma digital. Command mantiene el anclaje de confianza y los metadatos del certificado, por lo que cualquier clúster de Kubernetes puede verificar la imagen con la raíz de confianza de la organización. Los paquetes de confianza se distribuyen automáticamente en todos los entornos, independientemente de la configuración (local, en la nube, híbrida), por lo que cada clúster comparte una política de verificación coherente, eliminando la deriva de la configuración manual que a menudo socava la seguridad multiclúster.

Paso 3: Convertir Kubernetes en un punto de aplicación

Con la firma de código, la funcionalidad innata de Kubernetes puede reforzar la seguridad de todo el canal. Cuando un desarrollador despliega una nueva imagen, un controlador de admisión o un motor de políticas comprueba la firma antes de programar el pod. En cierto sentido, Kubernetes ya no "espera" que la imagen sea legítima, sino que la verifica utilizando la prueba criptográfica emitida bajo la gobernanza PKI de la empresa. Si la firma de la imagen falta, ha caducado o no es de confianza, el despliegue se rechaza automáticamente sin ralentizar los lanzamientos legítimos. Dado que esta aplicación se rige por políticas y no depende de secuencias de comandos ad hoc, es intrínsecamente escalable y coherente en todos los clústeres.

Paso 4: Introducir la gestión total del ciclo de vida con Keyfactor Command

Employing PKI tools such as Keyfactor Command for container security workflows has the advantages of total lifecycle management, automation, and elimination of human error. Code signing keys and certificates follow defined, automatable lifecycles from certificate creation, rotation, and renewal to certificate revocation and retirement. Automated certificate lifecycle management solutions enable organizations to easily adapt to evolving cryptographic standards.

Un flujo de trabajo de seguridad de Kubernetes maduro comprueba las siguientes casillas:

• Cada artefacto tiene una firma verificable vinculada a una identidad audible
• Los equipos de seguridad ven la actividad de firma, el estado de los certificados y la aplicación de políticas en todos los clústeres en un único panel unificado.
• Los registros de auditoría muestran exactamente qué clave firmó qué compilación, cuándo y bajo la autoridad de quién, lo que facilita el cumplimiento de la normativa.
• Las credenciales de firma caducadas o perdidas se detectan y rectifican a tiempo, lo que evita interrupciones o vulnerabilidades.

Mejores prácticas de firma de código para los flujos de trabajo de seguridad de Kubernetes

La firma de código en Kubernetes abarca cuatro capas integradas: creación y firma, verificación y aplicación, registro y almacenamiento, y distribución de confianza y gestión del ciclo de vida.

La capa de creación y firma incluye canalizaciones CI/CD que solicitan automáticamente la firma de identidades mediante la emisión basada en políticas vinculada a la PKI de la empresa. Los controladores de admisión de Kubernetes validan las firmas con anclajes de confianza gestionados, de modo que solo se permite la ejecución de cargas de trabajo verificadas. Las imágenes firmadas y los metadatos se almacenan juntos, lo que significa que la procedencia viaja con cada artefacto a través de los registros. Una automatización satisfactoria sincroniza los paquetes de confianza, rota las claves y actualiza los estándares criptográficos sin interrumpir las implantaciones.

Teniendo en cuenta estas cuatro capas de seguridad de Kubernetes, algunas de las mejores prácticas operativas que deben aplicarse incluyen:

• Despliegue de imágenes mediante compendios inmutables en lugar de etiquetas mutables para evitar ataques de sustitución.
• Definición de políticas a nivel de clúster, de modo que sólo se permitan las cargas de trabajo firmadas por sistemas de compilación autorizados.
• Almacenamiento de claves de firma privadas en HSM o cámaras acorazadas integradas, y automatización de su rotación.
• Mantener registros de auditoría completos de los eventos de firma y verificación para garantizar el cumplimiento de la normativa.
• Planificar la criptoagilidad, ya que los algoritmos de firma evolucionan mucho más rápido que los ciclos de vida de las infraestructuras.

Conclusión

La seguridad de Kubernetes ahora abarca no solo la protección de la infraestructura, sino también la protección de los activos de software con la firma de código. La integración de la firma de código en el flujo de trabajo se está convirtiendo en una práctica estándar para unir la agilidad de DevOps y la seguridad de PKI, garantizando que todas las cargas de trabajo estén autenticadas y autorizadas.

Cuando sus clústeres Kubernetes solo ejecutan software verificado criptográficamente, la seguridad deja de ser una suposición y se convierte en una garantía operativa.

Este proceso puede empezar por algo pequeño: firmar una única canalización de CI/CD, aplicar firmas en un clúster y ampliarlo a toda la organización. 

Keyfactor Command ofrece la automatización y visibilidad para hacerlo escalable, desde la emisión y rotación de certificados hasta la gestión de paquetes de confianza y la integración con herramientas CI/CD y Kubernetes.

The future of container security is verifiable trust.  Get in touch with Keyfactor today to help build it. Have any questions? Our team is here to help!