Ayuda a proteger las cadenas de suministro de software en Google Kubernetes Engine

En este artículo, se explica cómo asegurarse de que la cadena de suministro de software siga una ruta de acceso conocida y segura antes de implementar el código en un clúster de Google Kubernetes Engine (GKE). Además, se muestra cómo funciona la autorización binaria y cuál es el mejor modo de implementarla y usarla con Google Cloud a fin de garantizar que la canalización de implementación pueda proporcionar la mayor cantidad de información posible para ayudarte a aplicar las aprobaciones en cada una de las etapas requeridas.

Los informes State of DevOps identificaron las capacidades que impulsan el rendimiento de la entrega de software. Este artículo te ayudará con las siguientes funciones:

Componentes básicos para proteger la cadena de suministro de software

Cuando compilas y, luego, implementas aplicaciones en contenedores, debes usar artefactos inmutables como unidades de implementación. Los artefactos inmutables garantizan que puedas implementar y escalar el software en muchos hosts y entornos con la seguridad de que se comportará como esperas.

Luego de compilar los artefactos inmutables, los colocarás en un almacén de artefactos a fin de controlar sus versiones y catalogarlos para su uso posterior.

En varias fases del proceso de lanzamiento, las personas o los sistemas automatizados pueden agregar metadatos que describen el resultado de una actividad. Esto es similar a indicar un punto de control. Por ejemplo, puedes agregar metadatos a la imagen para indicar que aprobó un conjunto de pruebas de integración.

Después de que los artefactos tengan metadatos, crearás una política de implementación que defina las validaciones que deben aprobar antes de que puedan implementarse en la infraestructura. Crea un mecanismo en la infraestructura para validar que una carga de trabajo apruebe todos los puntos de control requeridos antes de que se admita. Este tipo de validación, que se realiza justo antes de que el código se configure para ejecutarse, garantiza que ninguna implementación omita las etapas obligatorias del flujo.

En el siguiente diagrama, se muestra un proceso general para la administración de la cadena de suministro de software.

proceso de administración de la cadena de suministro de software

Protege las cadenas de suministro en GKE

En la siguiente tabla, se asignan componentes básicos de la cadena de suministro a las características de Google Cloud.

Componente básico Implementación de Google Cloud
Artefacto inmutable Imagen de Docker
Almacén de artefactos Container Registry
Metadatos de artefactos Nota
Auditores de artefactos Certificadores
Validaciones de artefactos Certificaciones
Política de implementación Política de autorización binaria

El artefacto inmutable de GKE que implementas es una imagen de Docker. Esta imagen se compila una vez y, luego, se envía a Container Registry, el almacén de artefactos, en el que podrás implementarla en cualquier cantidad de clústeres de GKE.

En Container Registry, agregas información sobre las imágenes con etiquetas, que representan una sola pieza de metadatos. El uso más común de las etiquetas de Docker en las imágenes es indicar la versión del software o un entrenamiento de lanzamiento, como v2.0.0 o beta. Aunque esta información es útil, no puedes usar etiquetas para agregar detalles sobre el artefacto, como en qué lugar se compiló, a partir de qué código fuente o si está aprobado para implementarse en entornos de producción. Para estos detalles, usa las certificaciones.

Los certificadores pueden agregar notas sobre imágenes en Container Registry para indicar si una imagen cumple con ciertos criterios. Se puede acceder a estos fragmentos de información durante todo el ciclo de vida de la imagen. Algunos tipos de notas se clasifican de modo que puedas filtrar mejor la información sobre las imágenes. Un tipo de nota es una attestation, que agregan los certificadores en el proyecto. Por ejemplo, puedes tener un certificador que valide que las imágenes se compilen sin vulnerabilidades de seguridad críticas, o que un sistema de compilación en particular compiló una imagen.

Puedes agregar un certificador al proyecto; para ello, sube una clave pública de Privacidad bastante buena (PGP) asociada a fin de crear y, luego, identificar el certificador. Luego, los certificadores pueden crear certificaciones si firman mensajes que identifiquen qué resumen de imagen de contenido direccionable específico certifican.

En el siguiente diagrama, se muestra un ejemplo de cómo agregar una certificación a una imagen para un resumen en particular.

agregar una certificación a una imagen

Con la autorización binaria, puedes configurar una política que defina qué certificaciones deben estar presentes en la imagen antes de que pueda implementarse en los clústeres. Esta política crea un componente básico para garantizar que las imágenes sigan la ruta de acceso correcta a través de la canalización de implementación sin omitir ningún paso importante. En cada una de las etapas críticas de la canalización de implementación, puedes crear una certificación que indique que la imagen aprobó ese paso. Los sistemas automatizados o las personas pueden agregar certificaciones.

