GSP480

Visão geral

Este laboratório mostra como melhorar a segurança do Kubernetes Engine aplicando restrições granulares à comunicação de rede.

O princípio de privilégio mínimo é amplamente reconhecido como uma importante prática de design para melhorar a proteção de sistemas essenciais contra falhas e comportamentos maliciosos. Ele sugere que cada componente deve acessar apenas as informações e os recursos necessários à finalidade legítima. Este documento demonstra como é possível implementar o princípio de privilégio mínimo na camada de rede do Kubernetes Engine.

As conexões de rede podem ser restritas em dois níveis da infraestrutura do Kubernetes Engine. O primeiro mecanismo, que é menos granular, consiste na aplicação de regras de firewall nos níveis de rede, sub-rede e host. Elas são aplicadas fora do Kubernetes Engine, no nível da VPC.

Embora o uso de regras de firewall seja uma medida de segurança eficiente, o Kubernetes permite que você defina regras ainda mais detalhadas com as políticas de rede, que são usadas para limitar a comunicação intracluster. Elas não se aplicam aos pods anexados ao namespace de rede do host.

Neste laboratório, você provisionará um cluster privado do Kubernetes Engine e um Bastion Host para acessá-lo. O Bastion Host fornece um único host com acesso ao cluster para garantir que ele não seja exposto a comportamentos nocivos da Internet, quando combinado com a rede privada do Kubernetes. Os Bastions são especialmente úteis quando você não tem acesso via VPN à rede da nuvem.

No cluster, um servidor HTTP simples e dois pods clientes serão provisionados. Você aprenderá a usar uma política de rede e rotular para permitir apenas conexões de um dos pods.

Este laboratório foi criado por engenheiros do GKE Helmsman para explicar a autorização binária do GKE. Para conferir esta demonstração, execute os comandos gsutil cp -r gs://spls/gke-binary-auth/* . e cd gke-binary-auth-demo no Cloud Shell. Incentivamos todos a contribuir com nossos recursos.

Arquitetura

Você vai definir um cluster privado do Kubernetes no modo padrão que usa o Dataplane V2. O Dataplane V2 tem políticas de rede ativadas por padrão.

Como o cluster é privado, a API e os nós de trabalho não estarão acessíveis na Internet. Neste caso, você definirá um Bastion Host e usará uma regra de firewall para acessá-lo. O endereço IP do Bastion é definido como uma rede autorizada para o cluster, o que garante o acesso dele à API.

No cluster, provisione três cargas de trabalho:

1. hello-server: é um servidor HTTP simples com um endpoint acessível internamente.
2. hello-client-allowed: é um único pod que tenta acessar o hello-server repetidamente. O pod é rotulado para a política de rede permitir que ele se conecte a hello-server.
3. hello-client-blocked: executa o mesmo código que hello-client-allowed, mas o pod é rotulado de tal forma que a política de rede não permite que ele se conecte a hello-server.

Configuração e requisitos

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.

Clone a demonstração

1. Copie de um bucket do Cloud Storage os recursos necessários para este exercício de laboratório:

gsutil cp -r gs://spls/gsp480/gke-network-policy-demo .

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

cd gke-network-policy-demo

3. Torne os arquivos de demonstração executáveis:

chmod -R 755 *

Tarefa 1: configuração do laboratório

Primeiro, defina a região e a zona do Google Cloud.

1. Defina a região do Google Cloud.

gcloud config set compute/region "{{{project_0.default_region|placeholder}}}"

2. Defina a zona do Google Cloud. gcloud config set compute/zone "{{{project_0.default_zone|placeholder}}}"

Este laboratório usará as seguintes APIs de serviço do Google Cloud, que já foram ativadas:

• compute.googleapis.com
• container.googleapis.com
• cloudbuild.googleapis.com

Além disso, a configuração do Terraform usa três parâmetros para determinar onde criar o cluster do Kubernetes Engine:

• project ID
• region
• zone

Para facilitar, esses parâmetros são especificados em um arquivo chamado terraform.tfvars, no diretório terraform.

3. Para garantir a ativação das APIs adequadas e gerar o arquivo terraform/terraform.tfvars com base nos seus padrões da gcloud, execute o seguinte comando:

make setup-project

4. Quando for solicitada uma confirmação, digite y.

Isso ativa as APIs de serviço necessárias e também gera um arquivo terraform/terraform.tfvars com as chaves a seguir.

5. Execute o código abaixo para verificar se os valores correspondem à saída de gcloud config list:

cat terraform/terraform.tfvars

Provisione o cluster do Kubernetes Engine

1. Agora aplique a configuração do Terraform à raiz do projeto:

make tf-apply

