Vista geral da validação contínua

A validação contínua (CV) com políticas de plataforma baseadas em verificações é uma funcionalidade da autorização binária que lhe permite monitorizar os pods executados no Google Kubernetes Engine (GKE) para garantir que as respetivas imagens de contentores associadas continuam em conformidade com as políticas de plataforma baseadas em verificações da autorização binária que especificar.

Quando o CV determina que os pods violam as políticas da plataforma, este regista as violações no Cloud Logging.

A CV com políticas da plataforma substitui a validação contínua antiga (descontinuada).

Porquê usar o CV?

Embora a aplicação da autorização binária forneça validações de imagens únicas quando implementa imagens de contentores, o CV monitoriza continuamente se as imagens associadas aos pods em execução continuam a estar em conformidade com as suas políticas.

Por este motivo, quando ativa a aplicação da autorização binária e a CV com políticas baseadas em verificações, pode garantir que a conformidade com as políticas é validada durante todo o ciclo de vida da orquestração.

O CV é útil nos seguintes cenários:

  • Alterações de políticas: quando atualiza as políticas de aplicação de singleton do projeto da autorização binária, a autorização binária valida apenas as imagens implementadas após a atualização. Os pods que já estão em execução não são afetados. Continuam a ser executados, mesmo que a autorização binária, através da política atualizada, bloqueie agora a implementação da mesma imagem.

    Por este motivo, quando atualiza a política de singleton do projeto de autorização binária, recomendamos que também crie ou atualize uma política da plataforma de CV para corresponder à política de singleton do projeto. Desta forma, o CV informa-o sobre os pods em execução que violam as suas políticas atualizadas.

  • Monitorização dos metadados de imagens: a CV fornece verificações específicas para alterações nos metadados de imagens, incluindo o seguinte:

    • Atestados: o CV regista quando os atestados nas imagens dos Pods deixam de ser válidos.
    • Atualidade: o CV regista quando deteta que as imagens dos pods já não são atuais.
    • Proveniência: a CV pode verificar se as imagens dos pods foram criadas com um criador fidedigno, usando configurações de compilação que residem num repositório de origem fidedigno.
    • Assinaturas Sigstore: registos de CV quando as imagens nos pods não têm uma assinatura Sigstore válida.
    • Diretório fidedigno: registos de CV quando as imagens dos pods residem num diretório do repositório que não está listado na sua política da plataforma.
    • Vulnerabilidades: registos de CV quando são identificadas vulnerabilidades nas imagens dos pods.

  • Monitorização de execução de ensaio: quando ativa a execução de ensaio, a autorização binária permite a implementação de todas as imagens. Ao ativar o CV com uma política de plataforma que corresponda à política de instância única do projeto, o CV regista regularmente imagens que violam a política de plataforma.

  • Monitorização de acesso de emergência: quando implementa pods através do acesso de emergência, a autorização binária ignora a aplicação de políticas de instância única do projeto e regista um único evento nos registos de auditoria da nuvem. No entanto, ao usar uma política da plataforma de correspondência, o CV continua a registar regularmente pods que violam as políticas, incluindo os pods implementados através do breakglass.

Como funciona o CV

Para usar o CV, tem de o ativar nos seus clusters do GKE.

Depois de implementar imagens no cluster, o CV monitoriza os pods associados para se certificar de que estão em conformidade com a política da plataforma baseada em verificações.

A CV não suporta etiquetas de imagens, exceto as especificadas em imagens isentas.

O CV revê regularmente os pods em execução

Para monitorizar os pods em execução, a CV revê as imagens associadas a cada pod, pelo menos, a cada 24 horas. O CV também monitoriza contentores init e contentores efémeros.

Durante cada revisão, a CV obtém uma lista de imagens associadas a cada Pod. Em seguida, a CV verifica se as informações da imagem cumprem a política da plataforma.

Os registos de CV violam as políticas de plataforma

Quando a CV determina que as imagens violam uma política da plataforma, regista as violações e outras conclusões no Cloud Logging. É escrita uma entrada de registo separada para cada política de plataforma que é violada, para cada podcast.

