GSP496

Visão geral

Este laboratório mostra alguns riscos de segurança de uma configuração padrão do cluster do GKE e as medidas de proteção necessárias para evitar escapes do pod e escalonamento de privilégios do cluster. Os caminhos de ataque são relevantes nos seguintes cenários:

1. Uma falha do aplicativo em um pod externo que permite ataques de falsificação de solicitação do lado do servidor (SSRF)
2. Um contêiner totalmente comprometido em um pod que permite a execução de comando remoto (RCE)
3. Um usuário interno mal-intencionado ou um invasor com credenciais comprometidas que permitem criar/atualizar um pod em um determinado namespace

Este laboratório, criado por engenheiros do GKE Helmsman, explica como aumentar a segurança das configurações padrão do cluster do GKE.

*O código de exemplo deste laboratório é fornecido no estado em que se encontra, sem provisões ou garantias*

Objetivos

Após concluir o laboratório, você entenderá a necessidade de proteger os metadados da instância do GKE e definir políticas PodSecurityPolicy adequadas ao seu ambiente.

Você realizará as seguintes ações:

1. Criar um pequeno cluster do GKE usando as configurações padrão
2. Validar os caminhos mais comuns de escape do pod e o escalonamento de privilégios do cluster da perspectiva de um usuário interno mal-intencionado
3. Aumentar a proteção do cluster do GKE para resolver esses problemas
4. Validar o cluster para que essas ações não sejam mais permitidas

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.

Tarefa 1: crie um cluster simples do GKE

1. Defina uma zona em uma variável de ambiente chamada MY_ZONE. Este laboratório usa "". Você pode selecionar uma zona se preferir:

export MY_ZONE={{{project_0.default_zone|ZONE}}}

2. Execute este comando para iniciar o cluster do Kubernetes simplecluster que é gerenciado pelo Kubernetes Engine. Depois configure-o para processar dois nós:

gcloud container clusters create simplecluster --zone $MY_ZONE --num-nodes 2 --metadata=disable-legacy-endpoints=false --cluster-version=1.24

A criação de um cluster leva alguns minutos porque o Kubernetes Engine provisiona as máquinas virtuais. Neste laboratório, os avisos sobre os recursos disponíveis nas novas versões podem ser ignorados.

3. Após a criação do cluster, verifique a versão instalada do Kubernetes com o comando kubectl version:

kubectl version

O comando gcloud container clusters create autentica automaticamente a kubectl.

4. Confira os nós em execução no console do GCP. No Menu de navegação, clique em Compute Engine > Instâncias de VM.

O cluster do Kubernetes está pronto para ser usado.

Clique em Verificar meu progresso para conferir o objetivo. Crie um cluster simples do GKE

Tarefa 2: execute um pod do SDK do Google Cloud

1. No prompt do Cloud Shell, inicie uma única instância do contêiner do SDK do Google Cloud:

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Esse processo leva alguns minutos.

Observação: se você receber um erro de expiração, execute o comando de novo.

2. No contêiner do pod, agora há um shell bash:

root@gcloud:/#

Pode levar alguns segundos para o contêiner iniciar e o prompt de comando aparecer. Caso o prompt de comando não seja exibido, pressione Enter.

Confira o endpoint do Compute Metadata

1. Execute o comando a seguir para acessar o endpoint v1 do Compute Metadata:

curl -s http://metadata.google.internal/computeMetadata/v1/instance/name

A resposta será semelhante a esta:

...snip... Your client does not have permission to get URL /computeMetadata/v1/instance/name from this server. Missing Metadata-Flavor:Google header. ...snip...

Perceba que um erro aparece e informa que um cabeçalho HTTP personalizado está faltando.

2. Adicione o cabeçalho personalizado na próxima execução e recupere o nome da instância do Compute Engine que executa o pod:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

A resposta será semelhante a esta:

gke-simplecluster-default-pool-b57a043a-6z5v Observação: se um cabeçalho HTTP personalizado não for necessário para acessar um endpoint de metadados da instância do Compute Engine, um invasor poderia precisar apenas de uma falha no aplicativo para burlar um URL da Web e fornecer as credenciais do usuário. Ao exigir um cabeçalho HTTP personalizado, um ataque será mais difícil, porque o invasor precisaria de uma falha no aplicativo e de um cabeçalho personalizado.

Mantenha o shell no pod disponível para a próxima etapa.

3. Caso você saia acidentalmente do pod, execute novamente o seguinte comando:

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Analise as credenciais de bootstrapping do nó do GKE