2. Quando solicitado, revise o plano gerado e insira yes para implantar o ambiente.

A implantação levará alguns minutos.

Tarefa 2: validação

O Terraform gera uma mensagem quando o cluster é criado.

...snip... google_container_cluster.primary: Still creating... (3m0s elapsed) google_container_cluster.primary: Still creating... (3m10s elapsed) google_container_cluster.primary: Still creating... (3m20s elapsed) google_container_cluster.primary: Still creating... (3m30s elapsed) google_container_cluster.primary: Creation complete after 3m34s (ID: gke-demo-cluster) Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

Teste a tarefa concluída

Clique em Verificar meu progresso para conferir a tarefa realizada. Se você tiver implantado a infraestrutura necessária com o Terraform, verá uma pontuação de avaliação.

Use o Terraform para configurar a infraestrutura necessária (configuração do laboratório)

1. Para as etapas restantes, acesse o Bastion por ssh:

gcloud compute ssh gke-demo-bastion

As versões atuais do kubectl e dos clientes personalizados do Kubernetes contêm código específico do provedor para gerenciar a autenticação entre o cliente e o Google Kubernetes Engine. A partir da versão 1.26, esse código não vai mais ser incluído como parte do OSS kubectl. Os usuários do GKE vão precisar fazer o download e usar um plug-in de autenticação separado para gerar tokens específicos do GKE. O novo binário, gke-gcloud-auth-plugin, usa o mecanismo do plug-in de credenciais do cliente Go do Kubernetes para ampliar a autenticação do kubectl e oferecer suporte ao GKE. Para mais informações, confira a documentação a seguir.

Para que o kubectl use o novo plug-in binário na autenticação em vez do código padrão específico do provedor, siga as etapas abaixo.

2. Depois de se conectar, execute o seguinte comando para instalar o gke-gcloud-auth-plugin na VM.

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. Configure export USE_GKE_GCLOUD_AUTH_PLUGIN=True em ~/.bashrc:

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. Execute este comando:

source ~/.bashrc

5. Execute o comando a seguir para forçar a atualização da configuração do cluster com a configuração do plug-in de credenciais do cliente Go.

gcloud container clusters get-credentials gke-demo-cluster --zone {{{project_0.default_zone|placeholder}}}

Se tudo der certo, você vai receber esta mensagem:

kubeconfig entry generated for gke-demo-cluster.

O cluster recém-criado estará disponível para os comandos kubectl padrão no Bastion.

Tarefa 3: instalação do hello-server

O aplicativo de teste consiste em um servidor HTTP simples, implantado como hello-server, e dois clientes: app=hello e app=not-hello.

Os três serviços podem ser implantados aplicando os manifestos hello-app.

1. No Bastion, execute o seguinte comando:

kubectl apply -f ./manifests/hello-app/

Saída:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created service/hello-server created deployment.apps/hello-server created

2. Verifique se os três pods foram implantados:

kubectl get pods

Você verá um pod em execução para cada uma das implantações hello-client-allowed, hello-client-blocked e hello-server.

NAME READY STATUS RESTARTS AGE hello-client-allowed-7d95fcd5d9-t8fsk | 1/1 Running 0 14m hello-client-blocked-6497db465d-ckbn8 | 1/1 Running 0 14m hello-server-7df58f7fb5-nvcvd | 1/1 Running 0 14m

Teste a tarefa concluída

Clique em Verificar meu progresso para conferir a tarefa realizada. Se você tiver realizado a implantação do hello-server HTTP simples, uma pontuação de avaliação será exibida.

Instalação do hello-server

Tarefa 4: confirmação do acesso padrão ao hello-server

1. Primeiro siga o cliente "allowed":

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Para sair, pressione Ctrl + C.

2. Em seguida, siga os registros do cliente "blocked":

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

3. Para sair, pressione Ctrl + C.

Você verá que os dois pods conseguem se conectar ao serviço hello-server. Isso ocorre porque você ainda não definiu uma política de rede para restringir o acesso. Em cada janela, você verá respostas bem-sucedidas do servidor.

Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd ...

Tarefa 5: restrição do acesso com uma política de rede

Agora você bloqueará o acesso ao pod hello-server de todos os pods sem o rótulo app=hello.

A definição da política que será usada está em manifests/network-policy.yaml.

1. Aplique a política com o seguinte comando:

kubectl apply -f ./manifests/network-policy.yaml

Saída:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

2. Siga novamente os registros do cliente "blocked":

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

Na janela que segue o cliente "blocked", você verá que a resposta será semelhante a esta:

wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out ...

A política de rede impediu a comunicação do pod sem rótulo com o hello-server.

