Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Esta es documentación inédita para Admission Controller 1.34-dev.

Verificando SUSE Security Admission Controller

El stack SUSE Security Admission Controller proporciona diferentes atestaciones y garantías:

  • Atestaciones de procedencia: Informa sobre el proceso de construcción, las dependencias de construcción y ayuda a replicar las construcciones. Implementar el estándar SLSA (nivel 3 en nuestro caso).

  • Atestaciones de SBOMs: Contienen las dependencias de software. Ayudan a los consumidores en sentido descendente a determinar las vulnerabilidades de Admission Controller y sus dependencias.

  • Artefactos firmados: Indican si un artefacto es auténtico o no, proporcionando seguridad en el sistema de suministro. Esto incluye los entregables, pero también las atestaciones de procedencia y SBOM.

Los artefactos Admission Controller, las atestaciones de procedencia y los SBOMs están firmados utilizando Sigstore, con el flujo de trabajo sin clave. Esto significa que el certificado de firma contiene la siguiente información, donde * coincide con cualquier carácter siguiente:

El sujeto utilizado en la bandera CLI --certificate-identity-regexp de este tutorial utiliza los valores https://github.com/kubewarden/* para simplificar la explicación. Sin embargo, esto permite que los artefactos de los repositorios con el mismo prefijo eviten la validación. Por ejemplo: github.com/kubewarden/policy-server1.

Si deseas una verificación más segura, necesitas usar una URL completa:

https://github.com/kubewarden/policy-server/.github/workflows/container-image.yml@refs/tags/v1.30.0

Ten en cuenta que la URL incluye la ruta completa del repositorio, la ruta del archivo de flujo de trabajo y la etiqueta de versión. Si sigues esta buena práctica, puedes usar la bandera CLI cosign --certificate-identity con la URL completa.

El equipo Admission Controller también está haciendo esfuerzos para mejorar el sistema de suministro seguro y para que todo el stack cumpla con el nivel 3 de SLSA. Por lo tanto, los principales artefactos también incluyen archivos SBOM y de procedencia. En las siguientes secciones, mostraremos cómo verificar los diferentes artefactos producidos por el equipo Admission Controller y cómo asegurar el sistema de suministro seguro de los artefactos utilizando archivos SBOM y de procedencia.

Imágenes de contenedor

Para verificar las imágenes de contenedor firmadas sin clave producidas por el equipo Admission Controller, puedes usar la herramienta CLI cosign. Por ejemplo, para verificar la imagen kubewarden/policy-server, puedes ejecutar el siguiente comando:

cosign verify ghcr.io/kubewarden/policy-server:v1.30.0 \
  --certificate-identity-regexp 'https://github.com/kubewarden/*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Verification for ghcr.io/kubewarden/policy-server:v1.30.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

<snipped json>

Luego puedes verificar que el certificado en el JSON devuelto contenga el emisor, sujeto y extensiones github_workflow_repository correctos.

También puedes verificar con slsactl. Por ejemplo, para la versión 1.30.0:

slsactl verify ghcr.io/kubewarden/policy-server:v1.30.0

Lo mismo se aplica a todas las demás imágenes producidas por el equipo Admission Controller, como kubewarden/kubewarden-controller y kubewarden/audit-scanner.

Todas las imágenes de contenedor también tienen archivos SBOM y de procedencia que se pueden usar para asegurar el sistema de suministro seguro de las imágenes. Puedes encontrar archivos de atestación en la página de lanzamiento del componente o adjuntos a la imagen de contenedor en el registro OCI.

Usamos Docker para construir las imágenes y sus atestaciones. Sin embargo, el comando cosign no admite aún la verificación de las atestaciones generadas por Docker desde el registro OCI. Por esta razón, necesitas descargar los archivos de la página de lanzamiento o del registro y verificarlos localmente. Si deseas descargar los archivos de atestación del registro OCI, puedes seguir la documentación de Docker y utilizar herramientas como crane o docker para descargar los archivos del registro.

Al descargar los archivos de atestación desde la página de lanzamiento de los componentes Admission Controller, revísalos:

$ cosign verify-blob --bundle audit-scanner-attestation-amd64-checksum-cosign.bundle \
    --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
    --certificate-identity="https://github.com/kubewarden/audit-scanner/.github/workflows/attestation.yml@refs/tags/v1.30.0" \
    audit-scanner-attestation-amd64-checksum.txt
Verified OK

