Práticas Essenciais de RBAC para Proteger seus Clusters Kubernetes

O RBAC do Kubernetes decide quem pode fazer o quê no seu cluster. Uma única vinculação ampla pode permitir que uma conta comprometida leia segredos, modifique cargas de trabalho ou assuma o controle dos recursos do cluster.

Este guia explica os objetos principais do RBAC, mostra exemplos práticos e fornece hábitos de revisão que impedem que o acesso se desvie ao longo do tempo.

Entendendo os Fundamentos do RBAC no Kubernetes

O RBAC no Kubernetes é um mecanismo de autorização que regula o acesso aos recursos do Kubernetes com base nas funções de usuários individuais ou contas de serviço. É uma camada crucial de defesa, garantindo que apenas entidades autorizadas possam realizar ações específicas em recursos específicos.

Em sua essência, o RBAC depende de quatro tipos principais de objetos do Kubernetes:

• Role: Uma Role é um conjunto de permissões que se aplica dentro de um namespace específico. Ela define quais ações (verbos como get, list, create, update, delete) podem ser realizadas em quais recursos (como pods, deployments, services, secrets). Por exemplo, uma Role pode conceder permissão para ler pods e deployments no namespace development.
• ClusterRole: Semelhante a uma Role, mas uma ClusterRole define permissões que se aplicam em todo o cluster ou a recursos sem namespace (ex.: nodes, persistentvolumes). Uma ClusterRole também pode definir permissões para recursos com namespace em todos os namespaces. Por exemplo, uma ClusterRole pode permitir listar todos os nodes no cluster.
• RoleBinding: Uma RoleBinding concede as permissões definidas em uma Role (ou uma ClusterRole aplicada a um namespace) a um usuário, grupo ou conta de serviço. Ela sempre opera dentro de um namespace específico.
• ClusterRoleBinding: Uma ClusterRoleBinding concede as permissões definidas em uma ClusterRole a um usuário, grupo ou conta de serviço, aplicando essas permissões em todo o cluster.

Juntos, esses objetos permitem que os administradores construam um sistema de controle de acesso robusto e granular. Quando um usuário ou aplicativo (representado por uma conta de serviço) tenta realizar uma ação, o Kubernetes avalia as RoleBindings e ClusterRoleBindings existentes para determinar se a ação solicitada é permitida.

Implementando o Princípio do Menor Privilégio com RBAC

Um princípio central da segurança da informação é o princípio do menor privilégio. Um usuário, programa ou processo deve receber apenas as permissões necessárias para realizar seu trabalho. No Kubernetes, funções excessivamente permissivas são uma maneira comum de um pequeno comprometimento se tornar um problema em todo o cluster.

Definindo Permissões Granulares

Ao criar políticas de RBAC, pense nas ações e recursos precisos necessários:

• Verbos: Em vez de conceder * (todos os verbos), especifique exatamente quais ações são necessárias (get, list, watch, create, update, delete, patch, exec).
• Recursos: Seja específico sobre os recursos (pods, deployments, secrets, configmaps). Evite conceder acesso a * para recursos, a menos que seja absolutamente necessário e para funções administrativas bem justificadas.
• Nomes de Recursos: Para recursos muito sensíveis, como secrets, você pode restringir alguns verbos, como get, a resourceNames específicos dentro de um tipo de recurso. Não confie em resourceNames para acesso do tipo lista, pois list e watch não têm escopo para um único objeto nomeado da mesma forma.
• Grupos de API: A maioria dos recursos do Kubernetes pertence a um grupo de API (ex.: apps, rbac.authorization.k8s.io, "" para recursos principais). Especifique o grupo de API correto para restringir ainda mais o escopo.

Escopo de Namespace

Para a maioria dos aplicativos e equipes de desenvolvimento, as permissões devem ser confinadas a namespaces específicos. Essa segregação garante que um comprometimento no ambiente de um aplicativo ou equipe não leve automaticamente ao acesso em todo o cluster. Sempre prefira Role e RoleBinding em vez de ClusterRole e ClusterRoleBinding sempre que possível.

