Esta página contém informações sobre conceitos relacionados com a autorização binária.
Políticas
Uma política de autorização binária, também conhecida como política de singleton do projeto, é um conjunto de regras que regem a implementação de imagens de contentores.
A validação contínua (CV) usa um tipo de política diferente, denominada política de plataforma.
Uma política tem as seguintes partes:
- Regras de implementação
- Lista de imagens isentas
Pode configurar uma política através de uma das seguintes opções:
- Google Cloud consola
gcloudcomandos
Quando usa comandos gcloud, exporta e modifica uma definição da política no formato YAML antes de a importar novamente para o seu projeto. O formato YAML reflete a estrutura interna de uma política no armazenamento da autorização binária.
Para mais informações sobre este formato, consulte o
Referência YAML de políticas.
Cada Google Cloud projeto pode ter exatamente uma política. Tem de configurar a política no projeto onde executa a plataforma de implementação. Numa configuração de projeto único, a política e todos os recursos subordinados, ou seja, atestadores e atestações, residem no mesmo projeto. Para estabelecer a separação de funções, pode usar uma configuração de vários projetos. Nesta configuração, a plataforma de implementação pode ser executada num projeto, os atestadores podem residir noutro projeto e as atestações podem residir noutro projeto.
Para configurar e usar a autorização binária em plataformas suportadas, consulte o artigo Configuração por plataforma.
Veja um exemplo de configuração de vários projetos para o GKE.
Regras
Quando configura uma política, define as respetivas regras. As regras definem restrições que as imagens têm de cumprir antes de poderem ser implementadas. Uma política tem uma regra predefinida e pode ter regras específicas, consoante a plataforma. Para mais informações, consulte o artigo Tipos de regras suportados por plataforma.
Cada regra pode ser configurada com um modo de avaliação e um modo de aplicação. Por exemplo, uma regra pode exigir que uma imagem tenha uma atestação assinada antes de poder ser implementada.
Regra predefinida
Cada política tem uma regra predefinida. Esta regra aplica-se a qualquer pedido de implementação que não corresponda a uma regra específica. Num ficheiro YAML de política, a regra predefinida é especificada no nó defaultAdmissionRule.
Para mais informações sobre como configurar a regra predefinida, consulte o artigo Configurar uma política.
Regras específicas
Podem ser adicionadas uma ou mais regras específicas a uma política. Este tipo de regra aplica-se a imagens que vão ser implementadas em clusters, contas de serviço ou identidades específicos. O apoio técnico para regras específicas varia consoante a plataforma. Para mais informações, consulte o artigo Tipos de regras suportados por plataforma.
Num ficheiro YAML de política, cada regra específica do cluster é especificada num
clusterAdmissionRule
nó.
Tipos de regras suportados por plataforma
A tabela seguinte mostra os tipos de regras suportados para cada plataforma de implementação.
| Plataforma | Regra predefinida | Regra específica |
|---|---|---|
| GKE | Suportado | Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes |
| Cloud Run | Suportado | Não suportado |
| Clusters associados do GKE | Suportado | Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes |
| GKE no AWS | Suportado | Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes |
| Google Distributed Cloud | Suportado | Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes |
| Google Distributed Cloud | Suportado | Clusters Namespaces do Kubernetes Contas de serviço do Kubernetes |
| Cloud Service Mesh | Suportado | 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 à regra. O modo de avaliação de uma regra é especificado através da propriedade evaluationMode no ficheiro YAML da política.
Existem três modos de avaliação:
- Permitir todas as imagens: permite a implementação de todas as imagens.
- Não permitir todas as imagens: não permite a implementação de nenhuma imagem.
- Exigir atestações: exige que um signatário assine digitalmente o resumo da imagem e crie uma atestação antes da implementação. No momento da implementação, o agente do Binary Authorization usa um atestador para validar a assinatura na atestação antes de implementar a imagem associada.
Modos de aplicação
Cada regra também tem um modo de aplicação, que especifica a ação que o GKE realiza quando uma imagem não está em conformidade com a regra. Uma regra pode ter os seguintes modos de aplicação:
Bloquear e registo de auditoria: bloqueia a implementação de imagens que não estão em conformidade com a regra e escreve uma mensagem no registo de auditoria para indicar o motivo pelo qual a imagem não foi implementada.
Execução de teste: apenas registo de auditoria: o modo de execução de teste é um modo de aplicação numa política que permite a implementação de imagens não conformes, mas escreve detalhes sobre a implementação nos registos de auditoria da nuvem. O modo de teste permite-lhe testar uma política, por exemplo, no seu ambiente de produção, antes de a aplicação entrar em vigor.
A maioria das regras de produção usa o modo de aplicação Bloquear e registo de auditoria. A opção Execução de teste: apenas registo de auditoria é usada principalmente para testar uma política no seu ambiente antes de entrar em vigor.
O modo de aplicação de uma regra é especificado através da propriedade enforcementMode no ficheiro YAML da política.
Consulte Ver registos de auditoria (GKE, Google Distributed Cloud, Cloud Service Mesh) ou Ver registos de auditoria (Cloud Run) para mais informações sobre as mensagens escritas nos registos de auditoria do Cloud.
Validação contínua
A validação contínua (CV) é uma funcionalidade da 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.
Imagens isentas
Uma imagem isenta é uma imagem isenta das regras de políticas.
A autorização binária permite sempre a implementação de imagens isentas. Cada projeto tem uma lista de autorizações de imagens isentas especificada pelo caminho do registo. As imagens no caminho
gcr.io/google_containers/*, k8s.gcr.io/** e caminhos adicionais estão isentas por
predefinição, uma vez que contêm recursos necessários para que o GKE
possa iniciar um cluster com êxito com a política predefinida ativa.
Para adicionar uma imagem isenta à lista de autorizações, adicione o seguinte ao ficheiro de política:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Substitua EXEMPT_IMAGE_PATH pelo caminho para uma imagem a isentar. Para isentar imagens adicionais, adicione mais entradas - namePattern. Saiba mais sobre admissionWhitelistPatterns.
Padrões da lista de autorizações
Para permitir todas as imagens cuja localização do registo corresponda ao caminho especificado:
gcr.io/example-project/*
Para permitir todas as imagens cuja localização do registo seja qualquer subdiretório do caminho especificado (por exemplo, gcr.io/example-project/my-directory/helloworld):
gcr.io/example-project/**
Para adicionar uma imagem específica à lista de permitidos:
gcr.io/example-project/helloworld
Para permitir uma versão específica de uma imagem por etiqueta:
gcr.io/example-project/helloworld:latest gcr.io/example-project/helloworld:my-tag
Para adicionar todas as versões e etiquetas de uma imagem à lista de autorizações:
gcr.io/example-project/helloworld@*
Para adicionar uma versão específica de uma imagem à lista de autorizações através do respetivo resumo:
gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
Saiba mais sobre a utilização de resumos de imagens de contentores.
Saiba como gerir imagens isentas na Google Cloud consola, através da ferramenta de linha de comandos ou da API REST.
Imagens do sistema mantidas pela Google
A opção Confiar em todas as imagens do sistema mantidas pela Google faz com que a autorização binária isente uma lista de imagens do sistema mantidas pela Google de uma avaliação de políticas adicional. Quando esta definição está ativada, as imagens necessárias pelo GKE não são bloqueadas pela aplicação de políticas. A política de sistema é avaliada antes e além da avaliação da política do utilizador.
Pode ativar ou desativar esta definição através da propriedade
globalPolicyEvaluationMode
no ficheiro YAML da política. Pode ver o conteúdo da política do sistema através do seguinte comando:
gcloud alpha container binauthz policy export-system-policy
Atestações
Uma atestação é um documento digital que certifica uma imagem. Durante a implementação, a Autorização binária valida a atestação antes de permitir a implementação da imagem.
O processo de criação de uma atestação é por vezes denominado assinatura de uma imagem. É criada uma atestação após a criação de uma imagem. Cada imagem deste tipo tem um resumo globalmente único. Um signatário assina o resumo da imagem usando uma chave privada de um par de chaves e usa a assinatura para criar a atestação. No momento da implementação, o aplicador da Autorização binária usa a chave pública do atestador para validar a assinatura na atestação. Normalmente, um atestador corresponde exatamente a um signatário.
Uma atestação significa que a imagem associada foi criada através da execução bem-sucedida de um processo específico obrigatório. Por exemplo, se o signatário for um representante da sua função de controlo de qualidade, a atestação pode indicar que a imagem passou em todos os testes funcionais completos necessários num ambiente de preparação.
Para ativar as atestações na autorização binária, o evaluationMode da sua política está definido como REQUIRE_ATTESTATION.
Saiba como criar e usar atestadores e atestações.
Signatários
Um signatário é uma pessoa ou um processo automatizado que cria uma atestação ao assinar um descritor de imagem único com uma chave privada. A atestação é validada no momento da implementação pela chave pública correspondente armazenada num atestador antes de a imagem associada ser implementada.
Saiba como criar e usar atestadores e atestações.
Atestadores
Um atestador é um Google Cloud recurso que a autorização binária usa para validar a atestação no momento da implementaçã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 e criar a atestação. O aplicador da autorização binária usa o atestador no momento da implementação para limitar as imagens que podem ser implementadas àquelas com uma atestação verificável associada criada antes da implementação.
Os atestadores são frequentemente geridos por pessoal de operações de segurança que também gere os pares de chaves públicas e privadas, enquanto os signatários são normalmente engenheiros de software ou pessoal de controlo de qualidade ou conformidade de DevOps responsáveis por produzir imagens implementáveis, assiná-las com a chave privada e criar as atestações antes de tentar implementá-las.
Os atestantes têm:
- Uma nota de análise de artefactos correspondente
- Uma ou mais chaves públicas criptográficas que correspondem à chave privada que o signatário usou para criar uma atestação.
Quando configura uma política que contém uma regra Require Attestations, tem de adicionar um atestador para cada pessoa ou processo que tenha de validar se a imagem está pronta para implementação. Pode adicionar atestadores através da
consola, da interface gcloud ou da API REST
Binary Authorization. Google Cloud
Saiba como criar e usar atestadores e atestações.
Chaves criptográficas
A Autorização binária usa assinaturas digitais para validar imagens no momento da implementação quando a política contém uma regra Require Attestations.
É gerado um par de chaves. A chave privada é usada pelo signatário para assinar um descritor de imagem. Esta ação cria uma atestação.
Em seguida, é criado um atestador e armazenado na política. A chave pública que corresponde à chave privada usada para a assinatura é carregada e anexada ao atestador.
Quando se tenta implementar uma imagem, a autorização binária usa atestadores na política para validar as atestações da imagem. Se a atestação puder ser validada, a imagem é implementada.
A autorização binária suporta dois tipos de chaves:
- Infraestrutura de chave pública (X.509) (PKIX)
- PGP
As chaves PKIX podem ser armazenadas localmente, externamente ou no Serviço de gestão de chaves na nuvem.
Crie uma chave criptográfica e um atestador.
Notas da Artifact Analysis
A autorização binária usa a análise de artefactos para armazenar metadados fidedignos usados no processo de autorização. Para cada atestador que criar, tem de criar uma nota de análise de artefactos. Cada atestação é armazenada como uma ocorrência desta nota.
Quando a autorização binária avalia uma regra que exige que os atestadores tenham validado uma imagem, verifica o armazenamento da análise de artefactos para ver se as atestações necessárias estão presentes.