Visão geral da validação contínua

A validação contínua (CV, na sigla em inglês) é um recurso de autorização binária que permite monitorar pods executados no Google Kubernetes Engine (GKE) para garantir que as imagens de contêiner associadas continuem a obedecer à verificação de autorização binária baseada em políticas de plataforma especificadas.

Quando a CV determina que os pods violam as políticas da plataforma, ela registra as violações no Cloud Logging.

A CV por políticas de plataforma substitui a validação contínua legada.

Por que usar a CV?

Embora a aplicação da autorização binária forneça validações únicas ao implantar imagens de contêiner, a CV monitora continuamente que as imagens associadas aos pods em execução continuam em conformidade com as políticas.

Por isso, quando você ativa a aplicação da autorização binária e a CV com políticas baseadas em verificação, garante que a conformidade da política seja validada em todo o ciclo de vida de orquestração.

A CV é útil nos cenários de:

Alterações na política: quando você atualiza suas políticas de aplicação do singleton da autorização binária, ela valida apenas imagens que são implantadas após a atualização. Os pods que já estão em execução não são afetados. Eles continuam em execução mesmo que a autorização binária, usando a política atualizada, bloqueie a implantação da mesma imagem.

Por isso, ao atualizar a política de projeto singleton de autorização binária, recomendamos que você também crie ou atualize uma política de plataforma de CV para corresponder à política de projeto singleton. Dessa forma, a CV informa sobre a execução de pods que violam as políticas atualizadas.
Monitorar metadados de imagens: a CV oferece verificações específicas para alterações em metadados de imagens, incluindo:
- Atestados: os registros de CV quando os atestados nas imagens dos pods não são mais válidos.
- Atualização: a CV registra quando detecta que as imagens dos pods não estão mais atualizadas.
- Procedência: a CV pode verificar se as imagens dos pods foram criadas com um criador confiável, usando configurações de versão que residem em um repositório de origem confiável.
- Assinaturas Sigstore: registra CV quando as imagens dos pods não têm uma assinatura válida do Sigstore.
- Diretório confiável: os registros de CV quando as imagens dos pods residem em um diretório de repositório que não está listado na política de plataforma.
- Vulnerabilidades: registra quando as vulnerabilidades são identificadas nas imagens dos pods.
Monitoramento de simulação: quando você ativa a simulação, a autorização binária permite que todas as imagens sejam implantadas. Ao ativar a CV com uma política de plataforma que corresponda à política do singleton, a CV registra regularmente imagens que violam a política da plataforma.
Monitoramento de acesso de emergência: quando você implanta pods usando o breakglass, a autorização binária ignora a aplicação da política de singleton do projeto e registra um único evento nos registros de auditoria do Cloud. No entanto, ao usar uma política de plataforma correspondente, a CV continua a registrar regularmente pods que violam a política, incluindo aqueles implantados com o uso de acesso de emergência.

Como a CV funciona

Para usar a CV, é preciso ativá-la nos clusters do GKE.

Depois que você implanta imagens no cluster, a CV monitora os pods associados para garantir que estejam em conformidade com a política da plataforma baseada em verificação.

A CV não é compatível com tags de imagem, exceto as especificadas em imagens isentas.

A CV analisa regularmente os pods em execução

Para monitorar os pods em execução, a CV analisa as imagens associadas a cada pod pelo menos a cada 24 horas. A CV também monitora contêineres init.

Durante cada revisão, a CV recupera uma lista de imagens associadas a cada pod. Em seguida, a CV verifica se as informações da imagem atendem à política da plataforma.

A CV registra violações de políticas da plataforma

Quando a CV determina que as imagens violam uma política da plataforma, ela registra as violações e outras descobertas no Cloud Logging. Uma entrada de registro separada é gravada para cada política da plataforma que é violada, para cada pod.

Quando a CV avalia as imagens de um pod usando uma política de plataforma, as imagens podem satisfazer algumas verificações e violar outras. Uma entrada de registro é produzida sempre que uma imagem de um pod viola uma ou mais verificações. A entrada de registro contém apenas as imagens que violam a política da plataforma. Se todas as imagens atenderem a todas as verificações, nenhuma entrada de registro será produzida.