1. No mesmo shell do pod, execute o comando a seguir para listar os atributos associados às instâncias subjacentes do GCE. Lembre-se de incluir a barra final:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Talvez o dado mais confidencial da listagem seja kube-env. Ele contém diversas variáveis usadas pelo kubelet como credenciais iniciais ao anexar o nó ao cluster do GKE. As variáveis CA_CERT, KUBELET_CERT e KUBELET_KEY contêm essas informações e são consideradas confidenciais a administradores fora do cluster.

2. Para conferir as variáveis e os dados possivelmente confidenciais, execute o seguinte comando:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

Considere as situações abaixo:

• Uma falha que permita SSRF em um aplicativo de pod
• Uma falha do aplicativo ou biblioteca que permita RCE em um pod
• Um usuário interno com permissão para criar ou executar no pod

Nesses casos, há uma grande probabilidade de comprometimento e exfiltração das credenciais confidenciais de bootstrapping do kubelet pelo endpoint do Compute Metadata. É possível usar as credenciais do kubelet em algumas situações e escalonar os privilégios para cluster-admin. Isso permite controle total do cluster do GKE, inclusive dos dados, aplicativos e acessos aos nós subjacentes.

Use as permissões atribuídas à conta de serviço do pool do nó

Por padrão, os projetos do Google Cloud com a API Compute ativada têm uma conta de serviço no formato NNNNNNNNNN-compute@developer.gserviceaccount.com no projeto e o papel Editor anexado a ela. Os clusters do GKE criados sem a especificação de uma conta de serviço usam a conta de serviço padrão do Compute e a anexam a todos os nós de trabalho.

1. Execute o seguinte comando curl para listar os escopos do OAuth associados à conta de serviço anexada à instância subjacente do Compute Engine:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes

(Resposta)

https://www.googleapis.com/auth/devstorage.read_only https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/service.management.readonly https://www.googleapis.com/auth/servicecontrol https://www.googleapis.com/auth/trace.append

A combinação dos escopos de autenticação e as permissões da conta de serviço determinam quais aplicativos podem ser acessados nesse nó. A lista acima mostra os escopos mínimos necessários para a maioria dos clusters do GKE, mas alguns casos de uso exigem escopos maiores.

Aviso: se, durante a criação do cluster, você configurou o escopo da autenticação para incluir "https://www.googleapis.com/auth/cloud-platform", qualquer API Google Cloud estaria no escopo, e apenas as permissões do IAM atribuídas à conta de serviço determinariam o acesso.

Além disso, se a conta de serviço padrão com o papel Editor do IAM estiver em uso, qualquer pod nesse pool de nós teria permissões de Editor no projeto do Google Cloud em que o cluster do GKE estiver implantado. O papel Editor do IAM tem várias permissões de leitura/gravação para interagir com os recursos do projeto, como instâncias do Compute, buckets do Cloud Storage, registros do GCR, entre outros, o que provavelmente não é o desejado

2. Para sair do pod, digite:

exit Observação: se não voltar ao Cloud Shell, pressione ctrl+c

Tarefa 3: implante um pod que monte o sistema de arquivos do host

Um dos caminhos mais simples de aplicar o escape ao host subjacente é montando o sistema de arquivos do host no do pod com volumes e volumeMounts padrão do Kubernetes em uma especificação Pod.

1. Isso pode ser demonstrado executando o seguinte comando para criar um pod que monte o sistema de arquivos / subjacente do host em uma pasta chamada /rootfs no contêiner:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

2. Execute kubectl get pod e faça isso novamente até que ele atinja o estado "Running":

kubectl get pod

(Saída)

NAME READY STATUS RESTARTS AGE hostpath 1/1 Running 0 30s

Clique em Verificar meu progresso para conferir o objetivo. Implante um pod que monte o sistema de arquivos do host

Tarefa 4: analise e comprometa o host subjacente

1. Execute o seguinte comando para incluir um shell no pod recém-criado:

kubectl exec -it hostpath -- bash

2. Mude o ponto do sistema de arquivos raiz do shell do pod para o do host subjacente:

chroot /rootfs /bin/bash

Com esses comandos simples, o pod agora é um shell root no nó. Faça o seguinte:

Execute o comando padrão do Docker com permissão total	docker ps
Liste as imagens do Docker	docker images
Use docker run em um contêiner privilegiado que preferir	docker run --privileged <imagename>:<imageversion>
Analise os secrets ativos do Kubernetes	mount | grep volumes | awk '{print $3}' | xargs ls
Use exec em qualquer contêiner em execução (mesmo em outro pod e namespace).	docker exec -it <docker container ID> sh

Quase todas as operações que podem ser feitas pelo usuário root estão disponíveis nesse shell do pod. Isso inclui mecanismos de persistência, como adição de usuários/chaves SSH, execução de contêineres privilegiados do Docker no host fora da visualização do Kubernetes, entre outras funções.

