0Pricing
Cyber Security Academy · Aula

RBAC e contas de serviço

Proteja o acesso ao cluster.

RBAC e contas de serviço é uma aula grátis de Cyber Security Academy no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Cyber Security Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Cyber Security Academy inclui 4 aulas no total.

O RBAC controla tudo

O Controle de acesso baseado em funções (RBAC) determina quais identidades podem executar quais ações em quais recursos de um cluster. Toda chamada à API é autorizada com base no RBAC. Configurações incorretas de RBAC são a principal causa de elevação de privilégios dentro do cluster.

  • Sujeitos: usuários, grupos e contas de serviço.
  • As funções vinculam verbos a recursos.
  • As vinculações conectam sujeitos a funções.

Funções versus ClusterRoles

Existem dois escopos.

  • Função + RoleBinding: permissões limitadas ao espaço de nomes.
  • ClusterRole + ClusterRoleBinding: permissões em todo o cluster.

Uma ClusterRoleBinding para cluster-admin representa controle total. Concedê-la a uma conta de serviço é um erro frequente e perigoso.

Tokens de contas de serviço

Cada pod é executado como uma conta de serviço e, por padrão, monta o token dessa conta. Esse token é uma credencial de portador que contém as permissões RBAC da conta. Se o pod for comprometido, o token também será.

Os clusters modernos emitem tokens projetados de curta duração e vinculados ao público-alvo, mas tokens secretos antigos de longa duração ainda permanecem.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Enumerando suas permissões

Depois de capturar um token, o primeiro passo é descobrir o que ele pode fazer. O Kubernetes fornece uma API de autoverificação.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Combinações perigosas de permissões

Determinados verbos são mecanismos de escalação mesmo sem cluster-admin.

  • create pods: agendar um pod privilegiado ou com hostPath para escapar.
  • create pods/exec: executar comandos em pods existentes.
  • get/list secrets: ler credenciais em todo o cluster.
  • create rolebindings/clusterrolebindings: vincular sua identidade à administração.
  • escalate / bind: conceder direitos que você não possui.
  • personificar: agir como outro sujeito com mais privilégios.

Escalação por criação de pods

Se uma conta de serviço puder criar pods, ela frequentemente poderá assumir o controle do nó. O invasor agenda um pod que monta o sistema de arquivos do host ou é executado com privilégios e, em seguida, lê as credenciais do nó ou escapa.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Escalação por vinculação

Se você puder criar vinculações de funções (de cluster), poderá vincular sua conta de serviço diretamente a cluster-admin. O Kubernetes protege isso com os verbos bind/escalate, mas funções com configuração incorreta às vezes permitem essa ação.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Abuso de personificação

O verbo impersonate permite que um sujeito aja como qualquer usuário, grupo ou conta de serviço. Uma identidade com permissões amplas de personificação efetivamente possui todas as permissões do cluster.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

Auditoria do RBAC

As equipes de defesa devem revisar continuamente o RBAC em busca de concessões arriscadas.

  • Encontre os sujeitos vinculados a cluster-admin.
  • Sinalize verbos e recursos curinga (*).
  • Detecte concessões de leitura de segredos e criação de pods em contas não administrativas.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Fortalecimento das contas de serviço

Aplique o princípio do menor privilégio às identidades.

  • Defina automountServiceAccountToken: false quando o pod não precisar de acesso à API.
  • Dê a cada carga de trabalho uma conta de serviço dedicada e com escopo mínimo.
  • Evite a conta de serviço default para cargas de trabalho reais.
  • Use tokens projetados de curta duração com públicos-alvo; faça sua rotação e vincule-os.
  • Nunca vincule cargas de trabalho a cluster-admin.

Testando o RBAC de forma ética

Ao avaliar o RBAC, prefira verificações não destrutivas (auth can-i, execução simulada) a criar de fato vinculações de cluster-admin em produção. Se precisar comprovar a escalação, limite-a a um espaço de nomes de teste e remova todas as vinculações ou pods que criar.

Relate as funções e vinculações exatas que permitiram a escalação, para que possam ser restringidas.

Verificação rápida

Confirme sua compreensão do RBAC.

Recapitulação

Você aprendeu como o RBAC e as contas de serviço governam o acesso ao cluster e o colocam em risco.

  • O RBAC vincula sujeitos a verbos em recursos; cluster-admin representa controle total.
  • Os pods montam tokens SA; auth can-i revela seu alcance.
  • Criação de pods, vinculação, leitura de segredos e personificação são mecanismos de escalação.
  • Contas com o menor privilégio e montagem automática desativada fortalecem o cluster.

A seguir: segurança de pods e políticas de rede.

Perguntas Frequentes

A aula “RBAC e contas de serviço” é grátis?

Sim — o texto completo de “RBAC e contas de serviço” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Cyber Security Academy, atualize para CoddyKit PRO. O curso de Cyber Security Academy inclui 4 aulas no total.

O que vou aprender em “RBAC e contas de serviço”?

Proteja o acesso ao cluster. Você pratica Cyber Security Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Cyber Security Academy?

Nenhuma experiência prévia é necessária. Cyber Security Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “RBAC e contas de serviço”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Cyber Security Academy?

Sim. Cada aula de Cyber Security Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Modelo de ameaças do Kubernetes
  2. RBAC e contas de serviço
  3. Segurança de pods e políticas de rede
  4. Protegendo a cadeia de suprimentos e os segredos
← Voltar para Cyber Security Academy