Até que um pod com imagens não compatíveis com a política seja encerrado, a CV continua a registrar violações da política. Os pods que não estão de acordo com a política e encerrados durante o intervalo entre as verificações são registrados durante a próxima análise de CV.

A CV não encerra os pods em execução.

A CV usa um recurso de feed

Para recuperar informações sobre pods em execução no cluster do GKE, a CV cria um recurso de feed chamado binauthz-cv-cai-feed.

Políticas da plataforma de CV

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

As políticas de plataforma são diferentes das políticas de autorização binária legadas, também chamadas de políticas de singleton de projeto. Embora o projeto de implantação possa ter apenas uma política legada de projeto-singleton, é possível configurar várias políticas de plataforma. Cada política de plataforma pode residir em um ou mais projetos.

As políticas de plataforma só funcionam com o CV e não são compatíveis com a aplicação da autorização binária. Por isso, recomendamos que, se você quiser usar a aplicação da autorização binária e o monitoramento de CV, crie uma política de singleton de projeto e uma política de plataforma para monitoramento.

Por exemplo, suponha que você queira configurar a autorização binária para impor que suas imagens tenham um atestado antes de serem implantadas e que você também queira garantir que seus pods em execução estejam em conformidade com os mesmos requisitos. Para fazer isso, configure uma política de aplicação do projeto singleton com um atestador. Em seguida, crie uma política de plataforma com uma verificação de atestado de assinatura simples que tenha um autenticador com base na mesma nota e chave pública que o atestador.

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

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

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

Permissões necessárias

Para listar ou descrever políticas de plataforma, você precisa do papel binaryauthorization.policyViewer. Para criar, modificar e excluir políticas de plataforma, você precisa do papel binaryauthorization.policyEditor. Para mais informações, consulte Gerenciar políticas de plataforma.

Atualização nas políticas

Atualizar uma política da plataforma substitui a política atual por um descritor de política que você fornece no arquivo YAML. Para adicionar uma nova verificação a uma política de plataforma, recomendamos que você descreva a política existente, salve-a em um arquivo YAML, adicione a nova verificação e, em seguida, atualize a política usando o arquivo atualizado.

Várias políticas de plataforma

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

Como é possível configurar várias políticas de plataforma, nomeie cada uma com um nome de recurso exclusivo. Ao executar um comando da CLI gcloud, indique à política da plataforma local usando o ID dela. Ao se referir a uma política de plataforma em outro projeto, use o nome do recurso, no seguinte formato: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

É possível escolher qual política de plataforma associar a cada cluster do GKE, seja uma política de plataforma local ou em um projeto diferente.

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

É possível configurar várias verificações em cada política de plataforma adicionando-as ao bloco checks da política. Para saber mais sobre verificações específicas que podem ser configuradas, consulte Verificações.

Quando a política da plataforma de CV especificar mais de uma verificação, as imagens avaliadas por uma verificação continuarão sendo avaliadas pelas outras.

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 de lista de permissões de imagens isentas. Para mais informações, consulte Imagens isentas.

Configuração de projeto único

Você pode configurar a CV em um único projeto.

Em uma configuração de projeto único, a autorização binária configura automaticamente os papéis necessários no agente de serviço da autorização binária.

Se os clusters do GKE, as políticas da plataforma vinculadas aos clusters e os metadados exigidos pelas verificações estiverem no mesmo projeto, nenhum papel extra do Identity and Access Management (IAM) será obrigatório.

Para saber mais sobre como definir uma configuração de vários projetos para aumentar a segurança, consulte Separação de conceitos.

Configuração de vários projetos

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

Na configuração de vários projetos, é importante saber a finalidade de cada projeto e os recursos que a CV precisa para acessar e configurar os papéis e permissões necessários do IAM.

Como usar a CV

Para usar a CV, você geralmente faz o seguinte:

Decida quais verificações você quer usar.
Crie uma ou mais políticas de plataforma usando um arquivo YAML de política. O arquivo especifica quais verificações você quer usar.
Crie a política da plataforma. A política pode ser armazenada em um projeto de sua escolha.
Escolha se você quer ativar a CV em clusters individuais ou em uma frota.
Verifique se há eventos nos registros de CV no Logging.
Revise os registros e atualize seu build e outros processos para produzir imagens que atendam às verificações.

