Neste artigo, vou apresentar minha perspectiva sobre como proteger um cluster de Azure Kubernetes com o princípio de privilégio mínimo como prioridade. Explicarei as funções internas disponíveis no Azure Kubernetes, o papel dos grupos do Microsoft Entra (anteriormente conhecido como Azure Active Directory) e como utilizar o Kubernetes RBAC para gerenciar o acesso às workloads.
Autenticação e Autorização
Configure o cluster para integrá-lo ao Microsoft Entra e aproveite para gerenciar usuários e grupos a partir de um gerenciamento central de identidades.
Grupos do Microsoft Entra e Funções do Azure Kubernetes
Crie um ou mais Grupos do Entra para separar os administradores dos não administradores. O número e a estrutura dos grupos dependerão da sua organização. Vamos supor que criamos dois grupos:
admin
desenvolvedores
Agora, precisamos atribuir funções a esses grupos. Existem duas Roles do Azure Kubernetes que utilizo:
Função | Descrição |
Azure Kubernetes Service Cluster User Role | Essa role permite que o usuário faça login no cluster; no entanto, se não existirem (Cluster)RoleBindings, o usuário não poderá executar nenhum comando kubectl. |
Azure Kubernetes Service RBAC Cluster Admin | Permite ao usuário controle total sobre todos os recursos do cluster. |
O grupo "admin" terá a função de "RBAC Cluster Admin" e o grupo "desenvolvedores" terá a função de "User Role". Com essa atribuição de funções, alcançamos o princípio de privilégio mínimo, pois negamos todos os comandos do kubectl para o grupo "desenvolvedores". A partir de agora, eu, como administrador, utilizarei o Kubernetes RBAC para controlar o que os desenvolvedores podem fazer. O RBAC que você implementará variará de acordo com seus casos de uso.
Kubernetes RBAC
Agora, por exemplo, vou conceder permissões para que o grupo "desenvolvedores" possa ler Pods no namespace de desenvolvimento (dev) utilizando a seguinte Role:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]Obtenha o ID do recurso para o grupo "developers" usando o comando az ad group show. Esse grupo será definido como o sujeito de um RoleBinding no próximo passo.
az ad group show --group developers --query id -o tsvCrie uma RoleBinding para o grupo "desenvolvedores" utilizar a Role criada anteriormente para ler Pods.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-user-access
namespace: dev
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-reader
subjects:
- kind: Group
namespace: dev
name: <groupObjectId> # output of the az ad group showAgora, os membros do grupo "desenvolvedores" poderão ler Pods no namespace dev.
Resumo
Podemos configurar grupos de não administradores com a função "Azure Kubernetes Service Cluster User Role" para impor efetivamente uma política de "negação total". Isso significa que os membros desses grupos não terão permissão para executar nenhuma ação no cluster Kubernetes. O administrador pode, então, conceder seletivamente apenas as permissões necessárias para esses grupos.
Essa abordagem permite que o administrador proteja segredos do Kubernetes contra acesso não autorizado, impeça a exclusão de Pods do sistema e controle o acesso a namespaces específicos, o que é particularmente útil em ambientes multi-inquilino.
Na minha visão, é melhor começar com um ambiente fechado e, em seguida, gradualmente abrir o acesso conforme necessário, em vez de começar com acesso aberto e depois tentar restringi-lo.
Comments