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 Começar o Laboratório

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é ativado quando você clica em Iniciar 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, e 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 (recomendado) ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e de estudante, o que poderia causar cobranças extras na sua conta pessoal.

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

Observação: use apenas a conta de estudante neste laboratório. Se usar outra conta do Google Cloud, você poderá receber cobranças nela.

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 por ele, uma caixa de diálogo vai aparecer para você selecionar a forma de pagamento. No painel Detalhes do Laboratório, à esquerda, você vai encontrar o seguinte:

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

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página Fazer Login em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.

   {{{user_0.username | "Username"}}}

   Você também encontra o nome de usuário no painel Detalhes do Laboratório.

4. Clique em Próxima.

5. Copie a Senha abaixo e cole na caixa de diálogo de Olá.

   {{{user_0.password | "Password"}}}

   Você também encontra a senha no painel Detalhes do Laboratório.

6. Clique em Próxima.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: para acessar os produtos e serviços do Google Cloud, clique no Menu de navegação ou digite o nome do serviço ou produto no campo Pesquisar.

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.

2. Clique nas seguintes janelas:

   • Continue na janela de informações do Cloud Shell.
   • Autorize o Cloud Shell a usar suas credenciais para fazer chamadas de APIs do Google Cloud.

Depois de se conectar, você verá 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 {{{project_0.project_id | "PROJECT_ID"}}}

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

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

gcloud auth list

4. Clique em Autorizar.

Saída:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} 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_0.project_id | "PROJECT_ID"}}} Observação: consulte a documentação completa da gcloud no Google Cloud no guia de visão geral da gcloud CLI.

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: verificar o cluster

Confirme o cluster pré-criado no console. Acesse Menu de navegação > Kubernetes Engine > Clusters e clique em "rbac-demo-cluster". Verifique se a autorização legada está desativada no novo cluster.

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 Observação: ignore o erro relacionado ao plug-in 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 Observação: ignore o erro relacionado ao plug-in 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 Observação: ignore o erro relacionado ao plug-in 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.

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.

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 24 de fevereiro de 2025

Laboratório testado em 24 de fevereiro de 2025

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.