Implementação Prática de RBAC: Exemplos

Vamos percorrer alguns exemplos práticos de criação e vinculação de políticas de RBAC.

Exemplo 1: Acesso de Desenvolvedor a um Namespace Específico

Imagine que um desenvolvedor precisa gerenciar deployments e visualizar logs em seu namespace dedicado, dev-team-a. Ele não deve ter acesso a outros namespaces ou recursos em todo o cluster.

Primeiro, defina uma Role para o desenvolvedor no namespace dev-team-a:

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Para Deployments
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: [""] # Grupo de API principal para Pods e logs de Pods
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Aplique esta role:

kubectl apply -f dev-role.yaml

Em seguida, vincule esta Role a um usuário específico (ex.: [email protected] por meio de um provedor de identidade externo) ou a uma conta de serviço dentro do namespace dev-team-a:

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # O nome diferencia maiúsculas de minúsculas
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

Aplique esta vinculação:

kubectl apply -f dev-role-binding.yaml

Agora, [email protected] só pode gerenciar deployments e visualizar logs dentro do namespace dev-team-a. Ele não pode, por exemplo, criar secrets no kube-system ou listar todos os nodes.

Exemplo 2: Conta de Serviço de Aplicativo Acessando Secrets

Um aplicativo executado como ServiceAccount precisa ler um secret específico em seu próprio namespace.

Primeiro, certifique-se de que a conta de serviço existe ou crie uma:

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

Aplique esta conta de serviço:

kubectl apply -f app-sa.yaml

Em seguida, defina uma Role que permita a leitura de um secret específico:

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

Aplique esta role:

kubectl apply -f secret-reader-role.yaml

Finalmente, vincule esta Role à my-app-service-account:

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Aplique esta vinculação:

kubectl apply -f app-secret-reader-binding.yaml

O aplicativo agora só poderá ler o secret especificado e nada mais.

Exemplo 3: Função de Administrador do Cluster (com cautela)

Funções administrativas em todo o cluster devem ser concedidas com extrema moderação. Aqui está um exemplo de uma ClusterRole para listar todos os nodes, o que pode ser necessário para uma ferramenta de monitoramento.

# node-viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Aplique esta ClusterRole:

kubectl apply -f node-viewer-clusterrole.yaml

Em seguida, vincule-a a uma conta de serviço de monitoramento usando uma ClusterRoleBinding:

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Aplique esta vinculação:

kubectl apply -f monitoring-node-viewer-binding.yaml

Aviso: Seja extremamente cauteloso com ClusterRole e ClusterRoleBinding para usuários humanos. Limite seu uso a verdadeiros administradores do cluster e contas de serviço de infraestrutura específicas.

Práticas Essenciais de RBAC

Aderir a essas práticas recomendadas melhorará significativamente a postura de segurança do seu cluster:

1. Aplique o Princípio do Menor Privilégio (PoLP):

   • Conceda apenas as permissões mínimas necessárias. Revise cada permissão cuidadosamente.
   • Evite curingas (*) para resources e verbs sempre que possível. Se usados, justifique-os e tente defini-los com o escopo mais restrito possível.
   • Restrinja o acesso a recursos confidenciais (como secrets) usando resourceNames nas roles.

2. Use Namespaces para Segregação:

   • Organize seus aplicativos e equipes em namespaces distintos.
   • Use como padrão Role e RoleBinding para conceder permissões dentro desses namespaces.

3. Prefira Roles em vez de ClusterRoles:

   • Use ClusterRole e ClusterRoleBinding apenas quando as permissões precisarem genuinamente ser em todo o cluster (ex.: gerenciamento de nodes, definições de recursos personalizados, agentes de monitoramento específicos).
   • A maioria das permissões específicas de aplicativos deve ter namespace.

