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:

1. O código-fonte para criar o contêiner é armazenado no controle de origem.
2. Após a confirmação de uma mudança no controle de origem, o contêiner é criado e testado.
3. 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.
4. 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:

1. ele envia um webhook à API Binary Authorization para uma decisão relacionada à política;
2. a política de autorização binária é consultada;
3. se necessário, a API Container Analysis também é consultada para verificar as ocorrências de atestado necessárias;
4. se a imagem do contêiner estiver em conformidade com a política, a execução será permitida;
5. 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).

Observação: para executar este laboratório, use o modo de navegação anônima ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.

Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. 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ê verá o seguinte:

   • O botão Abrir Console do Cloud
   • Tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações se forem necessárias

2. Clique em Abrir Console do Google. O laboratório ativa recursos e depois abre outra guia com a página Fazer login.

   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.

3. Caso seja preciso, copie o Nome de usuário no painel Detalhes do laboratório e cole esse nome na caixa de diálogo Fazer login. Clique em Avançar.

4. Copie a Senha no painel Detalhes do laboratório e a cole na caixa de diálogo Olá. Clique em Avançar.

   Importante: você precisa usar as credenciais do painel à esquerda. Não use suas credenciais do Google Cloud Ensina. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

5. 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 GCP vai ser aberto nesta guia.

Observação: para ver uma lista dos produtos e serviços do Google Cloud, clique no Menu de navegação no canto superior esquerdo.

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.

1. 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:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

2. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

3. Clique em Autorizar.

4. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = <project_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

Tarefa 1: copie recursos

1. Agora, você vai copiar os recursos necessários para este laboratório executando o comando abaixo:

gsutil -m cp -r gs://spls/gke-binary-auth/* .

2. Acesse o diretório da demonstração:

cd gke-binary-auth-demo

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.

Para saber mais sobre regiões e zonas, além de conferir uma lista completa com todas elas, acesse a página Regiões e zonas da documentação.

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ê):

gcloud config set compute/region {{{ project_0.default_region | REGION }}} gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

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:

chmod +x create.sh chmod +x delete.sh chmod 777 validate.sh

Tarefa 2: configure a versão padrão do cluster

• Mude a variável GKE_VERSION em create.sh para defaultClusterVersion.

sed -i 's/validMasterVersions\[0\]/defaultClusterVersion/g' ./create.sh Observação: a versão padrão do cluster será compatível com outras dependências neste laboratório.

Tarefa 3: etapas da implantação

Observação: as instruções abaixo são válidas para implantações realizadas com e sem o Cloud Shell.

• Para implantar o cluster, execute este comando. Se quiser, substitua o texto my-cluster-1 pelo nome do cluster que você quer criar.

./create.sh -c my-cluster-1

Quando o script create for concluído, ele vai retornar esta mensagem:

kubeconfig entry generated for my-cluster-1. NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS my-cluster-1 {{{project_0.default_zone | Zone}}} 1.14.8-gke.17 104.154.181.211 n1-standard-1 1.14.8-gke.17 2 RUNNING Fetching cluster endpoint and auth data. kubeconfig entry generated for my-cluster-1.

O script faz o seguinte:

1. Ativa as APIs necessárias no seu projeto, especificamente: container, containerregistry, containeranalysis e binaryauthorization
2. Cria um cluster do Kubernetes Engine na zona, VPC e rede padrão
3. 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:

./validate.sh -c my-cluster-1

Se o script falhar, a saída será:

Validation Failed: the BinAuthZ policy was NOT available

E / ou:

Validation Failed: the Container Analysis API was NOT available

Se o script for aprovado, a saída será:

Validation Passed: the BinAuthZ policy was available Validation Passed: the Container Analysis API was available

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.

Crie um cluster do Kubernetes com autorização binária

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:

1. No console do Google Cloud, clique em Segurança > Autorização binária.

2. Clique em Editar política.

Observação: para acessar a configuração "Política de autorização binária" pela gcloud siga as etapas abaixo.

Execute gcloud beta container binauthz policy export > policy.yaml.

Faça as edições necessárias em policy.yaml.

Execute 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.

3. 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:

4. Mude sua regra padrão para Disallow all images.

5. Em "Configurações avançadas para implantações do GKE e do Anthos", clique em Criar regras específicas.

6. Selecione Cluster do GKE no menu suspenso e clique em Alterar.

7. Em Regras específicas do cluster do GKE, clique em Adicionar regra específica.

8. 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.

9. Selecione a regra padrão Allow all images para seu cluster.

10. Clique em ADICIONAR.

11. 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.

Atualize 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

Tarefa 6: crie uma imagem particular do GCR

1. Para simular uma configuração real, crie uma imagem particular de contêiner do GCR no seu projeto.

2. Você selecionará o contêiner nginx do projeto gcr.io/google-containers/nginx e o enviará sem modificação ao seu repositório do GCR.

3. No Cloud Shell, selecione o contêiner latest nginx:

docker pull gcr.io/google-containers/nginx:latest

