Configurar uma política usando a CLI gcloud

Observação: neste documento ou seção, há menções a um ou mais termos que o Google considera desrespeitosos ou ofensivos. Os termos são usados porque são palavras-chave no software descrito no documento.

Os termos: whitelist

Nesta página, fornecemos instruções para configurar uma política de autorização binária usando a Google Cloud CLI. Como alternativa, você também pode executar essas tarefas usando o Console do Google Cloud ou a API REST. Esta etapa faz parte da configuração da autorização binária.

Para configurar uma política usando a ferramenta de linha de comando, exporte a política atual como um arquivo YAML. Depois de modificar o arquivo, você pode importá-lo para atualizar a política, conforme descrito posteriormente neste guia. Para mais informações sobre o formato YAML da política, consulte Referência do YAML de políticas.

Observação: esta página descreve como configurar uma política para plataformas baseadas em contêiner compatíveis com a autorização binária, incluindo o Google Kubernetes Engine (GKE), clusters do GKE, Cloud Run e Anthos Service Mesh. As configurações de política, como o tipo e os parâmetros da regra e o formato do parâmetro, podem variar de acordo com as plataformas que você usa. Por isso, cada seção desta página explica as plataformas a que as configurações se aplicam. Verifique se as configurações que você usa são compatíveis com suas plataformas.

Antes de começar

1. Ative a autorização binária.
2. Crie um cluster.
3. Se você pretende usar atestados, recomendamos criar atestadores antes de configurar a política. É possível criar atestadores usando uma ferramenta de linha de comando ou pelo Console do Google Cloud.

4. Defina o ID do projeto em que você ativou a autorização binária:

   PROJECT_ID=PROJECT_ID
   gcloud config set project ${PROJECT_ID}
   

Exportar o arquivo YAML da política

Esta seção se aplica aos clusters do GKE, o GKE, Cloud Run e Anthos Service Mesh.

Para atualizar a política, primeiro exporte-a para um arquivo YAML local da seguinte maneira:

gcloud container binauthz policy export > /tmp/policy.yaml

Por padrão, o conteúdo do arquivo é semelhante ao seguinte:

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: EVALUATION_MODE
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

Para modificar a política, edite o arquivo e adicione ou atualize seções, conforme descrito mais adiante neste guia. Depois de salvar o arquivo, importe a política.

Observação: a lista admissionWhitelistPatterns pode conter caminhos de imagem recomendados adicionais por padrão.

Observação: não recomendamos mais usar admissionWhitelistPatterns para colocar imagens do sistema gerenciadas pelo Google na lista de permissões, conforme mostrado acima. Para colocar as imagens do sistema gerenciadas pelo Google na lista de permissões, defina globalPolicyEvaluationMode como ENABLE. Isso permite que o Google gerencie a lista de permissões de imagens do sistema que o Google Kubernetes Engine (GKE) usa. O Google atualiza essa lista de permissões a cada versão do GKE. Se você não ativar a configuração, precisará gerenciar a lista de permissões por conta própria. Consulte globalPolicyEvaluationMode para ver detalhes.

Definir a regra padrão

Esta seção se aplica aos clusters do GKE, o GKE, Cloud Run e Anthos Service Mesh.

Uma regra é a parte de uma política que define restrições que as imagens de contêiner precisam atender antes de serem implantadas. A regra padrão define restrições que se aplicam a todas as imagens não isentas que não têm a própria regra específica do cluster. Todas as políticas precisam ter uma regra padrão.

A regra padrão é definida no nó defaultAdmissionRule no arquivo YAML da política. Para mais informações sobre as partes desta regra, consulte ADMISSION_RULE na Referência da política de YAML. Para exemplos de regras padrão, consulte Políticas de exemplo.

Para definir a regra padrão, edite o nó defaultAdmissionRule no arquivo policy.yaml conforme necessário:

defaultAdmissionRule:
  evaluationMode: EVALUATION_MODE
  enforcementMode: ENFORCEMENT_MODE
  requireAttestationsBy:
  - ATTESTOR
  - ...

Substitua:

• EVALUATION_MODE: o modo de avaliação especifica o tipo de restrição que o aplicador de autorização binária aplica no momento da implantação. Substitua EVALUATION_MODE por um dos seguintes:

  • ALWAYS_ALLOW: permite que todas as imagens sejam implantadas.
  • ALWAYS_DENY: impede a implantação de todas as imagens.
  • REQUIRE_ATTESTATION: permite que uma imagem seja implantada se ela tiver um ou mais atestados que possam ser verificados por todos os atestadores adicionados a essa regra. No momento da implantação, o aplicador verifica o atestado usando os atestadores que você adiciona à lista ATTESTOR nesta regra. Para saber como criar atestadores, consulte Como criar atestadores. Se você especificar REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttestationsBy contendo pelo menos um atestador. Para saber como criar atestadores, consulte Como criar atestadores.

• ENFORCEMENT_MODE: o modo de aplicação especifica como o implementador responde quando uma imagem viola uma regra. Substitua ENFORCEMENT_MODE por um dos seguintes:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia imagens que violam a regra e informações de registro sobre a violação dos registros de auditoria do Cloud (padrão).
  • DRYRUN_AUDIT_LOG_ONLY: permite que todas as imagens sejam implantadas, com exceção das informações de aplicação do registro, incluindo informações sobre violações, nos registros de auditoria do Cloud.

• ATTESTOR: se você definir EVALUATION_MODE como REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttesationsBy. No bloco, você lista um ou mais atestadores por ID do recurso. O código do recurso tem este formato:

  projects/PROJECT_ID/attestors/ATTESTOR_NAME

  Para saber mais sobre como criar atestadores, consulte Como criar atestadores.

Observação: não recomendamos o uso do modo de avaliação ALWAYS_ALLOW na regra padrão. Isso permite que todas as imagens sejam implantadas, a menos que não satisfaçam a uma regra específica do cluster ou outra regra específica na política.

Gerenciar imagens isentas

Esta seção se aplica aos clusters do GKE, o GKE, Cloud Run e Anthos Service Mesh.

Uma imagem isenta é uma imagem isenta de regras da política. A autorização binária sempre permite a implantação de imagens isentas.

Para especificar imagens isentas, liste os caminhos de registro em admissionWhitelistPatterns. O caminho se refere ao Container Registry ou outro registro de imagem. No momento da implantação, a autorização binária isenta a lista de imagens especificadas por admissionWhitelistPatterns após as imagens especificadas pela política do sistema.

Para adicionar uma imagem isenta, adicione um nó namePattern em uma lista admissionWhitelistPatterns no arquivo policy.yaml:

admissionWhitelistPatterns:
- namePattern: MATCHING_PATTERN

Substitua MATCHING_PATTERN pelo caminho para uma única imagem em seu registro por correspondência exata ou para qualquer imagem que corresponda a um padrão usando o símbolo curinga (*, **).

Cloud Run

Esta seção se aplica ao Cloud Run.

Não é possível especificar diretamente nomes de imagens que contenham uma tag. Por exemplo, não é possível especificar IMAGE_PATH:latest.

Se você quiser especificar nomes de imagens que contenham tags, especifique o nome da imagem usando um padrão de caracteres curinga conforme mostrado a seguir:

• * para todas as versões de uma única imagem; por exemplo, us-docker.pkg.dev/myproject/container/hello@*
• ** para todas as imagens em um projeto; por exemplo, us-docker.pkg.dev/myproject/**

É possível usar nomes de caminho para especificar um resumo no formato IMAGE_PATH@DIGEST.

Modo de avaliação da política do sistema

Esta seção se aplica aos clusters do GKE e o GKE.

O modo de avaliação da política do sistema é uma configuração que faz com que a autorização binária avalie uma política do sistema antes de avaliar a política configurada. O Google gerencia a política do sistema, que isenta uma lista de imagens de sistema mantidas pelo Google que o GKE usa. As imagens listadas na política do sistema não são bloqueadas pela aplicação da política. Se você não ativar a configuração, precisará gerenciar a lista de imagens isentas por conta própria. Saiba como Gerenciar imagens isentas.

Visualize o conteúdo da política do sistema usando o seguinte comando:

gcloud alpha container binauthz policy export-system-policy

Para ativar o modo de avaliação de política global, adicione a seguinte linha ao arquivo policy.yaml:

globalPolicyEvaluationMode: ENABLE

Para desativar o modo de avaliação de política do sistema, adicione o seguinte:

globalPolicyEvaluationMode: DISABLE

Observação: por motivos de confiabilidade, a política do sistema é atualizada por região. Como resultado, a política do sistema pode diferir entre regiões durante uma atualização.

É possível exportar a política do sistema associada a uma região específica da seguinte maneira:

gcloud alpha container binauthz policy export-system-policy \
  --location=REGION > /tmp/policy.yaml

Substitua REGION pela região associada à política do sistema que você quer exportar (ou "global"). Por exemplo: asia-east1, europe-west1, us-central1.

Se você omitir --location ou especificar --location=global, o comando gerará uma política do sistema de uma região no último grupo de regiões para receber atualizações. Como a maioria das alterações na política do sistema são adições, a saída mostra o conjunto de imagens do sistema que são permitidas atualmente em todas as regiões.

Definir regras específicas do cluster (opcional)

Esta seção se aplica aos clusters do GKE e o GKE.

Um cluster também pode ter uma ou mais regras específicas de cluster. Esse tipo de regra se aplica a imagens de contêiner que serão implantadas apenas em clusters específicos do GKE. As regras específicas do cluster são uma parte opcional de uma política.

As regras específicas do cluster são definidas nos nós clusterAdmissionRules no arquivo YAML da política. Para mais informações sobre as partes desta regra, consulte ADMISSION_RULE na Referência da política de YAML. Por exemplo, consulte Usar uma regra específica do cluster em Políticas de exemplo.

Para adicionar uma regra específica do cluster:

No arquivo policy.yaml, adicione um nó clusterAdmissionRules:

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    evaluationMode: EVALUATION_MODE
    enforcementMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - ATTESTOR
    - ...

Substitua:

• CLUSTER_SPECIFIER: o ID do recurso do cluster ao qual a regra se aplica. Formate a regra da seguinte maneira:

  • Para GKE, clusters anexados do GKE e GKE na AWS, o formato é CLUSTER_LOCATION.CLUSTER_NAME. Por exemplo, us-central1-a.test-cluster.

  • Para o GKE em Bare Metal e o GKE no VMware, o formato é FLEET_MEMBERSHIP_LOCATION.FLEET_MEMBERSHIP_ID, por exemplo, global.test-membership.

    Outras propriedades estão descritas em Definir a regra padrão anteriormente neste guia. Consulte Políticas de exemplo para ver um exemplo de uma regra específica do cluster.

• EVALUATION_MODE: o modo de avaliação especifica o tipo de restrição que o aplicador de autorização binária aplica no momento da implantação. Substitua EVALUATION_MODE por um dos seguintes:

  • ALWAYS_ALLOW: permite que todas as imagens sejam implantadas.
  • ALWAYS_DENY: impede a implantação de todas as imagens.
  • REQUIRE_ATTESTATION: permite que uma imagem seja implantada se ela tiver um ou mais atestados que possam ser verificados por todos os atestadores adicionados a essa regra. No momento da implantação, o aplicador verifica o atestado usando os atestadores que você adiciona à lista ATTESTOR nesta regra. Para saber como criar atestadores, consulte Como criar atestadores. Se você especificar REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttestationsBy contendo pelo menos um atestador. Para saber como criar atestadores, consulte Como criar atestadores.

• ENFORCEMENT_MODE: o modo de aplicação especifica como o implementador responde quando uma imagem viola uma regra. Substitua ENFORCEMENT_MODE por um dos seguintes:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia imagens que violam a regra e informações de registro sobre a violação dos registros de auditoria do Cloud (padrão).
  • DRYRUN_AUDIT_LOG_ONLY: permite que todas as imagens sejam implantadas, com exceção das informações de aplicação do registro, incluindo informações sobre violações, nos registros de auditoria do Cloud.

• ATTESTOR: se você definir EVALUATION_MODE como REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttesationsBy. No bloco, você lista um ou mais atestadores por ID do recurso. O código do recurso tem este formato:

  projects/PROJECT_ID/attestors/ATTESTOR_NAME

  Para saber mais sobre como criar atestadores, consulte Como criar atestadores.

Definir regras específicas (opcional)

É possível criar regras com escopo para uma identidade de serviço de malha, uma conta de serviço do Kubernetes ou um namespace do Kubernetes.

Definir uma regra para uma identidade de serviço do Anthos Service Mesh

Para definir uma regra para uma identidade de serviço do Anthos Service Mesh (visualização), edite o arquivo policy.yaml e adicione um bloco istioServiceIdentityAdmissionRules, por exemplo:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
istioServiceIdentityAdmissionRules:
  SERVICE_IDENTITY_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...

name: projects/PROJECT_ID/policy

Substitua:

• SERVICE_IDENTITY_ID: a identidade de serviço do Anthos Service Mesh para definir o escopo dessa regra. A identidade do serviço tem o seguinte formato: PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT. No ID da identidade de serviço, substitua:

  • PROJECT_ID, o ID do projeto em que você define os recursos do Kubernetes.
  • NAMESPACE: o namespace do Kubernetes.
  • SERVICE_ACCOUNT: a conta de serviço.

• EVALUATION_MODE: o modo de avaliação especifica o tipo de restrição que o aplicador de autorização binária aplica no momento da implantação. Substitua EVALUATION_MODE por um dos seguintes:

  • ALWAYS_ALLOW: permite que todas as imagens sejam implantadas.
  • ALWAYS_DENY: impede a implantação de todas as imagens.
  • REQUIRE_ATTESTATION: permite que uma imagem seja implantada se ela tiver um ou mais atestados que possam ser verificados por todos os atestadores adicionados a essa regra. No momento da implantação, o aplicador verifica o atestado usando os atestadores que você adiciona à lista ATTESTOR nesta regra. Para saber como criar atestadores, consulte Como criar atestadores. Se você especificar REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttestationsBy contendo pelo menos um atestador. Para saber como criar atestadores, consulte Como criar atestadores.

• ENFORCEMENT_MODE: o modo de aplicação especifica como o implementador responde quando uma imagem viola uma regra. Substitua ENFORCEMENT_MODE por um dos seguintes:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia imagens que violam a regra e informações de registro sobre a violação dos registros de auditoria do Cloud (padrão).
  • DRYRUN_AUDIT_LOG_ONLY: permite que todas as imagens sejam implantadas, com exceção das informações de aplicação do registro, incluindo informações sobre violações, nos registros de auditoria do Cloud.

• ATTESTOR: se você definir EVALUATION_MODE como REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttesationsBy. No bloco, você lista um ou mais atestadores por ID do recurso. O código do recurso tem este formato:

  projects/PROJECT_ID/attestors/ATTESTOR_NAME

  Para saber mais sobre como criar atestadores, consulte Como criar atestadores.

Definir uma regra para uma conta de serviço do Kubernetes

Para definir uma regra para uma conta de serviço do Kubernetes, edite o arquivo policy.yaml e adicione um bloco kubernetesServiceAccountAdmissionRules, por exemplo:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesServiceAccountAdmissionRules:
  KUBERNETES_SERVICE_ACCOUNT_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

Substitua:

• KUBERNETES_SERVICE_ACCOUNT_ID: a conta de serviço do Kubernetes de escopo da regra. Esse ID de conta de serviço tem o formato: NAMESPACE:SERVICE_ACCOUNT. No ID da conta de serviço, substitua o seguinte:

  • NAMESPACE: o namespace do Kubernetes.
  • SERVICE_ACCOUNT: o nome da conta de serviço.

• EVALUATION_MODE: o modo de avaliação especifica o tipo de restrição que o aplicador de autorização binária aplica no momento da implantação. Substitua EVALUATION_MODE por um dos seguintes:

  • ALWAYS_ALLOW: permite que todas as imagens sejam implantadas.
  • ALWAYS_DENY: impede a implantação de todas as imagens.
  • REQUIRE_ATTESTATION: permite que uma imagem seja implantada se ela tiver um ou mais atestados que possam ser verificados por todos os atestadores adicionados a essa regra. No momento da implantação, o aplicador verifica o atestado usando os atestadores que você adiciona à lista ATTESTOR nesta regra. Para saber como criar atestadores, consulte Como criar atestadores. Se você especificar REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttestationsBy contendo pelo menos um atestador. Para saber como criar atestadores, consulte Como criar atestadores.

• ENFORCEMENT_MODE: o modo de aplicação especifica como o implementador responde quando uma imagem viola uma regra. Substitua ENFORCEMENT_MODE por um dos seguintes:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia imagens que violam a regra e informações de registro sobre a violação dos registros de auditoria do Cloud (padrão).
  • DRYRUN_AUDIT_LOG_ONLY: permite que todas as imagens sejam implantadas, com exceção das informações de aplicação do registro, incluindo informações sobre violações, nos registros de auditoria do Cloud.

• ATTESTOR: se você definir EVALUATION_MODE como REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttesationsBy. No bloco, você lista um ou mais atestadores por ID do recurso. O código do recurso tem este formato:

  projects/PROJECT_ID/attestors/ATTESTOR_NAME

  Para saber mais sobre como criar atestadores, consulte Como criar atestadores.

Definir uma regra para um namespace do Kubernetes

Para definir uma regra para um namespace do Kubernetes, edite o arquivo policy.yaml e adicione um bloco kubernetesNamespaceAdmissionRules, por exemplo:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesNamespaceAdmissionRules:
  KUBERNETES_NAMESPACE:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: EVALUATION_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

Substitua:

• KUBERNETES_NAMESPACE: o namespace do Kubernetes para definir o escopo dessa regra.

• EVALUATION_MODE: o modo de avaliação especifica o tipo de restrição que o aplicador de autorização binária aplica no momento da implantação. Substitua EVALUATION_MODE por um dos seguintes:

  • ALWAYS_ALLOW: permite que todas as imagens sejam implantadas.
  • ALWAYS_DENY: impede a implantação de todas as imagens.
  • REQUIRE_ATTESTATION: permite que uma imagem seja implantada se ela tiver um ou mais atestados que possam ser verificados por todos os atestadores adicionados a essa regra. No momento da implantação, o aplicador verifica o atestado usando os atestadores que você adiciona à lista ATTESTOR nesta regra. Para saber como criar atestadores, consulte Como criar atestadores. Se você especificar REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttestationsBy contendo pelo menos um atestador. Para saber como criar atestadores, consulte Como criar atestadores.

• ENFORCEMENT_MODE: o modo de aplicação especifica como o implementador responde quando uma imagem viola uma regra. Substitua ENFORCEMENT_MODE por um dos seguintes:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia imagens que violam a regra e informações de registro sobre a violação dos registros de auditoria do Cloud (padrão).
  • DRYRUN_AUDIT_LOG_ONLY: permite que todas as imagens sejam implantadas, com exceção das informações de aplicação do registro, incluindo informações sobre violações, nos registros de auditoria do Cloud.

• ATTESTOR: se você definir EVALUATION_MODE como REQUIRE_ATTESTATION, também precisará adicionar um bloco requireAttesationsBy. No bloco, você lista um ou mais atestadores por ID do recurso. O código do recurso tem este formato:

  projects/PROJECT_ID/attestors/ATTESTOR_NAME

  Para saber mais sobre como criar atestadores, consulte Como criar atestadores.

Importar o arquivo YAML da política

Esta seção se aplica aos clusters do GKE, o GKE, Cloud Run e Anthos Service Mesh.

Importe o arquivo YAML da política de volta para a autorização binária digitando:

gcloud container binauthz policy import /tmp/policy.yaml

Observação: pode levar alguns minutos para que a política entre em vigor.

A seguir

• Use o atestador built-by-cloud-build para implantar somente imagens criadas pelo Cloud Build (visualização).
• Usar atestados.
• Implantar uma imagem do GKE.