Quando a CV avalia as imagens de um Pod através de uma política da plataforma, as imagens podem satisfazer algumas verificações e violar outras. O CV produz uma entrada de registo sempre que uma imagem de um pod viola uma verificação. A entrada de registo contém apenas as imagens de pods que violam a política da plataforma. Se todas as imagens satisfizerem todas as verificações, não são produzidas entradas de registo.

O CV continua a registar violações de políticas até que um pod com imagens não conformes com as políticas termine. Quando os pods não conformes com as políticas são terminados durante o intervalo entre validações, as entradas de registo geradas pela CV podem aparecer após a terminação, durante a próxima avaliação da CV.

Os pods não conformes com as políticas devem ser registados, pelo menos, uma vez, mesmo para pods de curta duração.

A CV não termina os grupos de anúncios em execução.

O CV usa um recurso de feed

Para obter informações sobre os pods em execução no seu cluster do GKE, o CV cria um recurso de feed denominado binauthz-cv-cai-feed.

Políticas da plataforma de CV

Para usar a CV, primeiro configure as políticas da plataforma.

As políticas da plataforma são diferentes das políticas de autorização binária antigas, também denominadas políticas de projeto único. Embora o projeto de implementação só possa ter uma política de singleton do projeto antigo, pode configurar várias políticas de plataforma. Cada política de plataforma pode residir num ou mais projetos.

As políticas da plataforma só funcionam com o CV e não suportam a aplicação da autorização binária. Por este motivo, recomendamos que, se quiser usar a aplicação da autorização binária e a monitorização de CV, crie uma política de singleton do projeto para a aplicação e uma política de plataforma para a monitorização.

Por exemplo, suponha que quer configurar a autorização binária para aplicar que as suas imagens tenham uma atestação antes de poderem ser implementadas e também quer garantir que os seus pods em execução estão em conformidade com o mesmo requisito. Para tal, configure uma política de aplicação de singleton de projeto com um atestador. Em seguida, cria uma política de plataforma com uma verificação de atestação de assinatura simples que tem um autenticador baseado na mesma nota e chave pública que o atestador.

As políticas da plataforma são específicas da plataforma. O GKE é a única plataforma suportada.

Pode configurar verificações nas políticas da plataforma. As verificações são agrupadas em um ou mais conjuntos de verificações. Cada conjunto de verificações pode especificar uma ou mais verificações.

As políticas da plataforma podem isentar imagens da avaliação pela CV.

Autorizações necessárias

Para listar ou descrever políticas da plataforma, precisa da função binaryauthorization.policyViewer. Para criar, modificar e eliminar políticas de plataformas, precisa da função binaryauthorization.policyEditor. Para mais informações, consulte o artigo Faça a gestão de políticas da plataforma.

Atualizações de políticas

A atualização de uma política da plataforma substitui a política existente por um descritor de política que fornece no ficheiro YAML. Para adicionar uma nova verificação a uma política de plataforma existente, recomendamos que descreva a política existente, guarde-a num ficheiro YAML, adicione a nova verificação e, em seguida, atualize a política com o ficheiro atualizado.

Várias políticas da plataforma

Pode criar políticas de plataforma no mesmo projeto que o cluster (uma política de plataforma local) ou em qualquer outro projeto.

Uma vez que pode configurar várias políticas de plataforma, atribui um nome a cada uma com um nome de recurso exclusivo. Quando executa um comando da CLI gcloud, refere-se à política da plataforma local através do respetivo ID. Quando faz referência a uma política de plataforma noutro projeto, usa o nome do recurso no seguinte formato: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

Pode escolher a política da plataforma a associar a cada cluster do GKE, quer seja uma política da plataforma local ou uma política num projeto diferente.

Várias verificações por política da plataforma

Pode configurar várias verificações em cada política de plataforma adicionando-as ao bloco checks da política. Para saber mais sobre as verificações específicas que pode configurar, consulte o artigo sobre verificações.

Quando a política da plataforma de CV especifica mais do que uma verificação, as imagens que são avaliadas por uma verificação continuam a ser avaliadas pelas outras verificações.

A autorização binária avalia todas as verificações configuradas na política da plataforma para cada imagem, a menos que a imagem corresponda a um padrão da lista de autorizações de imagens isentas. Para mais informações, consulte o artigo Imagens isentas.

Configuração de projeto único

Pode configurar a CV num único projeto.

