Conceitos da autorização binária

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

Esta página contém informações sobre conceitos relacionados à autorização binária.

Políticas

Uma política de autorização binária, também conhecida como política de projeto-singleton, é um conjunto de regras que regem a implantação de imagens de contêiner.

A validação contínua (CV) usa um tipo diferente de política, chamada de política de plataforma.

Uma política tem como partes:

• Regras de implantação
• Lista de imagens isentas

Você pode configurar uma política usando uma das seguintes opções:

• Console do Google Cloud
• gcloud commands

Ao usar os comandos gcloud, exporte e modifique uma definição da política no formato YAML antes de importá-la de volta para o projeto. O formato YAML reflete a estrutura interna de uma política no armazenamento de autorização binária. Para mais informações sobre esse formato, consulte a Referência do YAML de políticas.

Cada projeto do Google Cloud pode ter exatamente uma política. Configure a política no projeto em que você executa a plataforma de implantação. Em uma configuração de projeto único, a política e todos os recursos subordinados (atestadores e atestados) residem na o mesmo projeto. Para estabelecer a separação de deveres, use uma configuração de vários projetos. Nesta configuração, a plataforma de implantação pode ser executada em um projeto, os atestadores podem residir em outro projeto e os atestados podem residir em outro projeto.

Para configurar e usar a autorização binária nas plataformas compatíveis, consulte Configurar por plataforma.

Veja um exemplo de configuração de vários projetos para GKE.

Regras

Ao configurar uma política, você define as regras dela. As regras definem restrições que as imagens precisam atender antes de serem implantadas. Uma política tem uma regra padrão e pode ter regras específicas, dependendo da plataforma. Para mais informações, consulte Tipos de regras compatíveis por plataforma.

Cada regra pode ser configurada com um modo de avaliação e com um modo de aplicação. Por exemplo, uma regra pode exigir que uma imagem tenha um atestado assinado antes de ser implantada.

Regra padrão

Cada política tem uma regra padrão. Essa regra se aplica a qualquer solicitação de implantação que não corresponda a uma regra específica. Em um arquivo YAML de política, a regra padrão é especificada no nó defaultAdmissionRule.

Para mais informações sobre como configurar a regra padrão, consulte Como configurar uma política.

Regras específicas

É possível adicionar uma ou mais regras específicas a uma política. Esse tipo de regra se aplica a imagens que serão implantadas em clusters, contas de serviço ou identidades específicas. A compatibilidade com regras específicas varia de acordo com a plataforma. Para mais informações, consulte Tipos de regras compatíveis por plataforma.

Em um arquivo YAML de política, cada regra específica do cluster é especificada em um nó clusterAdmissionRule.

Tipos de regras compatíveis por plataforma

Veja na tabela a seguir quais tipos de regra são compatíveis com cada plataforma de implantação.

Plataforma	Regra padrão	Regra específica
GKE	Compatível	Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes
Cloud Run	Compatível	Sem suporte
Clusters anexados do GKE	Compatível	Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes
GKE na AWS	Compatível	Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes
Google Distributed Cloud	Compatível	Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes
Google Distributed Cloud	Compatível	Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes
Cloud Service Mesh	Compatível	Identidades de serviço do Cloud Service Mesh

Modos de avaliação

Cada regra tem um modo de avaliação que especifica o tipo de restrição que a autorização binária aplica para a regra. O modo de avaliação de uma regra é especificado usando a propriedade evaluationMode no arquivo YAML da política.

Há três modos de avaliação:

• Permitir todas as imagens: permite que todas as imagens sejam implantadas.
• Não permitir todas as imagens: impede a implantação de todas as imagens.
• Exigir atestados: requer um signatário para assinar digitalmente o resumo da imagem e criar um atestado antes da implantação. No momento da implantação, o aplicador de autorização binária usa um atestador para verificar a assinatura no atestado antes de implantar a imagem associada.

Modos de aplicação

Cada regra também tem um modo de aplicação, que especifica a ação executada pelo GKE quando uma imagem não está em conformidade com a regra. Uma regra pode ter os seguintes modos de aplicação:

• Bloquear e registrar registros: bloqueia a implantação de imagens que não estão em conformidade com a regra e grava uma mensagem no registro de auditoria para indicar por que a imagem não foi implantada.

• Teste: somente registro de auditoria: é um modo de aplicação em uma política que permite a implantação de imagens que não estão em conformidade, mas grava detalhes sobre a implantação nos Registros de auditoria do Cloud. O modo de teste permite testar uma política, por exemplo, no ambiente de produção, antes que a aplicação entre em vigor.

A maioria das regras de produção usa o modo de aplicação Bloquear o registro de auditoria. Simulação: somente registro de auditoria é usado principalmente para testar uma política no ambiente antes de entrar em vigor.

O modo de aplicação de uma regra é especificado usando a propriedade enforcementMode no arquivo YAML da política.

Consulte Ver registros de auditoria (GKE, Google Distributed Cloud, Cloud Service Mesh) ou Acessar registros de auditoria (Cloud Run) para mais informações sobre mensagens gravadas nos Registros de auditoria do Cloud.

Validação contínua

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

A validação contínua (CV, na sigla em inglês) é um recurso de autorização binária que verifica periodicamente as imagens associadas aos pods em execução para garantir a conformidade contínua com as políticas.

Saiba mais sobre a CV.

Isentar imagens

Observação: não é recomendado usar admissionWhitelistPatterns para colocar na lista de permissões as imagens do sistema gerenciadas pelo Google. Para autorizar imagens de sistema gerenciadas pelo Google, globalPolicyEvaluationMode precisa ser definido como ENABLE. Consulte globalPolicyEvaluationMode para ver detalhes.

