Gerenciar Acesso

Em clusters Kubernetes, o controle de acesso é gerenciado pelo próprio Kubernetes. O arquivo kubeconfig baixado pelo painel de controle contém credenciais administrativas e é adequado para a configuração inicial do cluster.

Se vários membros do time precisam acessar o mesmo cluster, compartilhar um único kubeconfig de administrador não é uma boa prática. Se esse arquivo vazar ou ficar com um ex-funcionário, não há como revogar o acesso apenas para aquela pessoa. A abordagem mais segura é criar uma conta separada para cada usuário e conceder as permissões necessárias via RBAC.

Este guia mostra como configurar acesso individual usando um ServiceAccount, um RoleBinding ou ClusterRoleBinding, e um kubeconfig dedicado com token.

Pré-requisitos

Você vai precisar de um cluster Kubernetes em execução, do kubeconfig de administrador baixado pelo painel de controle e do kubectl instalado.

Para baixar o kubeconfig, acesse a página de gerenciamento do cluster Kubernetes no painel de controle. Na aba Painel de Controle, clique no link "baixe o arquivo de configuração". O arquivo baixado terá o nome twc-cluster_name.yaml.

Verifique a conectividade com o cluster:

kubectl --kubeconfig=twc-cluster_name.yaml get nodes

Se o comando retornar uma lista de nós, você está pronto para criar contas de usuário.

Criar um namespace para contas de usuário

É conveniente gerenciar todas as contas de usuário em um namespace dedicado, por exemplo kube-users:

kubectl create namespace kube-users

Crie um ServiceAccount para o usuário newuser:

kubectl create serviceaccount newuser -n kube-users

Esse nome de conta será usado na atribuição de permissões e na geração de tokens.

Conceder permissões

As permissões no Kubernetes são gerenciadas via RBAC com dois tipos de recursos:

• RoleBinding concede permissões dentro de um único namespace
• ClusterRoleBinding concede permissões em todo o cluster

Siga sempre o princípio do menor privilégio. Se um usuário precisa de acesso a apenas um namespace, use RoleBinding em vez de ClusterRoleBinding.

Acesso a um único namespace

Para restringir um usuário a um único namespace, crie um RoleBinding nesse namespace. O exemplo abaixo concede ao newuser permissões de edição no namespace app-prod:

kubectl create namespace app-prod
 
kubectl create rolebinding newuser-app-prod-edit \
  --namespace app-prod \
  --clusterrole edit \
  --serviceaccount kube-users:newuser

Você pode substituir edit por qualquer outra role integrada:

Essas são as ClusterRoles padrão do Kubernetes. Se nenhuma delas atender às suas necessidades, você pode criar ClusterRoles personalizadas com regras específicas.

Para verificar se as permissões foram aplicadas corretamente:

kubectl auth can-i create deployments \
  --as system:serviceaccount:kube-users:newuser \
  -n app-prod

Se o acesso estiver configurado corretamente, o comando retorna:

yes

Acesso a todo o cluster

Se um usuário precisar de acesso administrativo completo ao cluster, crie um ClusterRoleBinding:

kubectl create clusterrolebinding newuser-cluster-admin \
  --clusterrole cluster-admin \
  --serviceaccount kube-users:newuser

Atribua a role cluster-admin somente a administradores do cluster. Para times de desenvolvimento, o acesso restrito a namespaces é o padrão mais seguro.

Criar um token

Os usuários precisam de um token para se conectar via kubectl. O Kubernetes suporta dois tipos: tokens de curta duração e tokens de longa duração armazenados em um Secret.

Token de curta duração

Crie um token de curta duração com kubectl create token. O exemplo abaixo gera um token válido por 24 horas:

TOKEN=$(kubectl create token newuser -n kube-users --duration=24h)

Visualize o valor do token:

echo "${TOKEN}"

O token deixará de funcionar automaticamente após o prazo de validade.

Tokens de curta duração não criam nenhum objeto no cluster, portanto não é possível revogar um token específico antes de ele expirar. Se precisar cortar o acesso imediatamente, delete as permissões do usuário ou o próprio ServiceAccount.

Token de longa duração

Se você precisar de um token sem prazo de validade, crie um Secret do tipo kubernetes.io/service-account-token. Esse token pode ser revogado a qualquer momento deletando o Secret.

