Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Esta é uma documentação não divulgada para Admission Controller 1.34-dev.

Verificando SUSE Security Admission Controller

A pilha SUSE Security Admission Controller fornece diferentes atestações e garantias:

  • Atestações de proveniência: Informe sobre o processo de construção, as dependências de construção e auxilie na replicação das construções. Implementar o padrão SLSA (nível 3 no nosso caso).

  • Atestações de SBOMs: Contêm as dependências de software. Ajudam os consumidores downstream a determinar vulnerabilidades de Admission Controller e suas dependências.

  • Artefatos assinados: Indicam se um artefato é autêntico ou não, proporcionando segurança na cadeia de suprimento. Isso inclui os entregáveis, mas também as atestações de proveniência e SBOM.

Os artefatos Admission Controller, atestações de proveniência e SBOMs são assinados usando Sigstore, com o fluxo de trabalho sem chave. Isso significa que o certificado de assinatura contém as seguintes informações, onde * corresponde a quaisquer caracteres seguintes:

O sujeito usado na flag CLI --certificate-identity-regexp do cosign neste tutorial utiliza os valores https://github.com/kubewarden/* para simplificar a explicação. No entanto, isso permite que artefatos de repositórios com o mesmo prefixo contornem a validação. Por exemplo: github.com/kubewarden/policy-server1.

Se você quiser uma verificação mais segura, precisa usar uma URL completa:

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

Observe que a URL inclui o caminho completo do repositório, o caminho do arquivo de workflow e a tag de versão. Se você seguir essa melhor prática, pode usar a flag CLI do cosign --certificate-identity com a URL completa.

A equipe Admission Controller também está fazendo esforços para melhorar a cadeia de suprimento segura e tornar toda a pilha compatível com o nível 3 do SLSA. Portanto, os principais artefatos também incluem arquivos SBOM e de proveniência. Nas seções a seguir, mostraremos como verificar os diferentes artefatos produzidos pela equipe Admission Controller e como garantir a cadeia de suprimento segura dos artefatos usando arquivos SBOM e de proveniência.

Imagens de container

Para verificar as imagens de contêiner assinadas sem chave produzidas pela equipe Admission Controller, você pode usar a ferramenta CLI cosign. Por exemplo, para verificar a imagem kubewarden/policy-server, você pode executar o seguinte 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>

Você pode então verificar se o certificado no JSON retornado contém o emissor, sujeito e extensões github_workflow_repository corretos.

Você também pode verificar com slsactl. Por exemplo, para a versão 1.30.0:

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

O mesmo se aplica a todas as outras imagens produzidas pela equipe Admission Controller, como kubewarden/kubewarden-controller e kubewarden/audit-scanner.

Todas as imagens de contêiner também possuem arquivos SBOM e de proveniência que podem ser usados para garantir a cadeia de suprimento segura das imagens. Você pode encontrar arquivos de atestação na página de lançamento do componente ou anexados à imagem do contêiner no registro OCI.

Usamos o Docker para construir as imagens e suas atestações. No entanto, o comando cosign não suporta ainda a verificação das atestações geradas pelo Docker a partir do registro OCI. Por essa razão, você precisa baixar os arquivos da página de lançamento ou do registro e verificá-los localmente. Se você quiser baixar os arquivos de atestação do registro OCI, pode seguir a documentação do Docker e usar ferramentas como crane ou docker para baixar os arquivos do registro.

Ao baixar os arquivos de atestação da página de lançamento dos componentes Admission Controller, verifique-os:

$ 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

Agora que a integridade dos arquivos foi verificada, você pode inspecionar os arquivos SBOM e de proveniência. Você pode obtê-los da imagem do contêiner, usando `slsactl. Por exemplo, para a versão 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 Helm

Você pode encontrar Admission Controller gráficos Helm em nosso repositório tradicional de Helm https:// sob https://charts.kubewarden.io.

Os mesmos gráficos Helm são assinados via assinatura sem chave do Sigstore e enviados para um repositório OCI que contém tanto o gráfico Helm quanto sua atestação de proveniência como artefatos OCI.

Os gráficos Helm são publicados juntamente com um manifesto Hauler que lista todos os artefatos necessários.

Verificando com Hauler

O Hauler verifica automaticamente os artefatos ao serem baixados. Para mais informações, consulte nossa documentação.

Verificando manualmente

Desde o Helm 3.8.0, o Helm tem suporte para registros OCI, mas devido a restrições, eles não podem ser pesquisados via helm. Você pode encontrar a lista de gráficos no GitHub Container Registry.

Para verificar um gráfico Helm, você precisa ter cosign instalado. Então execute o seguinte comando, por exemplo:

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>

Você pode então verificar se o certificado no json retornado contém o emissor, o assunto e as extensões github_workflow_repository corretas.

As atestações do gráfico são enviadas para o registro OCI como uma camada de artefato. Veja a seção imagens de contêiner sobre como verificá-las.

Admission Controller gráficos enviam imagelist.txt e (policylist.txt quando relevante) dentro do gráfico. Portanto, se você já verificou o gráfico, pode usar essas listas para verificar as imagens de contêiner consumidas e as políticas.

Admission Controller também segue as práticas habituais em relação aos gráficos Helm. Portanto, também é possível encontrar todas as imagens nos gráficos Helm com um plugin como helm-image, ou com o seguinte 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'

o que nos dá:

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

Agora, para cada imagem nessa lista, você pode verificar suas assinaturas Sigstore seguindo as instruções da seção anterior.

kwctl

Os binários kwctl são assinados usando assinatura de blob do Sigstore.

Quando você baixa um kwctl lançamento cada arquivo zip contém um arquivo de pacote Sigstore que você pode usar para verificação: kwctl-*bundle.sigstore.

Para verificar o kwctl, você precisa ter o cosign instalado e, em seguida, executar o seguinte 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

Você pode então verificar se o certificado no json retornado contém o emissor, o assunto e as extensões github_workflow_repository corretas.

Os SBOMs são assinados e publicados nos GitHub Releases do projeto.

A atestação de proveniência para kwctl é verificada usando gh attestation verify. Por exemplo, com gh attestation verify kwctl-linux-x86_64 --repo kubewarden/kwctl.

Políticas

As políticas mantidas pela equipe Admission Controller também são assinadas usando o projeto Sigstore. Semelhante às imagens de contêiner habituais, é possível verificá-las usando 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>

Você pode então verificar se o certificado no json retornado contém o emissor, o assunto e as extensões github_workflow_repository corretas.