Ahora que se ha verificado la integridad de los archivos, puedes inspeccionar los archivos SBOM y de procedencia. Puedes obtener estos desde la imagen del contenedor, utilizando `slsactl. Por ejemplo, para la versión 1.30.0:

slsactl download provenance ghcr.io/kubewarden/policy-server:v1.30.0
slsactl download sbom ghcr.io/kubewarden/policy-server:v1.30.0

Gráficos de Helm

Puedes encontrar Admission Controller gráficos de Helm en nuestro https:// repositorio tradicional de Helm bajo https://charts.kubewarden.io..

Los mismos gráficos de Helm están firmados a través de la firma sin clave de Sigstore y se envían a un repositorio OCI que contiene tanto el gráfico de Helm como su atestación de procedencia como artefactos OCI.

Los gráficos de Helm se publican junto a un manifiesto de Hauler que lista todos los artefactos necesarios.

Verificando con Hauler

Hauler verifica automáticamente los artefactos al descargarlos. Para obtener más información, consulta nuestra documentación.

Verificando manualmente

Desde Helm 3.8.0, Helm tiene soporte para registros OCI, pero debido a las limitaciones en ellos, no se pueden buscar a través de helm. Puedes encontrar la lista de gráficos en GitHub Container Registry.

Para verificar un gráfico de Helm, necesitas tener cosign instalado. Luego ejecuta el siguiente comando, por ejemplo:

cosign verify ghcr.io/kubewarden/charts/kubewarden-defaults:1.5.4 \
  --certificate-identity-regexp 'https://github.com/kubewarden/*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Verification for ghcr.io/kubewarden/charts/kubewarden-defaults:1.5.4 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

<snipped json>

Puedes verificar que el certificado en el json devuelto contiene el emisor, sujeto y github_workflow_repository extensiones correctas.

Las atestaciones del gráfico se envían al registro OCI como una capa de artefacto. Consulta la sección imágenes de contenedor sobre cómo verificarlas.

Los Admission Controller gráficos incluyen imagelist.txt y (policylist.txt cuando sea relevante) dentro del gráfico. Por lo tanto, si ya has verificado el gráfico, puedes usar esas listas para verificar las imágenes de contenedor consumidas y las políticas.

Admission Controller también sigue las prácticas habituales con respecto a los gráficos de Helm. Por lo tanto, también se pueden encontrar todas las imágenes en los gráficos de Helm con un complemento como helm-image, o con el siguiente script:

#!/usr/bin/env bash
helm pull --untar kubewarden/kubewarden-controller && \
helm pull --untar kubewarden/kubewarden-defaults && \
{ helm template ./kubewarden-controller; helm template ./kubewarden-defaults } \
    | yq '..|.image? | select(.)' \
    | sort -u | sed 's/"//g'

que nos da:

ghcr.io/kubewarden/kubewarden-controller:v0.5.5
ghcr.io/kubewarden/policy-server:v0.3.1
ghcr.io/kubewarden/kubectl:v1.21.4

Ahora, para cada imagen en esa lista puedes verificar sus firmas de Sigstore siguiendo las instrucciones de la sección anterior.

kwctl

Los binarios de kwctl están firmados utilizando la firma de blob de Sigstore.

Cuando descargas un kwctl lanzamiento cada archivo zip contiene un archivo de paquete de Sigstore que puedes usar para la verificación: kwctl-*bundle.sigstore.

Para verificar kwctl necesitas tener cosign instalado, y luego ejecutar el siguiente comando:

cosign verify-blob \
  --bundle kwctl-linux-x86_64.bundle.sigstore \
  --certificate-identity-regexp 'https://github.com/kubewarden/*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  kwctl-linux-x86_64

Verified OK

Puedes verificar que el certificado en el json devuelto contiene el emisor, sujeto y github_workflow_repository extensiones correctas.

Los SBOMs están firmados y publicados en los lanzamientos de GitHub del proyecto.

La atestación de procedencia para kwctl se verifica utilizando gh attestation verify. Por ejemplo con gh attestation verify kwctl-linux-x86_64 --repo kubewarden/kwctl.

Directivas

Las políticas mantenidas por el equipo Admission Controller también están firmadas utilizando el proyecto Sigstore. Al igual que las imágenes de contenedor habituales, se pueden verificar utilizando cosign:

cosign verify ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.5 \
  --certificate-identity-regexp 'https://github.com/kubewarden/*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Verification for ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.5 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

  <snipped json>

Puedes verificar que el certificado en el json devuelto contiene el emisor, sujeto y github_workflow_repository extensiones correctas.