Numa configuração de projeto único, a Autorização binária configura automaticamente as funções necessárias no agente de serviço da Autorização binária.

Se os clusters do GKE, as políticas da plataforma associadas aos clusters e os metadados necessários para as verificações residirem no mesmo projeto, não são necessárias funções adicionais de gestão de identidades e acessos (IAM).

Para saber mais sobre a configuração de uma configuração com vários projetos para maior segurança, consulte o artigo Separação de responsabilidades.

Configuração de vários projetos

Quando configura uma configuração de CV com vários projetos com políticas de plataforma, as políticas de plataforma, as imagens, o cluster do GKE e outros tipos de recursos dependentes de CV podem residir num projeto diferente.

Na configuração de vários projetos, é importante conhecer a finalidade de cada projeto e os recursos aos quais o CV precisa de aceder e configurar as funções e as autorizações do IAM necessárias em conformidade.

Como usar o CV

Normalmente, para usar a CV, faz o seguinte:

  1. Decida que verificações quer usar.
  2. Componha uma ou mais políticas de plataforma através de um ficheiro YAML de políticas. O ficheiro especifica as verificações que quer usar.
  3. Crie a política de plataforma. A política pode ser armazenada num projeto à sua escolha.
  4. Escolha se quer ativar o CV em clusters individuais ou numa frota.
  5. Verifique os registos de CV no Registo para eventos.
  6. Reveja os registos e atualize a compilação e outros processos para produzir imagens que satisfaçam as verificações.

Checks

Esta secção descreve as verificações específicas que o CV oferece.

As políticas baseadas em verificações têm o seguinte formato canónico:

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

O campo displayName em checks e checkSets é opcional. É usado apenas quando os registos de CV registam violações de políticas. É omitido em alguns dos exemplos mais adiante neste guia.

Verificação de negação sempre

A verificação de recusa permanente garante que todas as imagens sujeitas a esta verificação falham a avaliação. Sempre que o CV revê os pods em execução com esta verificação, produz uma entrada de registo para cada um dos pods.

Pode combinar a verificação de recusa sempre com listas de autorizações ou vários conjuntos de verificações para garantir que a autorização binária produz sempre registos para pods em determinados casos.

Para usar a verificação de negação sempre, adicione alwaysDeny: true no bloco checks, da seguinte forma:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

Não é possível definir o valor de alwaysDeny como false. Em alternativa, remova a marca de verificação.

Para ver exemplos de como a verificação de recusa sempre pode ser usada, consulte o artigo Use vários conjuntos de verificações.

Verificação da atualidade da imagem

A verificação da atualização da imagem calcula a duração durante a qual uma imagem está a ser apresentada e regista quando a duração excede o limite, maxUploadAgeDays.

No exemplo de YAML da política da plataforma seguinte, os registos de CV mostram pods com imagens que foram carregadas para o repositório a partir do qual foram implementadas há mais de 30 dias.

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

Verificação de atestação de assinatura simples

Pode usar a verificação de atestação de assinatura simples de CV para verificar se cada uma das imagens de um pod tem uma atestação válida e assinada.

Esta verificação é equivalente à avaliação de atestação numa política de aplicação da autorização binária. Pode configurar esta verificação com as mesmas notas e chaves que usou no seu atestador. Recomendamos que use esta verificação em vez da validação contínua antiga (obsoleta).

Segue-se um exemplo de uma política de plataforma com uma verificação de atestação de assinatura simples:

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

Em vez de atestadores de autorização binária, as verificações de atestação de CV têm autenticadores. Especifica os autenticadores diretamente na política, no bloco attestationAuthenticators.

Numa política de plataforma, simpleSigningAttestationCheck pode ter vários attestationAuthenticators e várias chaves em cada pkixPublicKeySet. A verificação é satisfeita quando cada uma das imagens dos pods tem uma atestação válida assinada com qualquer chave no pkixPublicKeySet de qualquer autenticador.