4. Autentique o Docker no projeto:

gcloud auth configure-docker

Se aparecer, Do you want to continue (Y/n)? Digite Y.

5. Configure a variável de shell do PROJECT_ID:

PROJECT_ID="$(gcloud config get-value project)"

6. Marque e a envie para o GCR do projeto atual:

docker tag gcr.io/google-containers/nginx "gcr.io/${PROJECT_ID}/nginx:latest" docker push "gcr.io/${PROJECT_ID}/nginx:latest"

7. Liste a imagem "particular" do nginx no seu repositório do GCR:

gcloud container images list-tags "gcr.io/${PROJECT_ID}/nginx"

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.

1. Para isso, inicie um único pod nginx:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Você vai receber a mensagem pod/nginx created.

2. Liste os pods:

kubectl get pods

Saída:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 1m

Se ocorrer uma falha, confira o nome e a região do cluster e tente outra vez.

3. Agora, exclua esse pod:

kubectl delete pod nginx

4. 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.

5. Clique nos três pontos verticais à direita da regra específica do cluster do GKE e selecione Editar.

6. Depois, clique em Disallow all images e em Enviar.

Sua política será parecida com esta:

7. Por fim, clique em Salvar política para aplicar as mudanças.

Importante: aguarde pelo menos 30 segundos antes de continuar para a política entrar em vigor.

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.

Atualize a política específica do cluster para "Disallow all images"

8. Agora execute o mesmo comando anterior para criar o pod nginx estático:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Desta vez, você vai receber uma mensagem do servidor da API indicando que a política impediu a execução do pod:

Error from server (VIOLATES_POLICY): error when creating "STDIN": admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/qwiklabs-gcp-00-ce851250686b/nginx:latest denied by Binary Authorization cluster admission rule for {{{project_0.default_zone | Zone}}}.my-cluster-1. Denied by always_deny admission rule

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.

9. No Console do Google Cloud, acesse Menu de navegação > Logging > Análise de registros.
10. Preencha a caixa Criador de consultas com o seguinte:

resource.type="k8s_cluster" protoPayload.response.reason="VIOLATES_POLICY"

11. Selecione Executar consulta.
12. 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.

Crie um pod Nginx para verificar se a regra de admissão do cluster é aplicada para bloquear todas as imagens (negar a criação)

Tarefa 8: negue imagens, exceto as dos registros de contêiner que estão na lista de permissões

1. 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.

2. Você vai usar a saída do comando abaixo como o caminho da sua imagem:

echo "gcr.io/${PROJECT_ID}/nginx*"

3. Copie a saída do caminho da imagem no seu buffer.

4. Acesse Menu de navegação > Segurança > Autorização binária.

5. 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.

6. Cole o caminho da imagem que você copiou anteriormente e clique em Concluído. A imagem abaixo mostra um exemplo de caminho.

7. Clique em Salvar política e execute este código:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Agora você já pode iniciar esse pod e provar que a função para adicionar registros à lista de permissões está funcionando corretamente.

8. Execute o código abaixo para fazer a limpeza e se preparar para as próximas etapas:

kubectl delete pod nginx

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.

Atualize a política de autorização binária para negar imagens, exceto as dos registros de contêiner que estão na lista de permissões (o registro de contêiner do seu projeto)

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

1. Nome/dados de e-mail do atestador:

ATTESTOR="manually-verified" # No spaces allowed ATTESTOR_NAME="Manual Attestor" ATTESTOR_EMAIL="$(gcloud config get-value core/account)" # This uses your current user/email

2. ID da observação do Container Analysis/descrição da autoridade de atestado:

NOTE_ID="Human-Attestor-Note" # No spaces NOTE_DESC="Human Attestation Note Demo"

3. Nomes de arquivos para criar payloads/solicitações:

NOTE_PAYLOAD_PATH="note_payload.json" IAM_REQUEST_JSON="iam_request.json"

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.

1. Crie o payload da observação ATTESTATION:

cat > ${NOTE_PAYLOAD_PATH} << EOF { "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}", "attestation_authority": { "hint": { "human_readable_name": "${NOTE_DESC}" } } } EOF

2. Envie a observação ATTESTATION à API Container Analysis:

curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @${NOTE_PAYLOAD_PATH} \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Você vai encontrar a observação criada na saída do comando anterior, mas o comando abaixo também a listará:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

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.

Observação: estas mensagens de erro estão relacionadas a esta atividade. A chave PGP não é protegida por senha neste exercício. Em um sistema de produção, é importante proteger as chaves PGP particulares de maneira adequada.

1. Configure outra variável de shell:

PGP_PUB_KEY="generated-key.pgp"

2. Crie a chave PGP:

sudo apt-get install rng-tools sudo rngd -r /dev/urandom gpg --quick-generate-key --yes ${ATTESTOR_EMAIL}

3. Pressione Enter para usar uma senha longa vazia e confirmar os avisos.

4. Extraia a chave PGP pública:

gpg --armor --export "${ATTESTOR_EMAIL}" > ${PGP_PUB_KEY}

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.

1. Crie o atestador na API Binary Authorization:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors create "${ATTESTOR}" \ --attestation-authority-note="${NOTE_ID}" \ --attestation-authority-note-project="${PROJECT_ID}"

2. Adicione a chave PGP ao atestador:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR}" \ --pgp-public-key-file="${PGP_PUB_KEY}"

3. Liste o atestador recém-criado:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors list

A saída será parecida com esta:

NAME: manually-verified NOTE: projects//notes/Human-Attestor-Note NUM_PUBLIC_KEYS: 1

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.

1. Defina algumas variáveis de shell:

GENERATED_PAYLOAD="generated_payload.json" GENERATED_SIGNATURE="generated_signature.pgp"

2. Para receber a impressão digital do PGP, execute o seguinte:

PGP_FINGERPRINT="$(gpg --list-keys ${ATTESTOR_EMAIL} | head -2 | tail -1 | awk '{print $1}')"

3. Para receber o resumo SHA256 da imagem do contêiner, execute:

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

4. Crie um payload de assinatura no formato JSON:

gcloud beta container binauthz create-signature-payload \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" > ${GENERATED_PAYLOAD}

5. Confira o payload de assinatura gerado:

cat "${GENERATED_PAYLOAD}"

6. "Assine" o payload com a chave PGP:

gpg --local-user "${ATTESTOR_EMAIL}" \ --armor \ --output ${GENERATED_SIGNATURE} \ --sign ${GENERATED_PAYLOAD}

7. Acesse a assinatura gerada (mensagem PGP):

cat "${GENERATED_SIGNATURE}"

8. Crie o atestado:

gcloud beta container binauthz attestations create \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \ --signature-file=${GENERATED_SIGNATURE} \ --public-key-id="${PGP_FINGERPRINT}"

9. Visualize o atestado recém-criado:

gcloud beta container binauthz attestations list \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}"

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.

1. Se quiser mudar a política para exigir um atestado, execute o comando abaixo e copie o caminho completo/nome da autoridade do atestado:

echo "projects/${PROJECT_ID}/attestors/${ATTESTOR}" # Copy this output to your copy/paste buffer

2. 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.

3. Selecione Require attestations (Allow only images that have been verified by all of the following attestors) em vez de Disallow all images na janela pop-up:

4. Em seguida, clique em Add Attestors e Add by attestor resource ID. Insira o conteúdo do buffer de copiar/colar no formato projects/${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.

5. Para receber o resumo SHA256 mais recente da imagem assinada das etapas anteriores:

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

6. 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:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "${IMAGE_PATH}@${IMAGE_DIGEST}" ports: - containerPort: 80 EOF

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.

Atualize a política de autorização binária para a regra específica do cluster permitir somente imagens aprovadas por atestadores

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.

Observação: é preciso informar a equipe de segurança sobre o ocorrido, porque isso pode ser aproveitado por usuários mal-intencionados que conseguem criar um pod.

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):

1. Para executar um contêiner nginx não atribuído com a anotação "Acesso imediato", use este comando:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx-alpha annotations: alpha.image-policy.k8s.io/break-glass: "true" spec: containers: - name: nginx image: "nginx:latest" ports: - containerPort: 80 EOF

2. No Console do Google Cloud, acesse Menu de navegação > Logging > página Análise de registros.

3. 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"

4. 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.

Observação: aguarde pelo menos de 5 a 10 minutos para os registros aparecerem.

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.

1. O script a seguir destruirá o cluster do Kubernetes Engine:

./delete.sh -c my-cluster-1

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:

Deleting cluster Observação: o comando de exclusão está sendo executado de maneira assíncrona, e o cluster levará alguns minutos para ser removido. Use a IU do console do Cloud ou o comando 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.

Eliminação (excluir cluster)

Os comandos a seguir removerão os outros recursos.

2. Exclua a imagem do contêiner enviada ao GCR:

gcloud container images delete "${IMAGE_PATH}@${IMAGE_DIGEST}" --force-delete-tags

3. Quando aparecer Do you want to continue (Y/n)? digite Y.

4. Exclua o atestador:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors delete "${ATTESTOR}"

5. Exclua a observação do Container Analysis:

curl -X DELETE \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Solucione problemas no seu ambiente

1. 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.
2. Execute o comando gcloud container clusters list para verificar o status do cluster.
3. 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. Use kubectl describe pod <podname> para encontrar o caminho do registro na especificação da imagem e adicione-o à lista de permissões no formato gcr.io/example-registry/*. Em seguida, salve a política.
4. Aumente sua cota no projeto se você receber erros relacionados a isso. Saiba mais na Documentação das cotas de recursos.

Materiais relevantes

1. Cotas do Google Cloud
2. Inscrever-se no Google Cloud
3. Google Cloud Shell
4. Autorização binária no GKE
5. Notas do Container Analysis
6. Controlador de admissão do Kubernetes
7. 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.