Por ejemplo, es posible que desees asegurarte de que el equipo de control de calidad (QA) haya aprobado las validaciones de la imagen. Una vez que finalizan las pruebas, uno de los miembros del equipo de QA usará una clave específica para firmar una certificación del certificador qa-validated. Esa certificación es obligatoria para que los clústeres de producción implementen la imagen.

Del mismo modo, es posible que desees asegurarte de que la imagen se haya analizado en busca de vulnerabilidades y que no haya anomalías. Un sistema automatizado podría buscar imágenes nuevas en el repositorio y agregar una certificación que indique que cumplen con un estándar de vulnerabilidad determinado. Una vez que el sistema valida el análisis de vulnerabilidades, puede firmar y agregar una certificación del certificador not-vulnerable mediante la clave criptográfica. Puedes encriptar esta clave con Cloud Key Management Service, almacenarla de forma segura en Cloud Storage, controlar el acceso a ella a través de la administración de identidades y accesos, y auditar su uso a través de Cloud Logging.

En el siguiente diagrama, se muestran imágenes de Container Registry con certificaciones agregadas por personas y certificadores automatizados.

imágenes en Container Registry agregadas por personas o mediante la automatización

Con la autorización binaria, podrás crear políticas que definan qué claves criptográficas puedes usar para validar cada una de las certificaciones. También puedes agregar ciertas imágenes a la allowlist a fin de omitir la validación de certificación o inhabilitar la autorización binaria para ciertos clústeres.

Si bien Google Cloud ofrece servicios administrados para crear y administrar la cadena de suministro de software, también puedes usar implementaciones de código abierto a fin de implementar procesos similares en otros entornos.

En la siguiente tabla, se asignan los servicios de Google Cloud a las herramientas de código abierto que ofrecen funcionalidades similares.

Google Cloud Código abierto
Container Registry Distribución de Docker
API de metadatos Grafeas
Autorización binaria Kritis
Análisis de vulnerabilidades Clair, Anchore Engine

Prácticas recomendadas para la canalización de entrega continua

Validar la cadena de suministro de software es más eficaz cuando tienes una canalización de entrega continua que usa la automatización a fin de implementar un código fuente de un repositorio de código en la infraestructura de producción. Las etapas de estas canalizaciones varían entre las organizaciones, pero puedes implementar algunas prácticas recomendadas de alto nivel para garantizar que la canalización implemente el software de forma segura.

Orientación general sobre canalización de CI/CD

Muchas organizaciones permiten que los equipos individuales elijan sus propios procesos y herramientas de entrega continua. Si bien esta flexibilidad puede aumentar la autonomía y permite que los equipos usen herramientas conocidas, puede complicar la tarea de garantizar que todos los lanzamientos sigan las prácticas recomendadas. Recomendamos centralizar las canalizaciones de lanzamiento para equipos en una herramienta como Spinnaker, que ayuda a garantizar que puedas crear plantillas, compartir y auditar las metodologías en un mismo lugar.

Compila una imagen

Al igual que con cualquier cadena de suministro, el software es tan seguro como los materiales que usas para construir los artefactos ejecutables. Cuando usas GKE, debes asegurarte de que las imágenes que construyes provienen de imágenes base seguras.

El primer paso para maximizar la seguridad de las imágenes base es usar una distribución mínima que incluya solo el software y las bibliotecas necesarias para ejecutar la aplicación. Para las distribuciones populares, como Ubuntu, Debian y CentOS, Google Cloud proporciona imágenes base administradas que se actualizan de forma periódica con parches de seguridad. Las imágenes sin distribución son un conjunto de imágenes base que incluyen solo las bibliotecas y las herramientas necesarias para ejecutar aplicaciones escritas en varios lenguajes de programación. Después de elegir una base, intenta minimizar lo que agregas. Puedes aprovechar las compilaciones de varias etapas de Docker para separar las dependencias de tiempo de compilación de las dependencias de entorno de ejecución, lo cual reduce la superficie de ataque.

Después de compilar la imagen, asegúrate de que cumpla con las políticas de la organización. Puedes crear pruebas de estructura de contenedor que validen el contenido y los metadatos de la imagen. También puedes usar container-diff para comparar los contenedores existentes con los recién compilados.

Cuando hayas restringido el contenido de la imagen de la aplicación, intenta auditar las imágenes de terceros admitidas en los clústeres y reducir sus permisos. Puedes usar la autorización binaria para agregar las imágenes a la allowlist que puede omitir los requisitos de certificación. Asegúrate de que la entrada allowlist sea lo más específica posible para cada una de las imágenes que necesitas, pero que no puedes compilar a través de la canalización de creación de artefactos.

