GSP493

Visão geral

Este laboratório aborda o uso e a depuração do controle de acesso baseado em funções (RBAC) em um cluster do Kubernetes Engine.

Embora as definições de recursos do RBAC sejam padrão em todas as plataformas Kubernetes, você precisa entender sua interação com os provedores de autenticação e autorização subjacentes ao criar em qualquer provedor de nuvem.

O RBAC é um mecanismo de segurança avançado que proporciona muitas formas de restringir as operações em um cluster. Este laboratório abrange dois casos de uso do RBAC:

1. Como atribuir permissões diferentes a perfis de usuários, ou seja, proprietários e auditores.
2. Como conceder acesso de API limitado a um aplicativo em execução no cluster.

Como a flexibilidade do RBAC às vezes pode resultar em regras complexas, apresentamos etapas comuns para solucionar problemas do RBAC no cenário 2.

Arquitetura

Este laboratório explica o uso do RBAC em um cluster do Kubernetes Engine. Ele mostra como conceder vários níveis de privilégio de cluster a perfis de usuário diferentes. Você provisionará duas contas de serviço para representar os perfis de usuário e três namespaces: "dev", "test" e "prod". O perfil "owner" terá acesso de leitura/gravação aos três namespaces, já o perfil "auditor" terá acesso somente leitura ao namespace "dev".

Este laboratório foi criado por engenheiros do GKE Helmsman para explicar o uso dos controles de acesso baseado em função no GKE. Confira esta demonstração no GitHub. Incentivamos todos a contribuir com nossos recursos.

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.

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}}}

Tarefa 1: clonar a demonstração

1. Faça o download dos recursos necessários para este laboratório executando o seguinte:

gsutil cp gs://spls/gsp493/gke-rbac-demo.tar . tar -xvf gke-rbac-demo.tar

2. Mude para o diretório extraído:

cd gke-rbac-demo

Provisionar o cluster do Kubernetes Engine

Aplique a configuração do Terraform.

1. Na raiz do projeto, use make para aplicar a configuração do Terraform:

make create

A configuração da demonstração leva de 10 a 15 minutos. Caso não haja erros, o melhor a fazer é esperar. A execução de make create não deve ser interrompida.

2. Nesse período, após a criação de google_compute_instance, verifique o progresso no console acessando Compute Engine > Instâncias de VM. Nessa página, use o botão Atualizar para ver informações mais atualizadas.

Após a conclusão, o Terraform mostra uma mensagem indicando a criação do cluster.

3. Confirme se o cluster foi criado corretamente no console. Acesse Menu de navegação > Kubernetes Engine > Clusters e clique no cluster criado. Verifique se a autorização legada está desativada no novo cluster.

Clique em Verificar meu progresso para conferir o objetivo. Provisionar o cluster do Kubernetes Engine

Tarefa 2: Cenário 1: atribuir permissões por perfil de usuário

IAM - papel

Um papel chamado kube-api-ro-xxxxxxxx (em que xxxxxxxx é uma string aleatória) foi criado com as permissões abaixo como parte da configuração do Terraform em iam.tf. Essas permissões representam o mínimo necessário para qualquer usuário que precise acessar a API Kubernetes.

• container.apiServices.get
• container.apiServices.list
• container.clusters.get
• container.clusters.getCredentials

Como simular usuários

Três contas de serviço foram criadas como usuários de teste:

• admin: tem permissões de administrador no cluster e em todos os recursos
• owner: tem permissões de leitura e gravação nos recursos de cluster comuns
• auditor: tem permissões somente leitura no namespace "dev"

1. Execute o comando a seguir:

gcloud iam service-accounts list

Três hosts de teste foram provisionados pelo script do Terraform. Cada nó tem o kubectl e o gcloud instalados e configurados para simular um perfil de usuário diferente.

• gke-tutorial-admin: kubectl e gcloud são autenticados como administradores de cluster.
• gke-tutorial-owner: simula a conta owner.
• gke-tutorial-auditor: simula a conta auditor.

2. Execute o comando a seguir:

gcloud compute instances list