3. Para sair, pressione Ctrl + C.

Tarefa 6: restrição de namespaces com políticas de rede

No exemplo anterior, você definiu uma política de rede que restringe as conexões com base nos rótulos dos pods. Muitas vezes, é útil rotular namespaces inteiros, principalmente quando equipes ou aplicativos recebem os próprios namespaces.

Agora você modificará a política de rede para só permitir tráfego de um namespace atribuído. Depois você moverá o pod hello-allowed para esse novo namespace.

1. Primeiro exclua a política de rede:

kubectl delete -f ./manifests/network-policy.yaml

Saída:

networkpolicy.networking.k8s.io "hello-server-allow-from-hello-client" deleted

2. Crie a versão com namespace:

kubectl create -f ./manifests/network-policy-namespaced.yaml

Saída:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

3. Observe os registros do pod hello-allowed-client no namespace padrão:

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Você verá que ele não consegue mais se conectar ao hello-server.

4. Para sair, pressione Ctrl + C.

5. Por fim, implante uma segunda cópia do app hello-clients no novo namespace.

kubectl -n hello-apps apply -f ./manifests/hello-app/hello-client.yaml

Saída:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created

Teste a tarefa concluída

Clique em Verificar meu progresso para conferir a tarefa realizada. Se você tiver implantado uma segunda cópia do app hello-clients no novo namespace, verá uma pontuação de avaliação.

Implante uma segunda cópia do app hello-clients no novo namespace

Tarefa 7: validação

Em seguida, verifique os registros dos dois novos clientes hello-app.

1. Para conferir os registros do app com o rótulo "hello" no namespace hello-apps, execute o seguinte comando:

kubectl logs --tail 10 -f -n hello-apps $(kubectl get pods -oname -l app=hello -n hello-apps)

Saída:

Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp

Os dois clientes conseguem se conectar porque desde o Kubernetes 1.10.x, as políticas de rede não aceitam restrição de acesso a pods em um determinado namespace. É possível conceder permissões por rótulo de pod, por rótulo de namespace ou para a junção (ou seja, OR) de ambos. No entanto, não é possível permitir a interseção (ou seja, AND) dos rótulos de pod e de namespace.

2. Para sair, pressione Ctrl + C.

Tarefa 8: eliminação

Embora o Qwiklabs se encarregue de desativar todos os recursos usados no laboratório, saiba como limpar seu ambiente para reduzir o custo e ser um bom usuário da nuvem:

1. Saia do Bastion Host:

exit

2. Para destruir o ambiente, execute o seguinte comando:

make teardown

Saída:

...snip... google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 20s elapsed) google_compute_subnetwork.cluster-subnet: Destruction complete after 25s google_compute_network.gke-network: Destroying... (ID: kube-net) google_compute_network.gke-network: Still destroying... (ID: kube-net, 10s elapsed) google_compute_network.gke-network: Still destroying... (ID: kube-net, 20s elapsed) google_compute_network.gke-network: Destruction complete after 26s Destroy complete! Resources: 5 destroyed.

Tarefa 9: solução de problemas no seu ambiente

O script de instalação falha com um erro de "permissão negada" ao executar o Terraform

As credenciais que o Terraform está usando não concedem as permissões necessárias para criar recursos nos projetos selecionados. Verifique se a conta listada em gcloud config list tem as permissões necessárias para criar recursos. Se tiver, gere novamente as credenciais padrão do aplicativo com gcloud auth application-default login.

Erro na validação da impressão digital em operações do Terraform

Durante a atualização de determinados recursos, o Terraform pode indicar que uma impressão digital é inválida.

Se o erro abaixo aparecer, execute novamente o comando.

Parabéns!

Você melhorou a segurança do Kubernetes Engine aplicando restrições granulares à comunicação da rede.

Termine a Quest

Este laboratório autoguiado faz parte da Quest Google Kubernetes Engine Best Practices: Security. 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. Confira o catálogo do Google Cloud Ensina para acessar todas as Quests disponíveis.

Comece o próximo laboratório

Continue a Quest com o laboratório Como aumentar a segurança das configurações padrão de clusters do GKE ou confira estes outros laboratórios do Google Cloud Ensina:

• Segurança do Google Kubernetes Engine: autorização binária
• Como usar o controle de acesso baseado em funções no Kubernetes Engine

Próximas etapas / Saiba mais

• Terraform Google Provider
• Políticas de rede do Kubernetes
• Kubernetes Engine – Como criar uma política de rede de cluster
• Kubernetes Engine – Tutorial de políticas de rede
• Kubernetes Engine – Como aumentar a segurança do seu cluster

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 18 de outubro de 2023

Laboratório testado em 18 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.