Crie um arquivo chamado newuser-token-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: newuser-token
  namespace: kube-users
  annotations:
    kubernetes.io/service-account.name: newuser
type: kubernetes.io/service-account-token

Aplique o manifesto:

kubectl apply -f newuser-token-secret.yaml

Recupere o valor do token:

TOKEN=$(kubectl get secret newuser-token \
  -n kube-users \
  -o jsonpath='{.data.token}' | base64 -d)

Use tokens de longa duração somente quando tokens de curta duração não forem viáveis. Trate-os como credenciais sensíveis e armazene-os com segurança.

Criar um kubeconfig para o usuário

Crie um arquivo kubeconfig separado com os dados de conexão ao cluster e o token do newuser.

Primeiro, recupere os parâmetros do cluster a partir do kubeconfig de administrador:

CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
CLUSTER_SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
kubectl config view --raw --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt

Crie o novo arquivo de configuração:

kubectl config --kubeconfig=newuser.kubeconfig set-cluster "${CLUSTER_NAME}" \
  --server="${CLUSTER_SERVER}" \
  --certificate-authority=ca.crt \
  --embed-certs=true
 
kubectl config --kubeconfig=newuser.kubeconfig set-credentials newuser \
  --token="${TOKEN}"
 
kubectl config --kubeconfig=newuser.kubeconfig set-context newuser-context \
  --cluster="${CLUSTER_NAME}" \
  --user=newuser
 
kubectl config --kubeconfig=newuser.kubeconfig use-context newuser-context

Se o usuário precisar trabalhar em um namespace específico por padrão, adicione-o ao contexto:

kubectl config --kubeconfig=newuser.kubeconfig set-context newuser-context \
  --cluster="${CLUSTER_NAME}" \
  --user=newuser \
  --namespace=app-prod

Com o arquivo pronto, você pode entregar o newuser.kubeconfig ao usuário.

Exemplo de kubeconfig

Abaixo está um exemplo de kubeconfig de usuário com autenticação por token. Os valores de certificate-authority-data, server e token serão diferentes no seu cluster.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <CA_DATA>
    server: https://<API_SERVER>:6443
  name: twc-example-cluster
contexts:
- context:
    cluster: twc-example-cluster
    namespace: app-prod
    user: newuser
  name: newuser-context
current-context: newuser-context
kind: Config
preferences: {}
users:
- name: newuser
  user:
    token: <TOKEN>

O arquivo final não deve conter o usuário administrador, o certificado de cliente ou a chave privada do kubeconfig original. Antes de compartilhar o arquivo, verifique se a seção users contém apenas a conta do usuário com o token.

Verificar o acesso

Teste o novo kubeconfig:

kubectl --kubeconfig=newuser.kubeconfig get pods -n app-prod

Se o usuário tiver acesso apenas ao namespace app-prod, requisições a outros namespaces serão negadas:

kubectl --kubeconfig=newuser.kubeconfig get pods -n default

O Kubernetes retornará um erro de acesso:

Error from server (Forbidden): pods is forbidden

Para verificar se uma ação específica é permitida, use kubectl auth can-i:

kubectl --kubeconfig=newuser.kubeconfig auth can-i update deployments -n app-prod

Revogar acesso

A forma de revogar o acesso depende do que você precisa desativar.

Remover permissões de namespace

Para impedir que um usuário realize ações em um namespace, delete o RoleBinding correspondente:

kubectl delete rolebinding newuser-app-prod-edit -n app-prod

Se o usuário tiver acesso em nível de cluster, delete o ClusterRoleBinding:

kubectl delete clusterrolebinding newuser-cluster-admin

Após a exclusão do binding, o token pode continuar tecnicamente válido, mas o usuário não terá mais permissão para realizar nenhuma ação.

Revogar um token de longa duração

Se o token foi criado via Secret, delete esse Secret:

kubectl delete secret newuser-token -n kube-users

Após a exclusão do Secret, o token deixará de autenticar.

Deletar a conta completamente

Para remover um usuário por completo, delete o ServiceAccount:

kubectl delete serviceaccount newuser -n kube-users

Quando um ServiceAccount é deletado, todos os tokens emitidos para ele deixam de funcionar. A revogação pode não ser imediata, pois o Kubernetes pode armazenar em cache os resultados da validação de tokens por um curto período.

Após deletar a conta, remova também os RoleBindings e ClusterRoleBindings associados, se não forem mais necessários.