4. Audite e Revise Regularmente as Políticas de RBAC:

   • As políticas de RBAC podem se desviar ao longo do tempo. Revise periodicamente quem tem qual acesso.
   • Use ferramentas como kubectl auth can-i para testar permissões para usuários/contas de serviço específicos.

   # Verifique se '[email protected]' pode obter pods em 'dev-team-a'
   kubectl auth can-i get pods --namespace=dev-team-a [email protected]
   
   # Verifique se 'monitoring-sa' pode listar nodes (em todo o cluster)
   kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
   

   • Considere ferramentas de terceiros ou scripts personalizados para auditoria abrangente de RBAC.

5. Separe as Funções Administrativas:

   • Nunca dê privilégios cluster-admin a desenvolvedores ou contas de serviço de aplicativos.
   • Crie ClusterRoles administrativas específicas com apenas as permissões elevadas necessárias (ex.: cluster-reader, node-reader).

6. Aproveite as Contas de Serviço para Aplicativos:

   • Os aplicativos em execução dentro do cluster devem usar ServiceAccounts para interagir com a API do Kubernetes.
   • Cada aplicativo ou microsserviço deve idealmente ter sua própria ServiceAccount dedicada com permissões mínimas.
   • Defina automountServiceAccountToken: false para pods que não exigem acesso à API do Kubernetes, seja no pod ou na conta de serviço.

7. Integre com Gerenciamento de Identidade Externo:

   • Para usuários humanos, integre o Kubernetes a um provedor de identidade externo (ex.: OIDC, LDAP, Active Directory) para autenticação e gerenciamento de grupos.
   • Mapeie grupos externos para RoleBindings ou ClusterRoleBindings do Kubernetes para facilitar o gerenciamento.

8. Automatize o Gerenciamento de RBAC com GitOps:

   • Trate suas políticas de RBAC como código. Armazene-as em um repositório com controle de versão (Git).
   • Use os princípios do GitOps para gerenciar e implantar configurações de RBAC, garantindo consistência, rastreabilidade e reversões mais fáceis.

9. Monitore Eventos de RBAC por meio de Logs de Auditoria:

   • Habilite e configure o log de auditoria do Kubernetes para rastrear solicitações de API, incluindo quem realizou qual ação e quando.
   • Revise regularmente os logs de auditoria para detectar tentativas de acesso não autorizado ou atividades suspeitas relacionadas ao RBAC.

10. Atualize o Kubernetes Regularmente:

    • Mantenha-se atualizado com as versões do Kubernetes para se beneficiar de patches de segurança e melhorias, incluindo aprimoramentos de RBAC.

Armadilhas Comuns e Como Evitá-las

• Curingas Excessivamente Permissivos: Conceder apiGroups: ["*"], resources: ["*"] ou verbs: ["*"] é um grande risco de segurança. Seja sempre explícito.
• Uso Padrão de cluster-admin: Não use o grupo system:masters ou a ClusterRole cluster-admin para operações do dia a dia ou atribua-a a usuários não administradores. Qualquer um deles dá amplo controle sobre o cluster.
• Ignorar automountServiceAccountToken: Em muitos clusters, os pods recebem um token de conta de serviço, a menos que você desabilite a montagem automática. Se um pod não precisar interagir com a API do Kubernetes, defina automountServiceAccountToken: false na especificação do pod ou na definição da conta de serviço para reduzir sua superfície de ataque.
• Falta de Auditoria: Sem revisão regular, as políticas de RBAC podem se tornar desatualizadas ou excessivamente permissivas à medida que as necessidades do cluster evoluem. Implemente um processo de revisão.
• Confundir Role e ClusterRole: Entender mal o escopo pode levar à concessão de acesso em todo o cluster quando apenas o acesso com namespace era pretendido.

Conclusão

O RBAC funciona melhor quando você o mantém simples e específico: roles com namespace para equipes de aplicativos, permissões estreitas de contas de serviço, sem curingas sem revisão e verificações regulares de kubectl auth can-i. Trate cada vinculação como código de produção, porque em um cluster Kubernetes, efetivamente é.