Aceita cheque

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

As políticas baseadas em verificação 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. Ele é usado apenas quando a CV registra violações da política. Ele é omitido em alguns dos exemplos mais adiante neste guia.

Verificação de negação

A verificação "negar sempre" garante que todas as imagens sujeitas a essa verificação falhem. Cada vez que a CV analisa os pods em execução com essa verificação, ela produz uma entrada de registro para cada um dos pods.

É possível combinar a verificação "negar sempre" com as listas de permissões ou vários conjuntos de verificação para garantir que a autorização binária sempre gere registros para pods em determinados casos.

Para usar a verificação "negar sempre", adicione alwaysDeny: true ao bloco checks da seguinte maneira:

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

O valor de alwaysDeny não pode ser definido como false. Em vez disso, remova a marca.

Para ver exemplos de como a verificação de negação sempre pode ser usada, consulte Usar vários conjuntos de verificação.

Verificação de atualização de imagens

A verificação de atualização de imagem calcula a duração da execução de uma imagem e registra quando ela ultrapassa o limite maxUploadAgeDays.

No YAML de política da plataforma de exemplo a seguir, a CV registra os pods com imagens que foram enviadas para o repositório de onde foram implantadas há mais de 30 dias.

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

Verificação de atestado de assinatura simples

Use a verificação de atestado de assinatura simples da CV para verificar se cada uma das imagens de um pod tem um atestado válido.

Essa verificação é equivalente à avaliação de atestado em uma política de aplicação da autorização binária. É possível configurar essa verificação com as mesmas notas e chaves usadas no atestador. Recomendamos que você use essa verificação em vez da validação contínua legada.

Veja a seguir um exemplo de uma política de plataforma com uma verificação simples de atestado de assinatura:

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 atestado CV têm autenticadores. Você especifica autenticadores diretamente na política, no bloco attestationAuthenticators.

Em uma política da plataforma, simpleSigningAttestationCheck pode ter vários attestationAuthenticators e várias chaves em cada pkixPublicKeySet. A verificação é realizada quando cada uma das imagens dos pods tem um atestado válido assinado com qualquer chave em qualquer pkixPublicKeySet do autenticador.

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

As chaves PGP não são compatíveis.
Atestadores não são necessários. Em vez disso, crie manualmente chaves e descreva uma política da plataforma para recuperar o ID da chave que será usado para criar o atestado.
Você cria e assina manualmente o payload, cria o arquivo JSON de atestado e cria o atestado usando a API Artifact Analysis.
Você ainda cria uma nota do Artifact Analysis, mas não a especifica na política. Em vez disso, o CV procura atestados em cada projeto listado no campo containerAnalysisAttestationProjects.
Os atestados ainda são armazenados em ocorrências do Artifact Analysis, mas podem ser armazenados em mais de um projeto.
É preciso especificar explicitamente um ou mais projetos que contêm atestados usando o nome do recurso projects/ATTESTATION_PROJECT_ID.

A CV não é compatível com tags de imagem, exceto aquelas especificadas em imagens isentas.

Se as imagens forem implantadas com uma tag de imagem em vez de um resumo, a CV a avaliará primeiro em relação a imagens isentas, já que as listas de permissões podem incluir tags. Se a imagem não estiver isenta, a CV tentará encontrar o resumo da imagem. Como não há uma imagem, a imagem viola a verificação.

Verificação da SLSA

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

Veja a seguir um exemplo de 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 analisa as imagens usando essa política da plataforma, ela verifica o seguinte:

As imagens precisam ter sido criadas por um construtor confiável. O Cloud Build é o único builder confiável compatível com a verificação da SLSA.
O Cloud Build precisa ter gerado os atestados em attestation-project1 ou attestation-project2.
As imagens precisam ser criadas usando um arquivo de configuração de nível superior de um dos seguintes repositórios confiáveis:
- O repositório source.cloud.google.com/my-project/my-source-repo/
- Todos os repositórios em github.com/my-github-user/
As imagens em gcr.io/my-images/not-built-by-GCB/ ou nos subdiretórios que não foram criados pelo Cloud Build estão isentas da verificação porque seriam violadas.

Verificação de assinatura do Sigstore