As políticas da plataforma CV são diferentes das políticas de aplicação de singleton de projeto nos seguintes aspetos:

  • As chaves PGP não são suportadas.
  • Não são necessários atestadores. Em alternativa, cria manualmente chaves e, em seguida, descreve uma política da plataforma para obter o ID da chave que usa para criar a atestação.
  • Cria e assina manualmente a carga útil, cria o ficheiro JSON de atestação e cria a atestação através da API Artifact Analysis.
  • Continua a criar uma nota de análise de artefactos, mas não a especifica na política. Em alternativa, o CV procura atestações em todos os projetos indicados no campo containerAnalysisAttestationProjects.
  • As atestações continuam a ser armazenadas em ocorrências da análise de artefactos, mas podem ser armazenadas em mais do que um projeto.
  • Tem de especificar explicitamente um ou mais projetos que contenham atestações usando o nome do recurso projects/ATTESTATION_PROJECT_ID.

O CV não suporta etiquetas de imagem, exceto as especificadas em imagens isentas.

Se as imagens forem implementadas com uma etiqueta de imagem em vez de um resumo, o CV avalia-a primeiro em relação às imagens isentas, uma vez que as listas de autorizações podem incluir etiquetas. Se a imagem não estiver isenta, o CV tenta encontrar o resumo da imagem. Como não existe nenhuma, a imagem viola a verificação.

Verificação SLSA

A verificação SLSA verifica a proveniência especificada pela SLSA das imagens dos pods.

Segue-se um exemplo de uma configuração YAML da política da plataforma de CV:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

Quando a CV revê imagens através desta política da plataforma, verifica o seguinte:

  • As imagens têm de ter sido criadas por um criador fidedigno. O Cloud Build é o único criador fidedigno suportado pela verificação SLSA.

  • O Cloud Build tem de ter gerado as atestações em attestation-project1 ou attestation-project2.

  • As imagens têm de ser criadas com um ficheiro de configuração de nível superior de um dos seguintes repositórios fidedignos:

    • O repositório source.cloud.google.com/my-project/my-source-repo/
    • Quaisquer repositórios em github.com/my-github-user/

  • As imagens em gcr.io/my-images/not-built-by-GCB/ ou nos respetivos subdiretórios (que não foram criadas pelo Cloud Build) estão isentas da verificação, uma vez que a violariam.

Verificação da assinatura do Sigstore

A verificação de assinatura do Sigstore confirma que as imagens foram assinadas com assinaturas do Sigstore.

Esta verificação só suporta imagens alojadas no Artifact Registry. Verifica se é possível validar com êxito qualquer assinatura obtida do Artifact Registry com qualquer chave na política.

A política de plataforma de exemplo seguinte descreve como configurar uma verificação de assinatura do Sigstore:

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

Na política da plataforma, sigstoreSignatureCheck pode ter vários sigstoreAuthorities e várias chaves em cada publicKeySet. A verificação é satisfeita quando cada uma das imagens dos Pods tem uma atestação válida assinada com qualquer chave no qualquer publicKeySet do autenticador.

Verificação de diretório fidedigno

A verificação de diretórios fidedignos verifica se as imagens dos Pods residem num dos diretórios fidedignos fornecidos que especifica numa política da plataforma.

Quando usar esta verificação, recomendamos que também salvaguarde os repositórios que lista como diretórios fidedignos na sua política contra acesso não autorizado.

A política de plataforma de exemplo seguinte descreve como configurar uma verificação de diretório fidedigno:

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

Na política de plataformas de exemplo, trustedDirPatterns apresenta os diretórios fidedignos. Se todas as imagens dos Pods residirem nos diretórios indicados, estão em conformidade com a política. As imagens de pods que não residam nos diretórios indicados violam a política, e o CV regista as violações.

Verificação de vulnerabilidades

A verificação de vulnerabilidades usa a análise de vulnerabilidades do Artifact Analysis para verificar se as imagens dos pods contêm vulnerabilidades. Isto inclui novas vulnerabilidades identificadas pela análise de vulnerabilidades desde a implementação do pod. Na verificação de vulnerabilidades, pode configurar os limites do nível de gravidade das vulnerabilidades e vulnerabilidades específicas (como CVEs). As imagens com vulnerabilidades que violam a verificação de vulnerabilidades são registadas no registo.

Para usar esta verificação, primeiro tem de ativar a procura de vulnerabilidades na análise de artefactos.

A seguinte configuração da política de plataforma de exemplo contém uma verificação de vulnerabilidades:

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