3. Execute exit duas vezes: uma para deixar o chroot e outra para sair do shell do pod:

exit exit Observação: se não voltar ao Cloud Shell, pressione ctrl+c

4. Agora exclua o pod hostpath:

kubectl delete pod hostpath

Entenda os controles disponíveis

As próximas etapas vão demonstrar os seguintes tópicos:

• Como desativar o endpoint legado da API de metadados do Compute Engine: ao especificar uma chave e um valor de metadados personalizados, o endpoint v1beta1 não ficará mais disponível na instância.
• Ativar a ocultação de metadados: ao passar uma configuração adicional durante a criação do cluster e/ou do pool de nós, um proxy leve será instalado em cada nó para todas as solicitações da API de metadados e impedirá o acesso a endpoints confidenciais.
• Ativar e configurar o PodSecurityPolicy: configurar essa opção em um cluster do GKE adicionará o controle de admissão PodSecurityPolicy, que ajuda a restringir o uso de definições não protegidas na criação do pod. No caso da demonstração, você impedirá que contêineres operem como usuário raiz ou tenham a capacidade de ativar o sistema de arquivos de host subjacente.

Tarefa 5: implante um segundo pool de nós

Para que você tenha experiências com e sem a proteção do endpoint de metadados, será criado um segundo pool de nós que incluirá duas configurações adicionais. Os pods programados para o pool de nós genérico não terão proteção. Já os programados para o segundo pool de nós contarão com essa segurança.

Observação: endpoints legados foram suspensos em 30 de setembro de 2020. Nas versões 1.12 e mais recentes do GKE, a configuração "--metadata=disable-legacy-endpoints=true" será ativada automaticamente. O comando a seguir define isso.

• Crie o segundo pool de nós:

gcloud beta container node-pools create second-pool --cluster=simplecluster --zone=$MY_ZONE --num-nodes=1 --metadata=disable-legacy-endpoints=true --workload-metadata-from-node=SECURE

Clique em Verificar meu progresso para conferir o objetivo. Implante um segundo pool de nós

Tarefa 6: execute um pod do SDK do Google Cloud

1. No Cloud Shell, inicie uma única instância do contêiner do SDK do Google Cloud. Ela será executada apenas no segundo pool de nós com as proteções ativadas, sem operar como o usuário raiz:

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never --overrides='{ "apiVersion": "v1", "spec": { "securityContext": { "runAsUser": 65534, "fsGroup": 65534 }, "nodeSelector": { "cloud.google.com/gke-nodepool": "second-pool" } } }' -- bash Observação: se você receber um erro de expiração, execute o comando de novo.

2. Haverá um shell bash em execução no contêiner do pod no pool de nós second-pool. Isto vai aparecer:

nobody@gcloud:/$

Pode levar alguns segundos para o contêiner iniciar e o prompt de comando abrir.

Se um prompt de comando não for exibido, pressione Enter.

Analise vários endpoints bloqueados

1. Com a configuração do segundo pool de nós definida como --workload-metadata-from-node=SECURE, o comando abaixo para recuperar o arquivo confidencial, kube-env, apresentará falha:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

(Saída)

This metadata endpoint is concealed.

2. No entanto, outros comandos a endpoints não confidenciais ainda terão sucesso se o cabeçalho HTTP adequado tiver passado:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

Exemplo de saída

gke-simplecluster-second-pool-8fbd68c5-gzzp

3. Saia do pod:

exit

Você voltará ao Cloud Shell.

Tarefa 7: implante objetos PodSecurityPolicy

1. Para avançar, conceda permissões explícitas para transformar sua conta de usuário em cluster-admin:

kubectl create clusterrolebinding clusteradmin --clusterrole=cluster-admin --user="$(gcloud config list account --format 'value(core.account)')"

(Saída)

clusterrolebinding.rbac.authorization.k8s.io/clusteradmin created

2. Em seguida, implante um PodSecurityPolicy mais restrito em todos os usuários autenticados no namespace padrão:

cat <<EOF | kubectl apply -f - --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restrictive-psp annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' # Assume that persistentVolumes set up by the cluster admin are safe to use. - 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot' seLinux: # This policy assumes the nodes are using AppArmor rather than SELinux. rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 EOF

(Saída)

podsecuritypolicy.extensions/restrictive-psp created

3. Depois adicione o ClusterRole que oferece a capacidade necessária para "usar" o PodSecurityPolicy:

cat <<EOF | kubectl apply -f - --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: restrictive-psp rules: - apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - restrictive-psp verbs: - use EOF

(Saída)