Saída:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS rbac-demo-cluster-default-pool-a9cd3468-4vpc {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.5 RUNNING rbac-demo-cluster-default-pool-a9cd3468-b47f {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.6 RUNNING rbac-demo-cluster-default-pool-a9cd3468-rt5p {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.7 RUNNING gke-tutorial-auditor {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.4 35.224.148.28 RUNNING gke-tutorial-admin {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.3 35.226.237.142 RUNNING gke-tutorial-owner {{{project_0.default_zone|pZONE}}} f1-micro 10.0.96.2 35.194.58.130 RUNNING

Criar as regras do RBAC

Para criar os namespaces, os papéis e as vinculações de papéis, faça login na instância do administrador e aplique o manifesto rbac.yaml.

1. Estabeleça conexão SSH com a instância "admin":

gcloud compute ssh gke-tutorial-admin Ignore o erro relacionado ao plugin de autenticação gcp.

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 rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

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

Kubeconfig entry generated for dev-cluster.

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

6. Crie os namespaces, os papéis e as vinculações:

kubectl apply -f ./manifests/rbac.yaml

Saída:

namespace/dev created namespace/prod created namespace/test created role.rbac.authorization.k8s.io/dev-ro created clusterrole.rbac.authorization.k8s.io/all-rw created clusterrolebinding.rbac.authorization.k8s.io/owner-binding created rolebinding.rbac.authorization.k8s.io/auditor-binding created

Clique em Verificar meu progresso para conferir o objetivo. Como criar as regras do RBAC

Como gerenciar recursos com a conta de proprietário

1. Abra um novo terminal do Cloud Shell clicando em + na parte de cima da janela do terminal.

Estabeleça a conexão SSH com a instância "owner" e crie uma implantação simples em cada namespace.

2. Estabeleça a conexão SSH com a instância "owner":

gcloud compute ssh gke-tutorial-owner Ignore o erro relacionado ao plugin de autenticação gcp.

3. Quando precisar indicar a zona, digite n para usar a padrão.

4. Instale gke-gcloud-auth-plugin:

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. Crie um servidor em cada namespace, começando por dev:

kubectl create -n dev -f ./manifests/hello-server.yaml

Saída:

service/hello-server created deployment.apps/hello-server created

6. Depois crie prod:

kubectl create -n prod -f ./manifests/hello-server.yaml

Saída:

service/hello-server created deployment.apps/hello-server created

7. Por fim, crie test:

kubectl create -n test -f ./manifests/hello-server.yaml

Saída:

service/hello-server created deployment.apps/hello-server created

Clique em Verificar meu progresso para conferir o objetivo. Crie um servidor em cada namespace

Como proprietário, você também poderá consultar todos os pods.

• Na instância "owner", liste os pods hello-server nos namespaces executando o seguinte:

kubectl get pods -l app=hello-server --all-namespaces

Saída:

NAMESPACE NAME READY STATUS RESTARTS AGE dev hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 6m prod hello-server-6c6fd59cc9-mw2zt 1/1 Running 0 44s test hello-server-6c6fd59cc9-sm6bs 1/1 Running 0 39s

Consultar recursos com a conta de auditor

Abra um novo terminal, estabeleça a conexão SSH com a instância "auditor" e tente verificar todos os namespaces.

1. Abra um novo terminal do Cloud Shell clicando em + na parte de cima da janela do terminal.

2. Estabeleça a conexão SSH com a instância "auditor":

gcloud compute ssh gke-tutorial-auditor Ignore o erro relacionado ao plugin de autenticação gcp.

3. Quando precisar indicar a zona, digite n para usar a padrão.

4. Instale gke-gcloud-auth-plugin:

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. Na instância "auditor", liste os pods hello-server nos namespaces executando o seguinte:

kubectl get pods -l app=hello-server --all-namespaces

Você receberá este erro:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods at the cluster scope: Required "container.pods.list" permission

O erro indica que você não tem permissões suficientes. O papel de auditor é restrito à visualização dos recursos no namespace "dev". Por isso, você precisará especificar o namespace para ver os recursos.

Agora tente ver os pods no namespace "dev".

6. Na instância "auditor", execute o seguinte:

kubectl get pods -l app=hello-server --namespace=dev

Saída:

NAME READY STATUS RESTARTS AGE hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 13m

7. Tente consultar os pods no namespace "test":

kubectl get pods -l app=hello-server --namespace=test

Saída:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "test": Required "container.pods.list" permission.

8. Tente consultar os pods no namespace "prod":

kubectl get pods -l app=hello-server --namespace=prod

Saída:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "prod": Required "container.pods.list" permission.

Por fim, para verificar se o auditor tem acesso somente leitura, tente criar e excluir uma implantação no namespace "dev".

9. Na instância "auditor", tente criar uma implantação:

kubectl create -n dev -f manifests/hello-server.yaml

Saída:

Error from server (Forbidden): error when creating "manifests/hello-server.yaml": services is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create services in the namespace "dev": Required "container.services.create" permission. Error from server (Forbidden): error when creating "manifests/hello-server.yaml": deployments.extensions is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create deployments.extensions in the namespace "dev": Required "container.deployments.create" permission.

10. Na instância "auditor", tente excluir a implantação:

kubectl delete deployment -n dev -l app=hello-server

Saída:

Error from server (Forbidden): deployments.extensions "hello-server" is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot update deployments.extensions in the namespace "dev": Required "container.deployments.update" permission.

Tarefa 3: Cenário 2: atribuir permissões de API a um aplicativo de cluster

Neste cenário, você verá o processo de implantação de um aplicativo que requer acesso à API Kubernetes. Além disso, você irá configurar as regras do RBAC e solucionar alguns casos de uso comuns.

Como implantar o aplicativo de amostra

O aplicativo de amostra será executado como um único pod que recupera periodicamente todos os pods no namespace padrão do servidor de API e aplica um carimbo de data/hora a cada um deles.

1. Na instância do admin (sua primeira guia do Cloud Shell), implante o aplicativo pod-labeler. Isso também implantará um papel, uma conta de serviço e uma vinculação de papéis para o pod:

kubectl apply -f manifests/pod-labeler.yaml

Saída:

role.rbac.authorization.k8s.io/pod-labeler created serviceaccount/pod-labeler created rolebinding.rbac.authorization.k8s.io/pod-labeler created deployment.apps/pod-labeler created

Clique em Verificar meu progresso para conferir o objetivo. Como implantar o aplicativo de amostra

Como diagnosticar uma configuração incorreta do RBAC

Verifique o status do pod. Após a criação do contêiner, aparecerá um erro. Investigue o erro examinando os eventos e os registros dos pods.

1. Na instância admin, verifique o status do pod:

kubectl get pods -l app=pod-labeler

Saída:

NAME READY STATUS RESTARTS AGE pod-labeler-6d9757c488-tk6sp 0/1 Error 1 1m

2. Na instância admin, execute o código abaixo e confira o fluxo de eventos do pod:

kubectl describe pod -l app=pod-labeler | tail -n 20

Você receberá:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 7m35s default-scheduler Successfully assigned default/pod-labeler-5b4bd6cf9-w66jd to gke-rbac-demo-cluster-default-pool-3d348201-x0pk Normal Pulling 7m34s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk pulling image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Pulled 6m56s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Successfully pulled image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Created 5m29s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Created container Normal Pulled 5m29s (x4 over 6m54s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Container image "gcr.io/pso-examples/pod-labeler:0.1.5" already present on machine Normal Started 5m28s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Started container Warning BackOff 2m25s (x23 over 6m52s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Back-off restarting failed container

3. Para verificar os registros do pod na instância admin, execute o seguinte:

kubectl logs -l app=pod-labeler

Saída:

Attempting to list pods Traceback (most recent call last): File "label_pods.py", line 13, in ret = v1.list_namespaced_pod("default",watch=False) File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12310, in list_namespaced_pod File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12413, in list_namespaced_pod_with_http_info File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 321, in call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 155, in __call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 342, in request File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 231, in GET File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 222, in request kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Date': 'Fri, 25 May 2018 15:33:15 GMT', 'Audit-Id': 'ae2a0d7c-2ab0-4f1f-bd0f-24107d3c144e', 'Content-Length': '307', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods is forbidden: User \"system:serviceaccount:default:default\" cannot list pods in the namespace \"default\": Unknown user \"system:serviceaccount:default:default\"","reason":"Forbidden","details":{"kind":"pods"},"code":403}

Com base nesse erro, aparece um erro de permissão quando você tenta listar pods pela API.

4. A próxima etapa é confirmar se você está usando a conta de serviço correta.

Como corrigir o nome da conta de serviço

Examine a configuração do pod e verifique se ele está usando a conta de serviço padrão, em vez da personalizada.

1. Na instância admin, execute:

kubectl get pod -oyaml -l app=pod-labeler

Saída:

restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 9999 runAsGroup: 9999 runAsUser: 9999 serviceAccount: default

O arquivo pod-labeler-fix-1.yaml contém a correção especificada no modelo da implantação:

# Fix 1, set the serviceAccount so RBAC rules apply serviceAccount: pod-labeler

Aplique a correção e verifique a mudança resultante.

2. Na instância admin, aplique a correção 1 executando o seguinte:

kubectl apply -f manifests/pod-labeler-fix-1.yaml

Saída:

role.rbac.authorization.k8s.io/pod-labeler unchanged serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler configured

3. Verifique a mudança na configuração da implantação:

kubectl get deployment pod-labeler -oyaml

Mudanças na resposta:

... restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: pod-labeler ...

Clique em Verificar meu progresso para conferir o objetivo. Como corrigir o nome da conta de serviço

Como diagnosticar privilégios insuficientes

Ao verificar o status do pod novamente, você vai verificar que ele ainda apresenta um erro, mas agora com outra mensagem.

1. Na instância admin, verifique o status do pod:

kubectl get pods -l app=pod-labeler

Saída:

NAME READY STATUS RESTARTS AGE pod-labeler-c7b4fd44d-mr8qh 0/1 CrashLoopBackOff 3 1m

Talvez seja necessário executar o comando anterior novamente para consultar essa resposta.

2. Na instância admin, verifique os registros do pod:

kubectl logs -l app=pod-labeler

Saída:

File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 292, in PATCH return self.request("PATCH", url, File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 231, in request raise ApiException(http_resp=r) kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Audit-Id': 'f6c67c34-171f-42f3-b1c9-833e00cedd5e', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff', 'Date': 'Mon, 23 Mar 2020 16:35:18 GMT', 'Content-Length': '358'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \"pod-labeler-659c8c99d5-t96pw\" is forbidden: User \"system:serviceaccount:default:pod-labeler\" cannot patch resource \"pods\" in API group \"\" in the namespace \"default\"","reason":"Forbidden","details":{"name":"pod-labeler-659c8c99d5-t96pw","kind":"pods"},"code":403}

Como há falha em uma operação de PATCH, o erro também aparece no Stackdriver. Isso é útil quando os registros do aplicativo não têm níveis de detalhes suficientes.

3. No console, selecione Menu de navegação e, na seção "Operações", clique em Registros.

4. Na caixa de diálogo do Criador de consultas, cole o seguinte código e clique em Executar consulta:

protoPayload.methodName="io.k8s.core.v1.pods.patch"

5. Clique na seta para baixo ao lado do registro e consulte os detalhes.

Identificar o papel e as permissões do aplicativo

Use a vinculação de papéis do cluster para encontrar o papel e as permissões da conta de serviço.

1. Na instância admin, inspecione a definição rolebinding:

kubectl get rolebinding pod-labeler -oyaml

Saída:

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"Role","name":"pod-labeler"},"subjects":[{"kind":"ServiceAccount","name":"pod-labeler"}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2886" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/pod-labeler uid: 0e4d5be7-d986-40d0-af1d-a660f9aa4336 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-labeler subjects: - kind: ServiceAccount name: pod-labeler

A definição RoleBinding mostra que você precisa inspecionar o papel pod-labeler no namespace padrão. Verifique neste exemplo que o papel só tem permissão para listar pods.

2. Na instância admin, verifique a definição do papel pod-labeler:

kubectl get role pod-labeler -oyaml

Saída:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2883" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list

Como o aplicativo requer permissões de PATCH, agora você o adicionará à lista "verbs" do papel.

O arquivo pod-labeler-fix-2.yaml contém a correção na seção "rules/verbs":

rules: - apiGroups: [""] # "" refers to the core API group resources: ["pods"] verbs: ["list","patch"] # Fix 2: adding permission to patch (update) pods

Aplique a correção e verifique a configuração resultante.

3. Na instância admin, aplique fix-2:

kubectl apply -f manifests/pod-labeler-fix-2.yaml

Saída:

role.rbac.authorization.k8s.io/pod-labeler configured serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler unchanged

Clique em Verificar meu progresso para conferir o objetivo. Identificar o papel e as permissões do aplicativo

4. Na instância admin, confira a mudança resultante:

kubectl get role pod-labeler -oyaml

Saída:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list","patch"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "8802" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list - patch

Como pod-labeler talvez esteja em um loop de falha, a maneira mais rápida de testar a correção é eliminar o pod atual e deixar um novo assumir seu lugar.

5. Na instância admin, execute o código abaixo para eliminar o pod atual e deixar que o controlador de implantação o substitua:

kubectl delete pod -l app=pod-labeler

Saída:

pod "pod-labeler-659c8c99d5-t96pw" deleted

Verificar a configuração

Por fim, verifique se o novo pod-labeler está em execução e se o rótulo "atualizado" foi aplicado.

1. Na instância admin, liste todos os pods e confira os rótulos:

kubectl get pods --show-labels

Saída:

NAME READY STATUS RESTARTS NAME READY STATUS RESTARTS AGE LABELS pod-labeler-659c8c99d5-5qsmw 1/1 Running 0 31s app=pod-labeler,pod-template-hash=659c8c99d5,updated=1584982487.6428008

2. Verifique nos registros do pod se não há mais erros:

kubectl logs -l app=pod-labeler

Saída:

Attempting to list pods labeling pod pod-labeler-659c8c99d5-5qsmw labeling pod pod-labeler-659c8c99d5-t96pw ...

Pontos-chave

• Nos registros do contêiner e do servidor de API, você encontra as melhores pistas para diagnosticar problemas do RBAC.
• Use "RoleBindings" ou "ClusterRoleBindings" para identificar o papel que está especificando as permissões do pod.
• Os registros do servidor de API estão localizados no recurso Kubernetes do Stackdriver.
• Nem todas as chamadas de API são registradas no Stackdriver. Os payloads frequentes ou detalhados são omitidos pela política de auditoria do Kubernetes usada no Kubernetes Engine. A política exata varia de acordo com a versão do Kubernetes, mas pode ser encontrada na base de código aberto.

Tarefa 4: Eliminação

Quando terminar e quiser limpar os recursos criados, execute este comando para removê-los:

1. Digite exit para sair do Bastion Host.

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

make teardown

Saída:

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

Clique em Verificar meu progresso para conferir o objetivo. Eliminação

Tarefa 5: Solução de problemas no seu ambiente

Ocorre uma falha no script de instalação, e a mensagem Permission denied é exibida na execução do 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. Execute novamente o comando se você receber um erro com a mensagem: Error: Error applying plan e depois liste estes erros:

• module.network.google_compute_subnetwork.cluster-subnet: 1 error(s) occurred
• google.compute_subnetwork.cluster-subnet: Error updating subnetwork /kube-net-subnet: googleapi: Error412: Invalid fingerprint, conditionNotMet

Parabéns!

Você aprendeu a usar o controle de acesso baseado em função (RBAC) atribuindo permissões diferentes aos perfis dos usuários e concedendo acesso limitado à API a um aplicativo em execução no seu cluster.

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. 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 sua Quest com Segurança do Google Kubernetes Engine: autorização binária ou confira o conteúdo a seguir:

• Aumentar a segurança das configurações padrão de cluster do GKE

Próximas etapas / Saiba mais

• Configurar o controle de acesso baseado em função
• Criar políticas do IAM
• Autenticação de conta de serviço do Kubernetes
• Documentação do Terraform

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

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