No exemplo, maximumUnfixableSeverity e maximumFixableSeverity definem os níveis de gravidade do Common Vulnerability Scoring System (CVSS) associados a qualquer vulnerabilidade que a Artifact Analysis possa identificar. Além disso, blockedCves lista exposições de vulnerabilidades comuns (CVEs) específicas. Se uma vulnerabilidade identificada exceder um dos níveis de gravidade especificados ou corresponder a um dos CVEs indicados em blockedCves e não corresponder a um dos CVEs indicados em allowedCves, o CV regista uma entrada no registo.

Valide as políticas atualizadas

Depois de atualizar uma política da plataforma de CV, recomendamos vivamente que valide se a autorização binária e a CV continuam a funcionar como esperado.

Valide a configuração

Para verificar a sua configuração, inspecione as políticas únicas do projeto de autorização binária e as políticas da plataforma de CV.

Valide a operação

Para validar se a autorização binária e a CV estão a funcionar como esperado, pode implementar pods de teste e, em seguida, verificar as entradas de autorização binária no registo.

Exclua imagens com listas de autorizações

Quando cria uma política de plataforma, pode isentar imagens de verificações adicionando os respetivos URLs a uma lista de autorizações. Uma lista de autorizações ao nível da política isenta as imagens de toda a política. Uma lista de autorizações ao nível do conjunto de verificações isenta-se do conjunto de verificações e aplica-se apenas quando esse conjunto de verificações é avaliado. Uma lista de autorizações numa verificação isenta apenas as imagens dessa verificação.

Os padrões da lista de autorizações são padrões que correspondem a um ou mais URLs de imagens. Um padrão da lista de autorizações pode ser um dos seguintes:

  • Um prefixo do nome da imagem que termina com o caráter universal * ou **.
  • Apenas um nome de imagem, sem etiqueta nem resumo.
  • Um nome de imagem com uma etiqueta (ou um prefixo de etiqueta com o caráter universal *).
  • Um nome de imagem com um resumo.
  • Um nome de imagem com uma etiqueta e um resumo.

Seguem-se alguns exemplos de padrões de lista de autorizações:

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corresponde exatamente a um nome, uma etiqueta e um resumo de imagem.
  • us-central1.pkg.dev/my-project/my-image:latest corresponde ao nome e à etiqueta, com qualquer resumo (ou sem resumo).
  • us-central1.pkg.dev/my-image:foo* corresponde ao nome e ao prefixo da etiqueta (como myimage:foo e myimage:foobar), com qualquer resumo (ou sem resumo).
  • us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corresponde ao nome e ao resumo, com qualquer etiqueta (ou sem etiqueta).
  • us-central1.pkg.dev/my-project/my-image corresponde ao nome, com qualquer etiqueta e/ou resumo.

É possível usar os carateres universais * e ** para fazer corresponder qualquer nome com um determinado prefixo. * corresponde a sufixos que não incluem /. ** corresponde a sufixos que podem incluir /, mas ** só pode ser usado após um /. Tenha em atenção que não é possível usar * e ** com etiquetas ou resumos.