Encontrarás más información sobre cómo compilar contenedores en la documentación Prácticas recomendadas para compilar contenedores.

Habilita el análisis de vulnerabilidades de las imágenes

Habilita el análisis de vulnerabilidades de Container Registry en los proyectos para obtener más información sobre posibles problemas de seguridad en las imágenes de Docker. Los análisis automatizados que se ejecutan tan pronto se envían las imágenes pueden ayudarte a comprender la gravedad de las vulnerabilidades en las imágenes. Aunque debes comprobar si existen vulnerabilidades antes de la implementación, también debes revisar las imágenes después de la implementación, ya que es posible que se detecten vulnerabilidades nuevas. El análisis de vulnerabilidades analiza de manera continua las imágenes extraídas del registro en los últimos 30 días. Puedes usar Pub/Sub para recibir notificaciones cuando se encuentren vulnerabilidades en las imágenes.

Valida tu política durante la implementación

Para proteger la cadena de suministro de software, habilita la validación de imágenes durante la implementación. Como último paso en una canalización de entrega continua, la implementación es un buen momento para asegurarse de que el proceso incluya todas las etapas y apruebe todos los puntos de control. Si adoptas este enfoque, incluso si una persona obtuvo acceso a las credenciales de los clústeres, no podrá implementar imágenes maliciosas.

Con la autorización binaria, puedes configurar una regla predeterminada para todos los clústeres del proyecto y, luego, anularlas con opciones de configuración específicas del clúster. Por ejemplo, quizás deseas que todos los clústeres requieran certificaciones de análisis de vulnerabilidades y una validación de QA, pero también quieres asegurarte de que los desarrolladores puedan experimentar con imágenes y tecnologías nuevas en el clúster development sin pasar por una validación de QA. Para obtener más información sobre las políticas de autorización binaria, consulta la documentación Referencia de las políticas en formato YAML.

Canalización de ejemplo

A continuación, se muestra una canalización de ejemplo que se divide en dos fases principales: la compilación y la implementación.

Compilar y, luego, implementar fases en una canalización de muestra

En la siguiente tabla, se proporcionan más detalles sobre los pasos de la canalización y en qué lugar se agregan las certificaciones.

Número de paso Resumen Descripción Ícono
de la certificación
1 Obtener código fuente Comprueba el código fuente en la revisión deseada para que lo use el sistema de compilación. Ninguno
2 Ejecutar pruebas de unidades Asegúrate de que el código pase todas las pruebas de unidades antes de crear un artefacto.

Ejecutar pruebas de unidades.

3 Crear una imagen de Docker Usa el Dockerfile en el código fuente local para compilar una imagen que se pueda enviar a Container Registry. Ninguno
4 Asegurarse de que la imagen de Docker se ajuste a la política Con las pruebas de estructura de contenedores, puedes afirmar que la imagen tiene el contenido correcto y que los comandos dentro de ella muestran el resultado correcto.

Asegurarse de que la imagen de Docker se ajuste a la política.

5 Enviar imagen a Container Registry Una vez que el código se sometió a pruebas de unidades y se validó el contenido de la imagen, podrás enviarla a Container Registry. Se iniciará un análisis de vulnerabilidades de forma automática. Ninguno
6 Asegurarse de que la imagen no tenga vulnerabilidades críticas El análisis de vulnerabilidades tarda unos minutos en completarse y, luego, agrega notas a los metadatos de la imagen sobre las vulnerabilidades y riesgos comunes (CVE) que aparecen. Espera a que aparezcan estos datos y, luego, agrega una certificación si no se encuentran vulnerabilidades críticas.

Asegurarse de que la imagen no tenga vulnerabilidades críticas.

7 Implementar la imagen en etapa de pruebas Inicia una implementación en un entorno de preproducción en el que se puedan validar y observar los cambios en distintas situaciones lo más cercanas posibles a la producción.

Implementar imagen en etapa de pruebas.

8 Aprobar el código para la implementación en producción Si todas las señales muestran que el cambio cumple con los requisitos, apruébalo para que se implemente en producción. Ninguno
9 Implementar código en clústeres de producción Ahora puedes configurar la imagen para que se actualice en todos tus clústeres. Cada clúster verifica que todas las certificaciones estén completas antes de ejecutar la aplicación. Ninguno

Certificaciones de ejemplo

A continuación, se incluyen algunas certificaciones que tal vez quieras incluir en la canalización de lanzamiento:

  • Los resultados de los análisis de vulnerabilidades no incluyeron vulnerabilidades críticas.
  • Se aprobó la validación manual de QA.
  • Todo el software que se incluye en la imagen tiene una licencia adecuada.
  • El artefacto se creó en un sistema de compilación de confianza.

Próximos pasos