clusterrole.rbac.authorization.k8s.io/restrictive-psp created

4. Por fim, crie um RoleBinding no namespace padrão para que qualquer permissão de usuário autenticado use o PodSecurityPolicy:

cat <<EOF | kubectl apply -f - --- # All service accounts in kube-system # can 'use' the 'permissive-psp' PSP apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: restrictive-psp namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restrictive-psp subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated EOF

(Saída)

rolebinding.rbac.authorization.k8s.io/restrictive-psp created Observação: em um ambiente real, considere substituir o usuário system:authenticated no RoleBinding pelo usuário específico ou pela conta de serviço que precisa da capacidade de criar pods no namespace padrão.

Clique em Verificar meu progresso para conferir o objetivo. Implante objetos PodSecurityPolicy

Ative a política do PodSecurity

• Ativar o controlador de permissão PodSecurityPolicy:

gcloud beta container clusters update simplecluster --zone $MY_ZONE --enable-pod-security-policy

Esse processo leva alguns minutos para ser concluído.

Tarefa 8: implante um pod bloqueado que ative o sistema de arquivos do host

Como a conta usada para implantar o cluster do GKE recebeu permissões cluster-admin em uma etapa anterior, é necessário criar uma conta de "usuário" separada para interagir com o cluster e validar a aplicação do PodSecurityPolicy.

1. Para fazer isso, execute:

gcloud iam service-accounts create demo-developer

(Saída)

Created service account [demo-developer].

2. Agora execute os comandos abaixo para conceder à conta de serviço permissão para interagir com o cluster e tentar criar pods:

MYPROJECT=$(gcloud config list --format 'value(core.project)') gcloud projects add-iam-policy-binding "${MYPROJECT}" --role=roles/container.developer --member="serviceAccount:demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

3. Para ter acesso ao arquivo das credenciais da conta de serviço, execute este código:

gcloud iam service-accounts keys create key.json --iam-account "demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

4. Configure kubectl para autenticar como esta conta de serviço:

gcloud auth activate-service-account --key-file=key.json

5. Execute o código abaixo para configurar kubectl a usar as credenciais ao se comunicar com o cluster:

gcloud container clusters get-credentials simplecluster --zone $MY_ZONE

6. Agora tente criar outro pod que ative o sistema de arquivos / do host subjacente em uma pasta chamada /rootfs no contêiner:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

7. Esta resposta valida o bloqueio por PSP:

Error from server (Forbidden): error when creating "STDIN": pods "hostpath" is forbidden: unable to validate against any pod security policy: [spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used]

8. Implante outro pod que atenda aos critérios do restrictive-psp:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: securityContext: runAsUser: 1000 fsGroup: 2000 containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] EOF

(Saída)

pod/hostpath created

9. Execute o código abaixo para conferir a anotação adicionada ao pod indicando qual PodSecurityPolicy autorizou a criação:

kubectl get pod hostpath -o=jsonpath="{ .metadata.annotations.kubernetes\.io/psp }"

Resposta anexada à linha de comando do Cloud Shell:

restrictive-psp

Clique em Verificar meu progresso para conferir o objetivo. Implante um pod bloqueado que ative o sistema de arquivos do host

Parabéns!

Neste laboratório, você configurou um cluster padrão do Kubernetes no Google Kubernetes Engine. Em seguida, você sondou e analisou o acesso disponível ao pod, aumentou a proteção do cluster e confirmou que ações nocivas não são mais possíveis.

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. Você pode publicar os selos com um link para eles no seu currículo on-line ou nas redes sociais. Inscreva-se nesta Quest ou em outra que tenha este laboratório para receber os créditos de conclusão imediatamente. Consulte o catálogo do Google Cloud Ensina para ver todas as Quests disponíveis.

Comece o próximo laboratório

Continue a quest com Google Kubernetes Engine Security: Binary Authorization ou confira estes laboratórios do Google Cloud Ensina:

• Segurança de aplicativos no Kubernetes Engine – Três exemplos
• Como usar o controle de acesso baseado em papel no Kubernetes Engine

Próximas etapas / Saiba mais

IMPORTANTE: embora este laboratório aborde várias questões de segurança de forma detalhada, há outras áreas que precisam ser consideradas no seu ambiente. Consulte o Guia para aumentar a segurança do cluster para mais informações.

PodSecurityPolicy: Guia sobre como usar PodSecurityPolicies e Guia para aumentar a segurança do cluster

Contas de serviço do nó: Guia de permissões

Como proteger os metadados do nó: Guia sobre como proteger os metadados do nó

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 3 de outubro de 2023

Laboratório testado em 9 de outubro de 2023

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.