Visão geral
Neste laboratório, você criará namespaces em um cluster do GKE e depois usará o controle de acesso baseado em papéis para que um usuário não administrador trabalhe com pods em um namespace específico.
Objetivos
Neste laboratório, você aprenderá a fazer o seguinte:
- Criar namespaces para os usuários controlarem o acesso aos recursos de cluster
- Criar papéis e RoleBindings para controlar o acesso dentro de um namespace
.
Observação: para este laboratório, há dois nomes de usuário disponíveis na caixa de diálogo "Detalhes da conexão". Essas contas serão indicadas como Nome de usuário 1 e Nome de usuário 2 neste laboratório.
Tarefa 1: criar namespaces para os usuários acessarem os recursos de um cluster
Faça login no console do Google Cloud como o primeiro usuário
- Como de costume, faça login no Console do Google Cloud em uma janela anônima com o Nome de usuário 1 fornecido no Qwiklabs. A senha é a mesma para os dois nomes de usuário.
- Na barra de título do console do Google Cloud, clique em Ativar o Cloud Shell (
).
- Quando solicitado, clique em Continuar.
Você não precisa esperar o Cloud Shell iniciar para fazer a próxima tarefa.
Observação: o Nome de usuário 2 tem acesso ao projeto, mas apenas com o papel de Leitor, o que torna todos os recursos do projeto acessíveis, mas no modo somente leitura.
Faça login no Console do Google Cloud como o segundo usuário
- Abra outra guia na janela anônima.
- Acesse console.cloud.google.com.
- Clique no ícone do usuário no canto superior direito da tela e, em seguida, clique em Adicionar conta.
- Faça login no console do Google Cloud com o Nome de usuário 2 fornecido. Lembre-se de que a senha é a mesma para os dois nomes de usuário.
- Na barra de título do console do Google Cloud, clique em Ativar o Cloud Shell (
).
- Quando solicitado, clique em Continuar.
Você não precisa esperar o Cloud Shell iniciar para fazer a próxima tarefa.
Conecte-se ao cluster do GKE do laboratório
- Volte à guia Nome de usuário 1 do console do Google Cloud.
Observação: verifique se você está na guia Nome de usuário 1 do console do Google Cloud.
- No Cloud Shell, digite o comando a seguir para definir a variável de ambiente da zona e o nome do cluster:
export my_zone={{{ project_0.default_zone | ZONE }}}
export my_cluster=standard-cluster-1
- Configure o preenchimento automático da ferramenta de linha de comando kubectl:
source <(kubectl completion bash)
- Configure o acesso ao cluster para o kubectl:
gcloud container clusters get-credentials $my_cluster --zone $my_zone
- No Cloud Shell, digite o seguinte comando para clonar o repositório no Cloud Shell deste laboratório:
git clone https://github.com/GoogleCloudPlatform/training-data-analyst
- Crie um link flexível como atalho para o diretório de trabalho:
ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s
- Mude para o diretório que contém os arquivos de exemplo deste laboratório:
cd ~/ak8s/RBAC/
Crie um namespace
Um arquivo de manifesto chamado my-namespace.yaml
já foi gerado e criará o novo namespace production
.
apiVersion: v1
kind: Namespace
metadata:
name: production
- Liste os namespaces atuais no cluster usando o seguinte comando:
kubectl get namespaces
Saída:
NAME STATUS AGE
default Active 17m
kube-node-lease Active 17m
kube-public Active 17m
kube-system Active 17m
- No Cloud Shell, execute o seguinte comando para criar o novo namespace:
kubectl create -f ./my-namespace.yaml
- Verifique se o namespace aparece com o seguinte comando:
kubectl get namespaces
Saída:
NAME STATUS AGE
default Active 6m
kube-node-lease Active 6m
kube-public Active 6m
kube-system Active 6m
production Active 4s
O novo namespace aparece na parte inferior da lista.
- É possível ver os detalhes de um namespace executando:
kubectl describe namespaces production
Saída:
Name: production
Labels:
Annotations:
Status: Active
Resource Quotas
Name: gke-resource-quotas
Resource Used Hard
-------- --- ---
count/ingresses.extensions 0 100
count/jobs.batch 0 5k
pods 0 1500
services 0 500
No LimitRange resource.
Crie um recurso em um namespace
Se você não especificar o namespace de um pod, ele usará o namespace "padrão". Nesta tarefa, você especificará o local do namespace recém-criado ao criar um novo pod. Um arquivo de manifesto simples chamado my-pod.yaml
que cria um pod com um contêiner nginx foi gerado.
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
- No Cloud Shell, execute o seguinte comando para criar o recurso no namespace chamado
production
:
kubectl apply -f ./my-pod.yaml --namespace=production
Também é possível especificar o namespace no arquivo yaml. Isso exige o campo namespace: production
na seção "metadata:".
Por exemplo:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
name: nginx
namespace: production
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
- Use o seguinte comando para ver o pod:
kubectl get pods
Saída:
No resources found in default namespace.
Você não verá o pod porque o kubectl verificou o namespace padrão em vez do novo namespace.
- Execute o comando novamente, mas, desta vez, especifique o novo namespace:
kubectl get pods --namespace=production
Saída:
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 20s
Agora você deve ver o pod recém-criado.
Clique em "Verificar meu progresso" para conferir o objetivo.
Criar o namespace e o pod
Tarefa 2: sobre papéis e RoleBindings
Nesta tarefa, você criará um papel personalizado de amostra e, em seguida, criará um RoleBinding que concederá ao Nome de usuário 2 o papel de editor no namespace "production".
O papel é definido no arquivo pod-reader-role.yaml
fornecido. Esse manifesto define um papel chamado pod-reader
, que concede as permissões "create", "get", "list" e "watch" para os objetos pod no namespace production
. Esse papel não pode excluir pods.
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["create", "get", "list", "watch"]
Crie um papel personalizado
Antes de criar um papel, sua conta deve ter permissões para o papel que está sendo atribuído. Para administradores de cluster, isso pode ser feito facilmente criando o RoleBinding a seguir para conceder à sua própria conta de usuário o papel cluster-admin.
- Para conceder privilégios de administrador de cluster à conta Nome de usuário 1, execute o seguinte comando, substituindo [USERNAME_1_EMAIL] pelo endereço de e-mail da conta
Nome de usuário 1
:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user [USERNAME_1_EMAIL]
Exemplo de saída:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user gcpstaging28307_student@qwiklabs.net
- No Cloud Shell, execute o seguinte comando para criar o papel:
kubectl apply -f pod-reader-role.yaml
- Para listar os papéis e verificar a criação, execute o seguinte comando:
kubectl get roles --namespace production
Saída:
NAME AGE
pod-reader 3m
Crie um RoleBinding
O papel é usado para atribuir privilégios, mas, por si só, não faz nada. O papel precisa estar vinculado a um usuário e a um objeto, o que é feito no RoleBinding.
O arquivo de manifesto username2-editor-binding.yaml
cria um RoleBinding chamado username2-editor
para o segundo usuário deste laboratório ao papel pod-reader
criado anteriormente. O papel pode criar e ver pods, mas não excluí-los.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: username2-editor
namespace: production
subjects:
- kind: User
name: [USERNAME_2_EMAIL]
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Este arquivo contém um marcador, [USERNAME_2_EMAIL]
, que precisa ser substituído pelo endereço de e-mail do Nome de usuário 2 antes de ser usado.
- No Cloud Shell, crie uma variável de ambiente que inclua o endereço de e-mail completo do Nome de usuário 2:
export USER2=[USERNAME_2_EMAIL]
Exemplo de saída:
export USER2=gcpstaginguser68_student@qwiklabs.net
- No Cloud Shell, use
sed
para substituir o marcador de posição no arquivo pelo valor da variável de ambiente:
sed -i "s/\[USERNAME_2_EMAIL\]/${USER2}/" username2-editor-binding.yaml
- No Cloud Shell, execute o seguinte comando para confirmar que a alteração correta foi feita:
cat username2-editor-binding.yaml
A seção "subjects" fica parecida com o exemplo abaixo.
Exemplo de saída:
subjects:
- kind: User
name: gcpstaginguser68_student@qwiklabs.net
apiGroup: rbac.authorization.k8s.io
Você aplicará este RoleBinding mais tarde.
Teste o acesso
Agora você testará se o Nome de usuário 2 pode criar um pod no namespace "production" usando o Nome de usuário 2 para criar um pod com o arquivo de manifesto production-pod.yaml
. Esse manifesto implanta um pod simples com um único contêiner nginx.
apiVersion: v1
kind: Pod
metadata:
name: production-pod
labels:
name: production-pod
namespace: production
spec:
containers:
- name: production-pod
image: nginx
ports:
- containerPort: 8080
Como essa é uma conta de usuário separada, você precisa preparar novamente o ambiente do Cloud Shell para ter acesso ao cluster e aos arquivos de amostra do repositório do laboratório.
- Volte para a guia com o Nome de usuário 2 do console do Google Cloud.
Observação: verifique se você está na guia Nome de usuário 2 do console do Google Cloud.
- No Cloud Shell do Nome de usuário 2, digite o comando abaixo para definir a variável de ambiente da zona e o nome do cluster:
export my_zone={{{ project_0.default_zone | ZONE }}}
export my_cluster=standard-cluster-1
- Configure o preenchimento automático da ferramenta de linha de comando kubectl:
source <(kubectl completion bash)
- Configure o acesso ao cluster para o kubectl:
gcloud container clusters get-credentials $my_cluster --zone $my_zone
- No Cloud Shell, digite o comando a seguir para clonar o repositório no Cloud Shell deste laboratório:
git clone https://github.com/GoogleCloudPlatform/training-data-analyst
- Crie um link flexível como atalho para o diretório de trabalho:
ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s
- Mude para o diretório que contém os arquivos de exemplo deste laboratório:
cd ~/ak8s/RBAC/
- Verifique se o Nome de usuário 2 pode ver o namespace "production" com o comando abaixo:
kubectl get namespaces
Saída:
NAME STATUS AGE
default Active 29m
kube-node-lease Active 29m
kube-public Active 29m
kube-system Active 29m
production Active 23m
Como o namespace "production" aparece na parte inferior da lista, podemos continuar.
- No Cloud Shell, execute o seguinte comando para criar o recurso no namespace "production":
kubectl apply -f ./production-pod.yaml
Isso gera um erro, indicando que o Nome de usuário 2 não tem permissão para criar pods. O Nome de usuário 2 só tem as permissões de visualizador com que ele iniciou o laboratório, já que você ainda não vinculou outro papel a essa conta. Você fará isso agora.
- Volte à guia Nome de usuário 1 do console do Google Cloud.
Observação: verifique se você está na guia Nome de usuário 1 do console do Google Cloud.
- No Cloud Shell do Nome de usuário 1, execute o comando abaixo para criar o RoleBinding que concede ao Nome de usuário 2 o papel de
pod-reader
, que inclui a permissão para criar pods no namespace production
:
kubectl apply -f username2-editor-binding.yaml
- No Cloud Shell do Nome de usuário 1, execute o comando abaixo para procurar o novo RoleBinding:
kubectl get rolebinding
Saída:
No resources found in default namespace.
O RoleBinding não aparece porque o kubectl está mostrando o namespace padrão.
- No Cloud Shell do Nome de usuário 1, execute o comando abaixo com o namespace "production" especificado:
kubectl get rolebinding --namespace production
Saída:
NAME AGE
username2-editor 23s
- Volte para a guia com o Nome de usuário 2 do console do Google Cloud.
Observação: verifique se você está na guia Nome de usuário 2 do console do Google Cloud.
- No Cloud Shell do Nome de usuário 2, execute o comando abaixo para criar o recurso no namespace "production":
kubectl apply -f ./production-pod.yaml
Isso deve funcionar, já que o Nome de usuário 2 agora tem a permissão para criar pods no namespace production.
- Verifique se o pod foi implantado corretamente no namespace "production" usando o comando abaixo:
kubectl get pods --namespace production
Saída:
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 16m
production-pod 1/1 Running 0 20s
Você verá o pod que acabou de criar.
- Verifique se somente as permissões específicas do RBAC concedidas pelo papel "pod-reader" estão em vigor para o Nome de usuário 2. Para isso, tente excluir o "production-pod":
kubectl delete pod production-pod --namespace production
Isso gera um erro, já que o Nome de usuário 2 não tem a permissão para excluir pods.
Clique em "Verificar meu progresso" para conferir o objetivo.
Papéis e RoleBindings
Finalize o laboratório
Clique em Terminar o laboratório após a conclusão. O Google Cloud Ensina remove os recursos usados e limpa a conta por você.
Você vai poder avaliar sua experiência no laboratório. Basta selecionar o número de estrelas, digitar um comentário e clicar em Enviar.
O número de estrelas indica o seguinte:
- 1 estrela = muito insatisfeito
- 2 estrelas = insatisfeito
- 3 estrelas = neutro
- 4 estrelas = satisfeito
- 5 estrelas = muito satisfeito
Feche a caixa de diálogo se não quiser enviar feedback.
Para enviar seu feedback, fazer sugestões ou correções, use a guia Suporte.
Copyright 2020 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.