A verificação de assinatura do Sigstore verifica se as imagens foram assinadas usando assinaturas do Sigstore.

Essa verificação aceita apenas imagens hospedadas no Artifact Registry. Ela confere se alguma assinatura buscada no Artifact Registry pode ser verificada por qualquer chave da política.

O exemplo de política de plataforma a seguir 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árias sigstoreAuthorities e várias chaves em cada publicKeySet. A verificação é realizada quando cada uma das imagens dos pods tem um atestado válido assinado com qualquer chave em qualquer publicKeySet do autenticador.

Verificação de diretório confiável

A verificação de diretório confiável verifica se as imagens dos pods residem em um dos diretórios confiáveis fornecidos que você especificou em uma política da plataforma.

Ao usar essa verificação, recomendamos que você também proteja os repositórios listados como diretórios confiáveis na sua política contra o acesso não autorizado.

O exemplo de política de plataforma a seguir descreve como configurar uma verificação de diretório confiável:

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"

No exemplo de política da plataforma, trustedDirPatterns lista os diretórios confiáveis. Se todas as imagens dos pods estiverem nos diretórios listados, eles estarão em conformidade com a política. As imagens de pods que não residem nos diretórios listados violam a política, e a CV registra as violações.

Verificação de vulnerabilidades

A verificação de vulnerabilidades usa a verificação de vulnerabilidades do Artifact Analysis para verificar se as imagens dos pods contêm vulnerabilidades. Isso inclui novas vulnerabilidades identificadas pela verificação de vulnerabilidades desde que o pod foi implantado. Na verificação de vulnerabilidades, é possível configurar limites de nível de gravidade da vulnerabilidade e vulnerabilidades específicas (como CVEs, na sigla em inglês). As imagens com vulnerabilidades que violam a verificação de vulnerabilidades são registradas no Logging.

Para usar essa verificação, primeiro é necessário ativar a verificação de vulnerabilidades no Artifact Analysis.

O exemplo de configuração da política de plataforma a seguir 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 Sistema de pontuação de vulnerabilidade comum (CVSS, na sigla em inglês) associados a qualquer vulnerabilidade que o Artifact Analysis possa identificar. Além disso, blockedCves lista exposições comuns de vulnerabilidade (CVEs, na sigla em inglês) específicas. Se uma vulnerabilidade identificada exceder um dos níveis de gravidade especificados ou corresponder a um dos CVEs listados em blockedCves e não corresponder a um dos CVEs listados em allowedCves, a CV registra uma entrada para o Logging.

Validar políticas atualizadas

Depois de atualizar uma política da plataforma de CV, é altamente recomendável que você confirme se a autorização binária e a CV continuam funcionando conforme o esperado.

Validar sua configuração

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

Validar operação

Para validar o funcionamento esperado da autorização binária e da CV, implante pods de teste e verifique as entradas de autorização binária no Logging.

Imagens isentas com listas de permissões

Ao criar uma política de plataforma, você pode isentar imagens de verificações adicionando os URLs delas a uma lista de permissões. Uma lista de permissões no nível da política isenta imagens de toda a política. Uma lista de permissões no nível do conjunto de verificação isenta do conjunto de verificação e se aplica apenas quando esse conjunto de verificação é avaliado. Uma lista de permissões em uma verificação isenta imagens somente dessa verificação.

Os padrões de lista de permissões são padrões que correspondem a um ou mais URLs de imagem. Um padrão de lista de permissões pode ser um dos seguintes:

Um prefixo de nome da imagem que termina com o caractere curinga * ou **.
Apenas um nome de imagem, sem tag ou resumo.
Um nome de imagem com uma tag (ou prefixo de tag com o caractere curinga *).
Um nome de imagem com um resumo.
Um nome de imagem com uma tag e um resumo.

Veja a seguir exemplos de padrões de lista de permissões:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corresponde a um nome de imagem, tag e resumo de imagem exatos.
us-central1.pkg.dev/my-project/my-image:latest corresponde ao nome e à tag, com qualquer resumo (ou nenhum resumo).
us-central1.pkg.dev/my-image:foo* corresponde ao prefixo do nome e da tag (como myimage:foo e myimage:foobar), com qualquer resumo (ou nenhum resumo).
us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corresponde ao nome e resumo por e-mail, com qualquer tag (ou nenhuma tag).
us-central1.pkg.dev/my-project/my-image corresponde ao nome, com qualquer tag e/ou resumo.