Por exemplo:

  • us-central1.pkg.dev/my-project/my-image* corresponde a us-central1.pkg.dev/myproject/my-image, us-central1.pkg.dev/myproject/my-image1 e us-central1.pkg.dev/myproject/my-image2, com qualquer etiqueta e/ou resumo.
  • us-central1.pkg.dev/my-project/** corresponde a us-central1.pkg.dev/myproject/my-image e us-central1.pkg.dev/my-project/some-directory/other-image, com qualquer etiqueta e/ou resumo.

Tenha em atenção que os prefixos de nomes e os prefixos de etiquetas não podem estar vazios. Assim, * ou ** sozinhos não são um padrão válido, tal como us-central1.pkg.dev/my-image:*.

gkePolicy-level exemption

O exemplo seguinte mostra como isentar imagens ao nível da política da plataforma. Todas as imagens nos diretórios exempt-images1 e exempt-images2, bem como nos respetivos subdiretórios, são excluídas da monitorização de CV.

gkePolicy:
  imageAllowlist:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

Na política, as imagens indicadas em imageAllowlist estão isentas de todos os conjuntos de verificações (checkSets) indicados em gkePolicy.

checkSet-level exemption

O exemplo seguinte mostra como isentar imagens ao nível do conjunto de verificações:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

Na política, as imagens apresentadas em imageAllowlist estão isentas de todas as verificações apresentadas em checkSets.

isenção ao nível das verificações

O exemplo seguinte mostra como isentar imagens ao nível da verificação:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

Use vários conjuntos de verificações

Uma política baseada na verificação de CV pode conter mais do que um conjunto de verificações. A CV avalia um conjunto de verificações sempre que avalia a política. Pode considerar os conjuntos de verificações como subpolíticas que devem ser avaliadas em diferentes situações. Por exemplo, se quiser aplicar verificações diferentes em ambientes de desenvolvimento do que em ambientes de produção, pode colocar as verificações para cada ambiente num conjunto de verificações separado, um que é avaliado apenas no ambiente de desenvolvimento e outro que é avaliado em produção.

Cada conjunto de verificações tem âmbito num espaço de nomes do Kubernetes ou numa conta de serviço do Kubernetes. O âmbito determina a que Pods se aplica o conjunto de verificações.

Quando um conjunto de verificações é configurado com um âmbito, aplica-se apenas aos pods em execução nesse âmbito.

Quando um conjunto de verificações não tem âmbito, é denominado conjunto de verificações predefinido, o que significa que as verificações se aplicam a todos os pods, independentemente do respetivo espaço de nomes do Kubernetes ou âmbito da conta de serviço.

A maioria das políticas de exemplo nos guias de CV usa apenas um conjunto de verificações predefinido.

A seguinte configuração de política de exemplo configura três conjuntos de verificações:

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

Na configuração de exemplo, o primeiro conjunto de verificações tem o âmbito de prod-namespace, pelo que as respetivas verificações afetam apenas os pods em execução nesse âmbito. O segundo conjunto de verificações tem o âmbito definido para dev-namespace, pelo que as respetivas verificações afetam apenas os pods em execução nesse âmbito. O terceiro conjunto de verificações é um conjunto de verificações predefinido. As respetivas verificações aplicam-se a todos os pods no cluster em execução fora dos âmbitos prod-namespace e dev-namespace.

Quando a CV avalia o conjunto de verificações denominado Prod check set, verifica o seguinte para as imagens dos pods em execução no espaço de nomes do prod-namespace Kubernetes:

  • As imagens são armazenadas no diretório prod-images fidedigno.
  • As imagens foram carregadas nos últimos 30 dias.

Quando o CV avalia o conjunto de verificações denominado Dev check set, avalia os pods em execução no espaço de nomes do Kubernetes dev-namespace, verificando se as imagens no pod provêm do diretório dev-images.

A verificação predefinida funciona como uma solução abrangente. A verificação de negação sempre garante que o CV regista todos os pods que estão a ser executados em qualquer outro espaço de nomes.

Para usar uma conta de serviço do Kubernetes como o âmbito de um conjunto de verificações, substitua a chave kubernetesNamespace no exemplo por kubernetesServiceAccount. O valor tem o formato my-namespace:my-service-account.

Verifique se os âmbitos definidos têm as seguintes regras:

  • Só pode existir um conjunto de verificações por âmbito numa política de plataforma.

  • Se uma política contiver conjuntos de verificação com âmbito do espaço de nomes e com âmbito da conta de serviço, o conjunto de verificação com âmbito da conta de serviço tem de ser apresentado primeiro, seguido do conjunto de verificação com âmbito do espaço de nomes.

  • Só pode existir um conjunto de verificações predefinido, e este tem de ser o último da lista.

Se uma política de plataforma contiver conjuntos de verificações, tem de conter, pelo menos, um conjunto de verificações predefinido. É permitida uma política de plataforma sem conjuntos de verificações, mas, uma vez que não existem verificações a violar, o CV não produz entradas de registo.

CV antigo

Esta secção descreve as políticas de CV antigas. Se for um utilizador novo da CV, recomendamos que use a CV com políticas baseadas em verificações.

Para suportar utilizadores de CV antigos, o CV pode ser ativado em projetos que executam o GKE. Em seguida, o CV usa a política de aplicação da autorização binária para verificar todos os pods em execução em todos os clusters no projeto, incluindo clusters para os quais a aplicação da autorização binária não está ativada.

Saiba como usar o CV antigo (descontinuado) e ver eventos de CV antigos no Cloud Logging.

O que se segue?