Uma imagem isenta é uma imagem isenta de regras de política. A autorização binária sempre permite a implantação de imagens isentas. Cada projeto tem uma lista de permissões de imagens isentas especificadas pelo caminho do registro. As imagens no caminho gcr.io/google_containers/*, k8s.gcr.io/** e outros caminhos são isentas por padrão, porque contêm recursos necessários para que o GKE possa iniciar um cluster com a política padrão ativa.

Para adicionar uma imagem isenta à lista de permissões, inclua o seguinte no arquivo de política:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Substitua EXEMPT_IMAGE_PATH pelo caminho para a imagem a ser isentada. Para isentar outras imagens, adicione outras entradas - namePattern. Saiba mais sobre admissionWhitelistPatterns.

Padrões da lista de permissões

Para colocar todas as imagens de contêiner cujo local de registro corresponde ao caminho especificado na lista de permissões:

gcr.io/example-project/*

Para colocar todas as imagens na lista de permissões cujo local de registro é qualquer subdiretório do caminho especificado (por exemplo, gcr.io/example-project/my-directory/helloworld):

gcr.io/example-project/**

Para colocar uma imagem específica na lista de permissões:

gcr.io/example-project/helloworld

Para colocar uma versão específica de uma imagem na lista de permissões por tag:

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

Para colocar todas as versões/tags de uma imagem na lista de permissões:

gcr.io/example-project/helloworld:*

Para autorizar uma versão específica de uma imagem pelo resumo:

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

Saiba mais sobre como usar resumos de imagem de contêiner.

Saiba como gerenciar imagens isentas no Console do Google Cloud usando a ferramenta de linha de comando ou a API REST.

Imagens do sistema mantidas pelo Google

Confiar em todas as imagens do sistema mantidas pelo Google faz com que a autorização binária isenta uma lista de imagens do sistema mantidas pelo Google para avaliação adicional de política. Quando essa configuração está ativada, as imagens exigidas pelo GKE não são bloqueadas pela aplicação da política. A política do sistema é avaliada antes e depois da avaliação da política do usuário.

Você pode ativar ou desativar essa configuração usando a propriedade globalPolicyEvaluationMode no arquivo YAML da política. Visualize o conteúdo da política do sistema usando o seguinte comando:

gcloud alpha container binauthz policy export-system-policy

Atestados

Um atestado é um documento digital que certifica uma imagem. Durante a implantação, a autorização binária verifica o atestado antes de permitir que a imagem seja implantada.

Às vezes, o processo de criação de um atestado é chamado de assinatura de uma imagem. Um atestado é criado após a criação de uma imagem. Cada imagem tem um resumo globalmente exclusivo. Um signatário assina o resumo da imagem usando uma chave privada de um par de chaves e usa a assinatura para criar o atestado. No momento da implantação, o aplicador de autorização binária usa a chave pública do atestador para verificar a assinatura no atestado. Normalmente, um atestador corresponde exatamente a um signatário.

Um atestado significa que a imagem associada foi criada ao executar um processo específico. Por exemplo, se o signatário representar sua função de controle de qualidade, o atestado poderá indicar que a imagem do contêiner foi aprovada em todos os testes funcionais de ponta a ponta em um ambiente de teste.

Para ativar atestados na autorização binária, o evaluationMode da política está definido como REQUIRE_ATTESTATION.

Saiba como criar e usar atestadores e atestados.

Signatários

Um signatário é uma pessoa ou um processo automatizado que cria um atestado assinando um descritor de imagem de contêiner exclusivo com uma chave privada. O atestado é verificado no momento da implantação pela chave pública correspondente armazenada em um atestador antes de o contêiner associado ser implantado.

Saiba como criar e usar atestadores e atestados.

Atestadores

Um atestador é um recurso do Google Cloud que a autorização binária usa para verificar o atestado no momento da implantação da imagem. Os atestadores contêm a chave pública que corresponde à chave privada usada por um signatário para assinar o resumo da imagem do contêiner e criar o atestado. O aplicador de autorização binária usa o atestador no momento da implantação para limitar quais imagens podem ser implantadas para aquelas com um atestado verificável criado antes da implantação.

Os atestadores muitas vezes são gerenciados pela equipe de operações de segurança que também gerencia os pares de chaves públicas e privadas. Já os signatários geralmente são engenheiros de software ou a equipe de controle de qualidade de DevOps ou de conformidade responsável pela produção de imagens de contêiner implantáveis, assinatura das imagens com a chave privada e criação dos atestados antes de tentar implantá-los.

Os atestadores têm:

• Uma nota do Artifact Analysis correspondente
• uma ou mais chaves públicas criptográficas que correspondem à chave privada que o assinante usou para criar um atestado.

Ao configurar uma política que contenha uma regra Exigir atestados, você precisa adicionar um atestador para cada pessoa ou processo necessário para verificar se a imagem do contêiner está pronta para implantação. Você pode adicionar atestadores usando o Console do Google Cloud, a interface gcloud ou a API REST de autorização binária.

Saiba como criar e usar atestadores e atestados.

Chaves de criptografia

A autorização binária usa assinaturas digitais para verificar imagens no momento da implantação quando a política contém uma regra Exigir atestados.

Um par de chaves é gerado. A chave privada é usada pelo signatário para assinar um descritor de imagem. Isso cria um atestado.

Em seguida, um atestador é criado e armazenado na política. A chave pública que corresponde à chave privada usada para assinatura é enviada e anexada ao atestador.

Quando uma tentativa de implantação é feita, a autorização binária usa atestadores na política para verificar os atestados da imagem. Se o atestado puder ser verificado, a imagem será implantada.

A autorização binária é compatível com dois tipos de chaves:

• PKIX
• PGP

As chaves PKIX podem ser armazenadas localmente, externamente ou no Cloud Key Management Service.

Crie uma chave criptográfica e um atestador.

Notas do Artifact Analysis

A autorização binária usa o Artifact Analysis para armazenar metadados confiáveis usados no processo de autorização. Para cada atestador criado, você precisa criar uma nota do Artifact Analysis. Cada atestado é armazenado como uma ocorrência desta nota.

Quando a autorização binária avalia uma regra que exige que os atestadores verifiquem uma imagem, ela verifica o armazenamento do Artifact Analysis para ver se os atestados necessários estão presentes.