Os caracteres curinga * e ** podem ser usados para 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 depois de um /. Observe que * e ** não podem ser usados com tags ou resumos.

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 tag 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 tag e/ou resumo.

Os prefixos de nome e de tag não podem ficar em branco. Portanto, * ou ** sozinho não é um padrão válido, e us-central1.pkg.dev/my-image:* não é.

Isenção no nível do gkePolicy

O exemplo a seguir mostra como isentar imagens no nível de uma política da plataforma. Todas as imagens nos diretórios exempt-images1 e exempt-images2 e respectivos subdiretórios são excluídas do monitoramento da CV.

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

Na política, as imagens listadas em imageAllowlist são isentas de todos os conjuntos de verificação (checkSets) listados em gkePolicy.

Isenção no nível do checkSet

O exemplo a seguir mostra como isentar imagens no nível do conjunto de verificação:

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

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

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

O exemplo a seguir mostra como isentar imagens no nível da verificação:

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

Usar vários conjuntos de verificação

Uma política baseada em verificação CV pode conter mais de um conjunto de verificação. A CV avalia um conjunto de verificações a cada vez que avalia a política. Pense nos conjuntos de verificação como subpolíticas que precisam ser avaliadas em diferentes situações. Por exemplo, se você quiser aplicar verificações diferentes em ambientes de desenvolvimento e em ambientes de produção, coloque as verificações de cada ambiente em um conjunto de verificações separado, que será avaliado somente no ambiente de desenvolvimento e que é avaliado na produção.

Cada conjunto de verificação tem como escopo um namespace do Kubernetes ou uma conta de serviço do Kubernetes. O escopo determina a quais pods o conjunto de verificação se aplica.

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

Quando um conjunto de verificações não tem escopo, ele é chamado de conjunto de verificação padrão, o que significa que as verificações se aplicam a todos os pods, independentemente do namespace do Kubernetes ou do escopo da conta de serviço.

A maioria das políticas de exemplo nos guias do CV usa apenas um conjunto de verificação padrão.

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

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ção tem o escopo prod-namespace. Portanto, as verificações afetam somente os pods em execução nesse escopo. O segundo conjunto de verificações tem o escopo dev-namespace. Portanto, as verificações afetam somente os pods em execução nesse escopo. O terceiro conjunto de verificação é um conjunto de verificação padrão. As verificações se aplicam a todos os pods no cluster em execução fora dos escopos prod-namespace e dev-namespace.

Quando a CV avalia o conjunto de verificação chamado Prod check set, ele verifica o seguinte para imagens de pods em execução no namespace prod-namespace do Kubernetes:

As imagens são armazenadas no diretório confiável prod-images.
As imagens foram enviadas nos últimos 30 dias.

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

O conjunto de verificação padrão funciona como um "pega-tudo". A verificação "Sempre negar" garante que o CV registre todos os pods em execução em qualquer outro namespace.

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

Os escopos do conjunto de verificação têm as seguintes regras:

Só pode haver um conjunto de verificações por escopo em uma política da plataforma.
Se uma política tiver os conjuntos de verificação com escopo de namespace e de conta de serviço, o conjunto de verificação com escopo de conta de serviço precisa ser listado primeiro, seguido pelo conjunto de verificação com escopo de namespace.
Só pode haver um conjunto de verificação padrão, que precisa ser listado por último.

Se uma política de plataforma contiver algum conjunto de verificação, ela precisará conter pelo menos um conjunto de verificação padrão. Uma política da plataforma sem conjuntos de verificação é permitida, mas como não há verificações para violar, a CV não produz entradas de registro.

CV legada

Esta seção descreve as políticas de CV legadas. Se você é novo no CV, recomendamos que use as políticas de plataforma da CV.

Para oferecer suporte a usuários legados de CVs, ele pode ser ativado em projetos que executam o GKE. Em seguida, a 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 aqueles em que a aplicação da autorização binária não está ativada.

Saiba como usar a CV legada e visualizar eventos de CV legadas no Cloud Logging.