Checkpoints
Create a Kubernetes Cluster with Binary Authorization
/ 20
Update Binary Authorization Policy to add Disallow all images rule at project level and allow at cluster level
/ 10
Update cluster specific policy to Disallow all images
/ 10
Create a Nginx pod to verify cluster admission rule is applied for disallow all images (denies to create)
/ 10
Update BA policy to denying images except from whitelisted container registries (your project container registry)
/ 10
Update BA policy to modify cluster specific rule to allow only images that have been approved by attestors
/ 20
Tear Down (delete cluster)
/ 20
Segurança do Google Kubernetes Engine: autorização binária
- GSP479
- Visão geral
- Arquitetura
- Configuração
- Tarefa 1: copie recursos
- Tarefa 2: configure a versão padrão do cluster
- Tarefa 3: etapas da implantação
- Tarefa 4: validação
- Tarefa 5: use a autorização binária
- Tarefa 6: crie uma imagem particular do GCR
- Tarefa 7: negue todas as imagens
- Tarefa 8: negue imagens, exceto as dos registros de contêiner que estão na lista de permissões
- Tarefa 9: aplique atestados
- Tarefa 10: "assine" uma imagem de contêiner
- Tarefa 11: execute uma imagem com a aplicação de atestado ativada
- Tarefa 12: lide com situações de emergência
- Tarefa 13: eliminação
- Solucione problemas no seu ambiente
- Materiais relevantes
- Parabéns!
GSP479
Visão geral
Uma das principais preocupações de segurança ao executar clusters do Kubernetes é saber quais imagens de contêiner estão em execução em cada pod e identificar as origens. Para definir a "procedência", é preciso rastrear o contêiner até um ponto de origem confiável e garantir que a organização siga os processos desejados durante a criação do artefato (contêiner).
Veja algumas das principais preocupações:
- Origem segura: como garantir que todas as imagens de contêiner em execução no cluster são de uma origem aprovada?
- Consistência e validação: como verificar se todas as etapas de validação desejadas foram concluídas em cada criação e implantação do contêiner?
- Integridade: como garantir que os contêineres não foram modificados antes da execução e depois que a procedência foi comprovada?
Do ponto de vista da segurança, não restringir a origem das imagens apresenta vários riscos:
- Um agente malicioso que comprometeu um contêiner pode conseguir privilégios de cluster suficientes para iniciar outros contêineres de uma origem desconhecida sem restrição.
- Um usuário autorizado com permissões para criar pods talvez consiga executar acidentalmente ou de maneira mal-intencionada um contêiner indesejado diretamente em um cluster.
- Um usuário autorizado pode, acidentalmente ou de maneira mal-intencionada, substituir uma tag de imagem Docker por um contêiner funcional com código indesejado adicionado de modo silencioso. Em seguida, o Kubernetes extrai e implanta automaticamente esse contêiner como parte de uma implantação.
Para ajudar os operadores de sistemas a eliminar esses riscos, o Google Cloud oferece um recurso chamado autorização binária. É um serviço gerenciado do Google Cloud que opera com o GKE para aplicar controles de segurança no momento da implantação e garantir que apenas imagens de contêiner confiáveis sejam implantadas. Com a autorização binária, é possível adicionar registros de contêiner à lista de permissões, exigir que as imagens sejam assinadas por autoridades confiáveis e aplicar essas políticas de maneira centralizada. Ao aplicar essa política, você tem mais controle do ambiente do contêiner e garante que somente imagens aprovadas e/ou verificadas sejam integradas ao processo de criação e lançamento.
Este laboratório implanta um cluster do Kubernetes Engine com o recurso de autorização binária ativado, demonstra como adicionar registros de contêiner aprovados à lista de permissões e ensina a criar e executar um contêiner assinado.
Este laboratório foi criado por engenheiros do GKE Helmsman para explicar a autorização binária do GKE. Incentivamos todos a contribuir com nossos recursos.
Arquitetura
As APIs Binary Authorization e Container Analysis são baseadas nos projetos de código aberto Grafeas e Kritis.
- O Grafeas define uma especificação de API para gerenciar metadados sobre recursos de software, como imagens de contêiner, imagens de máquina virtual (VM), arquivos JAR e scripts. Você pode usar o Grafeas para definir e agregar informações sobre os componentes do seu projeto.
- O Kritis define uma API para garantir que uma implantação seja evitada, a menos que o artefato (imagem do contêiner) esteja em conformidade com a política central e, opcionalmente, tenha os atestados necessários.
Em um pipeline simplificado de implantação de contêiner, como este:
O contêiner passa por pelo menos quatro etapas:
- O código-fonte para criar o contêiner é armazenado no controle de origem.
- Após a confirmação de uma mudança no controle de origem, o contêiner é criado e testado.
- Se as etapas de criação e teste forem concluídas, o artefato de imagem do contêiner será colocado em um registro de contêiner central, pronto para implantação.
- Quando uma implantação dessa versão do contêiner é enviada à API Kubernetes, o ambiente de execução do contêiner extrai essa imagem do registro do contêiner e a executa como um pod.
Em um pipeline de criação de contêiner, existem oportunidades para injetar outros processos que indiquem ou "atestem" que cada etapa foi concluída. Alguns exemplos são a execução de testes de unidade, as verificações de análise de controle de origem, a verificação do licenciamento, as análises de vulnerabilidade e muito mais. Cada etapa pode receber o poder ou a "autoridade de atestado" para assinar a conclusão dessa etapa. Uma "autoridade de atestado" é uma pessoa ou sistema com a chave PGP correta e a capacidade de registrar esse "atestado" com a API Container Analysis.
Com chaves PGP separadas, cada etapa do atestado pode ser realizada por diferentes pessoas, sistemas ou estágios de criação no pipeline (a). Cada chave PGP é associada a uma "nota de atestado" que é armazenada na API Container Analysis. Quando uma etapa do build "assina" uma imagem, um snippet de metadados JSON sobre essa imagem é assinado por PGP e enviado à API como uma "ocorrência de observação".
(b). Depois que a imagem do contêiner é criada e os atestados necessários são armazenados de forma centralizada, eles ficam disponíveis para consulta como parte de um processo de decisão de política. Nesse caso, depois que um controlador de admissão do Kubernetes recebe uma solicitação de API create
ou update
referente a um pod:
- ele envia um webhook à API Binary Authorization para uma decisão relacionada à política;
- a política de autorização binária é consultada;
- se necessário, a API Container Analysis também é consultada para verificar as ocorrências de atestado necessárias;
- se a imagem do contêiner estiver em conformidade com a política, a execução será permitida;
- se a imagem do contêiner não atender à política, um erro será apresentado ao cliente da API com uma mensagem que descreve o motivo do bloqueio.
Configuração
Antes de clicar no botão Start Lab
Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.
Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.
Confira os requisitos para concluir o laboratório:
- Acesso a um navegador de Internet padrão (recomendamos o Chrome).
- Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.
Como iniciar seu laboratório e fazer login no console do Google Cloud
-
Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você vai encontrar o seguinte:
- O botão Abrir console do Google Cloud
- O tempo restante
- As credenciais temporárias que você vai usar neste laboratório
- Outras informações, se forem necessárias
-
Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.
O laboratório ativa os recursos e depois abre a página Fazer login em outra guia.
Dica: coloque as guias em janelas separadas lado a lado.
Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta. -
Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.
{{{user_0.username | "Nome de usuário"}}} Você também encontra o Nome de usuário no painel Detalhes do laboratório.
-
Clique em Seguinte.
-
Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.
{{{user_0.password | "Senha"}}} Você também encontra a Senha no painel Detalhes do laboratório.
-
Clique em Seguinte.
Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais. -
Acesse as próximas páginas:
- Aceite os Termos e Condições.
- Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
- Não se inscreva em testes gratuitos.
Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.
Ativar o Cloud Shell
O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.
- Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.
Depois de se conectar, vai notar que sua conta já está autenticada, e que o projeto está configurado com seu PROJECT_ID. A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:
gcloud
é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.
- (Opcional) É possível listar o nome da conta ativa usando este comando:
-
Clique em Autorizar.
-
A saída será parecida com esta:
Saída:
- (Opcional) É possível listar o ID do projeto usando este comando:
Saída:
Exemplo de saída:
gcloud
, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.
Tarefa 1: copie recursos
- Agora, você vai copiar os recursos necessários para este laboratório executando o comando abaixo:
- Acesse o diretório da demonstração:
Configure sua região e zona
Alguns recursos do Compute Engine estão em regiões e zonas. As regiões são localizações geográficas específicas onde você executa seus recursos. Todas elas têm uma ou mais zonas.
Execute o comando a seguir para configurar a região e a zona do seu laboratório (use a região/zona mais adequada para você):
Como atualizar as permissões dos arquivos
- Torne alguns arquivos legíveis, graváveis e executáveis para os recursos necessários deste laboratório:
Tarefa 2: configure a versão padrão do cluster
- Mude a variável GKE_VERSION em
create.sh
paradefaultClusterVersion
.
Tarefa 3: etapas da implantação
- Para implantar o cluster, execute este comando. Se quiser, substitua o texto
my-cluster-1
pelo nome do cluster que você quer criar.
Quando o script create
for concluído, ele vai retornar esta mensagem:
O script faz o seguinte:
- Ativa as APIs necessárias no seu projeto, especificamente:
container
,containerregistry
,containeranalysis
ebinaryauthorization
- Cria um cluster do Kubernetes Engine na zona, VPC e rede padrão
- Recupera as credenciais do cluster para permitir o uso de
kubectl
Os avisos podem ser ignorados.
Tarefa 4: validação
- O script abaixo vai validar se a demonstração foi implantada corretamente:
Se o script falhar, a saída será:
E / ou:
Se o script for aprovado, a saída será:
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Se você tiver criado um cluster do Kubernetes com autorização binária, verá uma pontuação de avaliação.
Tarefa 5: use a autorização binária
Como gerenciar a política de autorização binária
Para acessar a IU de configuração da política de autorização binária, siga as instruções abaixo:
- No console do Google Cloud, clique em Segurança > Autorização binária.
- Clique em Editar política.
gcloud
siga as etapas abaixo.
gcloud beta container binauthz policy export > policy.yaml
.policy.yaml
.gcloud beta container binauthz policy import policy.yaml
.A política que você está editando é a padrão e se aplica a todos os clusters do GKE no projeto do Google Cloud, a menos que uma política específica esteja definida para o cluster.
A recomendação é criar políticas específicas para cada cluster, garantir operações bem-sucedidas (adicionando registros à lista de permissões quando necessário) e depois definir a política padrão no nível do projeto com a configuração "Negar todas as imagens". Qualquer cluster novo no projeto precisará de uma política própria específica.
- Após clicar em Editar política, esta imagem vai aparecer. Clique na seta para baixo ao lado de Regras de isenção personalizadas para mostrar as opções:
A regra de política padrão é Allow all images
. Isso simula o comportamento como se a autorização binária não estivesse ativada no cluster.
Se a regra padrão for alterada para Disallow all images
ou Allow only images that have been approved by all of the following attestors
, as imagens que não corresponderem aos caminhos de registro isentos ou não tiverem os atestados necessários, respectivamente, serão bloqueadas.
Agora você vai editar a política:
-
Mude sua regra padrão para
Disallow all images
. -
Em "Configurações avançadas para implantações do GKE e do Anthos", clique em Criar regras específicas.
-
Selecione Cluster do GKE no menu suspenso e clique em Alterar.
-
Em Regras específicas do cluster do GKE, clique em Adicionar regra específica.
-
No campo Adicionar regra específica do cluster do GKE, insira o local e o nome do cluster no formato
location.clustername
. Por exemplo,.my-cluster-1, que corresponde à zona e ao nome do cluster my-cluster-1
. -
Selecione a regra padrão
Allow all images
para seu cluster. -
Clique em ADICIONAR.
- Clique em Salvar política.
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Após atualizar a política de autorização binária para adicionar a regra "Disallow all images" no nível do projeto e permitir no nível do cluster, você verá uma pontuação de avaliação.
Tarefa 6: crie uma imagem particular do GCR
-
Para simular uma configuração real, crie uma imagem particular de contêiner do GCR no seu projeto.
-
Você selecionará o contêiner
nginx
do projetogcr.io/google-containers/nginx
e o enviará sem modificação ao seu repositório do GCR. -
No Cloud Shell, selecione o contêiner
latest
nginx
:
- Autentique o Docker no projeto:
Se aparecer, Do you want to continue (Y/n)?
Digite Y
.
- Configure a variável de shell do PROJECT_ID:
- Marque e a envie para o GCR do projeto atual:
- Liste a imagem "particular" do nginx no seu repositório do GCR:
Tarefa 7: negue todas as imagens
Para verificar se a negação de imagem por política vai funcionar como esperado, primeiro confira se a regra allow
específica do cluster está em vigor e permite a execução dos contêineres.
- Para isso, inicie um único pod
nginx
:
Você vai receber a mensagem pod/nginx created
.
- Liste os pods:
Saída:
Se ocorrer uma falha, confira o nome e a região do cluster e tente outra vez.
- Agora, exclua esse pod:
- Em seguida, verifique se a política de autorização binária pode bloquear a execução de imagens indesejadas no cluster.
Na página "Autorização binária", clique em Editar política.
-
Clique nos três pontos verticais à direita da regra específica do cluster do GKE e selecione Editar.
-
Depois, clique em
Disallow all images
e em Enviar.
Sua política será parecida com esta:
- Por fim, clique em Salvar política para aplicar as mudanças.
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Caso a política de autorização binária tenha sido atualizada para a regra "Disallow all images" no nível do cluster, você vai receber uma pontuação de avaliação.
- Agora execute o mesmo comando anterior para criar o pod
nginx
estático:
Desta vez, você vai receber uma mensagem do servidor da API indicando que a política impediu a execução do pod:
Para ver quando algumas ou todas as imagens estão bloqueadas pela política de autorização binária, navegue até os registros de auditoria do GKE no Stackdriver e filtre as mensagens de erro relacionadas a esta atividade.
- No Console do Google Cloud, acesse Menu de navegação > Logging > Análise de registros.
- Preencha a caixa Criador de consultas com o seguinte:
- Selecione Executar consulta.
- Você vai encontrar os erros correspondentes ao bloqueio da execução do pod
nginx
.
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Se você tiver verificado a regra de admissão do cluster, verá uma pontuação de avaliação.
Tarefa 8: negue imagens, exceto as dos registros de contêiner que estão na lista de permissões
-
Imagine que você quer executar apenas o contêiner nginx. A maneira mais rápida de fazer isso é colocar na lista de permissões o registro de origem dele.
-
Você vai usar a saída do comando abaixo como o caminho da sua imagem:
-
Copie a saída do caminho da imagem no seu buffer.
-
Acesse Menu de navegação > Segurança > Autorização binária.
-
Edite a política de autorização binária, em Regras de isenção personalizadas, mostre os caminhos das imagens e clique em Adicionar um padrão de imagem.
-
Cole o caminho da imagem que você copiou anteriormente e clique em Concluído. A imagem abaixo mostra um exemplo de caminho.
- Clique em Salvar política e execute este código:
Agora você já pode iniciar esse pod e provar que a função para adicionar registros à lista de permissões está funcionando corretamente.
- Execute o código abaixo para fazer a limpeza e se preparar para as próximas etapas:
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Se a política de autorização binária tiver sido atualizada para permitir o registro de contêiner, você verá uma pontuação de avaliação.
Tarefa 9: aplique atestados
A inclusão de registros de imagem de contêiner na lista de permissões é uma ótima etapa inicial para evitar que imagens de contêiner indesejadas sejam executadas em um cluster. No entanto, é possível fazer mais do que isso para confirmar que o contêiner foi criado corretamente.
É recomendável verificar criptograficamente se uma imagem de contêiner foi aprovada para implantação. Isso é feito por uma "autoridade de atestado", que declara ou atesta a conclusão de uma determinada etapa. Para isso, a autoridade de atestado assina um snippet de metadados descrevendo um hash SHA256 de uma imagem de contêiner e o envia a um repositório de metadados central: a API Container Analysis.
Mais tarde, quando o controlador de admissão validar se a imagem de contêiner pode ser executada, consultando uma política de autorização binária que exige a presença de atestados na imagem, ele verificará se a API Container Analysis contém os snippets assinados de metadados e informará quais etapas foram concluídas. Com essas informações, o controlador de admissão saberá se pode permitir ou negar a execução do pod.
Em seguida, execute um atestado manual de uma imagem de contêiner. Você vai assumir a função de uma autoridade de atestado humana e realizará todas as etapas para assinar uma imagem de contêiner, criar uma política para exigir a presença desse atestado nas imagens em execução no seu cluster e executar a imagem em um pod.
Configure as variáveis necessárias
- Nome/dados de e-mail do atestador:
- ID da observação do Container Analysis/descrição da autoridade de atestado:
- Nomes de arquivos para criar payloads/solicitações:
Como criar uma observação de atestado
A primeira etapa consiste em registrar a autoridade de atestado como uma observação do Container Analysis com a API Container Analysis. Para isso, crie uma nota ATTESTATION
para enviá-la à API.
- Crie o payload da observação
ATTESTATION
:
- Envie a observação
ATTESTATION
à API Container Analysis:
Você vai encontrar a observação criada na saída do comando anterior, mas o comando abaixo também a listará:
Como criar uma chave de assinatura PGP
Como sua autoridade de atestado usa uma chave PGP para fazer a assinatura criptográfica dos metadados da imagem, crie uma chave desse tipo e exporte a chave PGP pública.
- Configure outra variável de shell:
- Crie a chave PGP:
-
Pressione Enter para usar uma senha longa vazia e confirmar os avisos.
-
Extraia a chave PGP pública:
Como registrar o atestador na API Binary Authorization
Na próxima etapa, você criará um "atestador" na API Binary Authorization e adicionará uma chave PGP pública a ele.
- Crie o atestador na API Binary Authorization:
- Adicione a chave PGP ao atestador:
- Liste o atestador recém-criado:
A saída será parecida com esta:
Tarefa 10: "assine" uma imagem de contêiner
As etapas anteriores só precisam ser executadas uma vez. A partir deste ponto, apenas esta etapa precisa ser repetida para cada nova imagem de contêiner.
A imagem nginx
em gcr.io/google-containers/nginx:latest
já foi criada e está disponível para uso. Realize os atestados manuais como se fosse sua imagem criada pelos seus processos e salve a etapa de criação.
- Defina algumas variáveis de shell:
- Para receber a impressão digital do PGP, execute o seguinte:
- Para receber o resumo SHA256 da imagem do contêiner, execute:
- Crie um payload de assinatura no formato JSON:
- Confira o payload de assinatura gerado:
- "Assine" o payload com a chave PGP:
- Acesse a assinatura gerada (mensagem PGP):
- Crie o atestado:
- Visualize o atestado recém-criado:
Tarefa 11: execute uma imagem com a aplicação de atestado ativada
A próxima etapa consiste em mudar a política de autorização binária para exigir o atestado nas imagens que não correspondem aos padrões da lista de permissões.
- Se quiser mudar a política para exigir um atestado, execute o comando abaixo e copie o caminho completo/nome da autoridade do atestado:
- Depois, mude a política de autorização binária para
edit
e edite a regra específica do cluster do GKE.
Clique nos três pontos ao lado do nome do cluster para editar as regras específicas do cluster.
- Selecione
Require attestations (Allow only images that have been verified by all of the following attestors)
em vez deDisallow all images
na janela pop-up:
- Em seguida, clique em
Add Attestors
eAdd by attestor resource ID
. Insira o conteúdo do buffer de copiar/colar no formatoprojects/${PROJECT_ID}/attestors/${ATTESTOR}
, depois clique em Adicionar 1 atestador e em Enviar. Por último, clique em Salvar Política.
A política padrão ainda vai mostrar Disallow all images
, mas a regra específica do cluster exigirá um atestado.
- Para receber o resumo SHA256 mais recente da imagem assinada das etapas anteriores:
- Depois de aguardar pelo menos 30 segundos do momento em que a política de autorização binária foi atualizada, execute o pod e verifique se a operação foi bem-sucedida:
Parabéns! Você atestou manualmente uma imagem de contêiner e aplicou uma política a ela no seu cluster do GKE.
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Se a política de autorização binária tiver sido atualizada para que a regra específica do cluster permita somente imagens aprovadas por atestadores, você verá uma pontuação de avaliação.
Tarefa 12: lide com situações de emergência
Da perspectiva do usuário, a política de autorização binária pode bloquear incorretamente uma imagem ou pode haver outro problema com a operação do webhook do controlador de admissão.
Nesse caso de "emergência", há um recurso de acesso imediato que sinaliza ao controlador de admissão com uma anotação específica para executar o pod e pular a aplicação da política.
Nesse caso, porém, seus procedimentos de resposta podem ser iniciados segundos após a ocorrência da atividade. Os registros estão disponíveis no pacote de operações do Google Cloud (antigo Stackdriver):
- Para executar um contêiner
nginx
não atribuído com a anotação "Acesso imediato", use este comando:
-
No Console do Google Cloud, acesse Menu de navegação > Logging > página Análise de registros.
-
Preencha a caixa Criador de consultas com o código abaixo e clique em Executar consulta:
resource.type="k8s_cluster" protoPayload.request.metadata.annotations."alpha.image-policy.k8s.io/break-glass"="true" -
Você vai encontrar eventos quando o controlador de admissão permitir um pod por causa da presença da anotação. Com esse filtro, será possível criar um
Sink
que envia registros correspondentes ao filtro para um destino externo.
Tarefa 13: eliminação
O Qwiklabs vai remover todos os recursos que você criou neste laboratório. No entanto, é recomendável que você saiba como limpar seu ambiente.
- O script a seguir destruirá o cluster do Kubernetes Engine:
Use o nome do seu cluster caso o tenha criado no início do laboratório. Neste exemplo, usamos o nome my-cluster-1
.
As últimas linhas da saída serão:
gcloud container clusters list
para acompanhar o andamento, se quiser. Aguarde a remoção do cluster.
Teste a tarefa concluída
Clique em Verificar meu progresso para conferir a tarefa realizada. Quando o cluster for excluído, você verá uma pontuação de avaliação.
Os comandos a seguir removerão os outros recursos.
- Exclua a imagem do contêiner enviada ao GCR:
-
Quando aparecer
Do you want to continue (Y/n)?
digiteY
. -
Exclua o atestador:
- Exclua a observação do Container Analysis:
Solucione problemas no seu ambiente
- Se você atualizar a política de autorização binária e tentar iniciar um novo pod/contêiner rapidamente, talvez a política ainda não tenha entrado em vigor. Aguarde 30 segundos ou mais para a ativação da mudança da política. Para tentar novamente, exclua o pod com
kubectl delete <podname>
e reenvie o comando de criação dele. - Execute o comando
gcloud container clusters list
para verificar o status do cluster. - Se você adicionar outros recursos, como
--enable-network-policy
,--accelerator
,--enable-tpu
ou--enable-metadata-concealment
, talvez seja necessário adicionar registros à sua lista de permissões de política de autorização binária para permitir a execução dos pods. Usekubectl describe pod <podname>
para encontrar o caminho do registro na especificação da imagem e adicione-o à lista de permissões no formatogcr.io/example-registry/*
. Em seguida, salve a política. - Aumente sua cota no projeto se você receber erros relacionados a isso. Saiba mais na Documentação das cotas de recursos.
Materiais relevantes
- Cotas do Google Cloud
- Inscrever-se no Google Cloud
- Google Cloud Shell
- Autorização binária no GKE
- Notas do Container Analysis
- Controlador de admissão do Kubernetes
- Etapas de lançamento
Parabéns!
Termine a Quest
Este laboratório autoguiado faz parte da Quest Google Kubernetes Engine Best Practices: Security do Qwiklabs. Uma Quest é uma série de laboratórios relacionados que formam um programa de aprendizado. Ao concluir uma Quest, você ganha um selo como reconhecimento da sua conquista. É possível publicar os selos e incluir um link para eles no seu currículo on-line ou nas redes sociais.Inscreva-se nesta Quest e receba o crédito de conclusão imediatamente. Consulte o catálogo do Google Cloud Ensina para conferir todas as Quests disponíveis.
Comece o próximo laboratório
Continue a Quest com Como usar uma política de rede no Kubernetes Engine ou confira estas sugestões:
- Como usar o controle de acesso baseado em papéis no Kubernetes Engine
- Como aumentar a segurança das configurações padrão do cluster do GKE
Manual atualizado em 11 de outubro de 2023
Laboratório testado em 11 de outubro de 2023
Copyright 2024 Google LLC. Este software é fornecido no estado em que se encontra, sem declarações nem garantias para qualquer uso ou finalidade. O uso do software está sujeito ao seu contrato com o Google.