O problema não é apenas autenticação
Quando trabalhamos com AKS, é comum associar Microsoft Entra ID diretamente ao controle de acesso do cluster. Entretanto, autenticação e autorização são responsabilidades diferentes.
O Microsoft Entra ID pode ser utilizado para autenticar usuários, grupos e identidades que acessam o Kubernetes API. Depois que a identidade é validada, o cluster ainda precisa determinar quais ações aquela identidade poderá executar.
É justamente nesse ponto que entram os modelos de autorização: Azure RBAC para Kubernetes e Kubernetes RBAC.
Autorização responde: o que essa identidade pode fazer dentro do cluster?
O que é Kubernetes RBAC?
Kubernetes RBAC é o modelo de autorização nativo do Kubernetes. As permissões são declaradas através de recursos armazenados dentro do próprio cluster.
Os principais objetos são:
Role: define permissões dentro de um namespace.ClusterRole: define permissões em nível de cluster.RoleBinding: associa uma Role ou ClusterRole a uma identidade dentro de um namespace.ClusterRoleBinding: associa uma ClusterRole em nível de cluster.
Nesse modelo, o Kubernetes API Server é responsável por avaliar diretamente se uma determinada requisição deve ser autorizada.
O que é Azure RBAC para Kubernetes?
No modelo Azure RBAC para Kubernetes, as decisões de autorização podem ser administradas através do Azure utilizando atribuições de função associadas às identidades do Microsoft Entra ID.
Isso permite utilizar a mesma estrutura de identidade e governança já existente no Azure para controlar o acesso aos recursos do Kubernetes.
O AKS disponibiliza funções internas específicas para esse cenário, entre elas:
- Azure Kubernetes Service RBAC Reader
- Azure Kubernetes Service RBAC Writer
- Azure Kubernetes Service RBAC Admin
- Azure Kubernetes Service RBAC Cluster Admin
Azure RBAC x Kubernetes RBAC
| Característica | Azure RBAC | Kubernetes RBAC |
|---|---|---|
| Gerenciamento | Azure / Microsoft Entra ID | Dentro do cluster Kubernetes |
| Permissões | Azure Role Assignments | Roles e ClusterRoles |
| Associação | Usuários, grupos e identidades Entra ID | RoleBindings e ClusterRoleBindings |
| Governança corporativa | Centralizada | Administrada por cluster |
| Granularidade Kubernetes | Alta para recursos suportados | Muito alta e nativa |
| Escala com múltiplos clusters | Facilita centralização | Exige gestão das configurações por cluster |
Qual modelo utilizar?
Em ambientes corporativos Azure, Azure RBAC tende a ser uma excelente escolha quando existe a necessidade de centralizar identidade, governança e administração de permissões.
Ele permite que grupos do Microsoft Entra ID sejam utilizados diretamente dentro da estratégia de acesso ao AKS, reduzindo a necessidade de manter controles completamente separados entre Azure e Kubernetes.
Kubernetes RBAC continua sendo extremamente importante quando precisamos trabalhar com permissões específicas do ecossistema Kubernetes ou implementar controles mais próximos das aplicações, namespaces e workloads.
Faz bastante sentido quando:
- o ambiente possui forte governança através do Azure;
- Microsoft Entra ID é a identidade corporativa central;
- existem vários clusters ou equipes;
- o gerenciamento centralizado de acesso é prioridade.
Faz bastante sentido quando:
- são necessárias regras muito específicas dentro do cluster;
- aplicações utilizam Service Accounts;
- o controle precisa acompanhar manifests Kubernetes;
- as permissões fazem parte do ciclo de vida da aplicação.
Os dois modelos podem coexistir?
Sim. Uma arquitetura de acesso não precisa obrigatoriamente tratar Azure RBAC e Kubernetes RBAC como opções mutuamente exclusivas.
Em determinados cenários, Azure RBAC pode ser utilizado como camada central de governança para usuários e equipes, enquanto Kubernetes RBAC continua sendo utilizado dentro do cluster para permissões específicas de workloads, Service Accounts e componentes internos.
Um ponto importante: RBAC não é acesso ao kubeconfig
Outro ponto que costuma gerar confusão é a diferença entre obter credenciais do cluster e possuir autorização para executar ações dentro dele.
Conseguir recuperar as credenciais necessárias para acessar um cluster AKS não significa automaticamente possuir permissão sobre todos os recursos Kubernetes.
O acesso ao cluster e a autorização dentro do Kubernetes devem ser analisados como camadas diferentes da arquitetura de segurança.
Forbidden ao tentar listar Secrets, criar Pods
ou consultar outros recursos.
Minha recomendação arquitetural
Para ambientes corporativos executando AKS no Azure, eu considero importante começar pelo modelo de identidade da organização antes de definir as permissões Kubernetes.
Quando Microsoft Entra ID já é utilizado como identidade corporativa, Azure RBAC oferece uma camada consistente para governança e gerenciamento centralizado de usuários e grupos.
Kubernetes RBAC permanece fundamental para controles específicos do Kubernetes e para autorizações relacionadas diretamente aos workloads.
Mais importante do que escolher apenas uma tecnologia é estabelecer claramente onde cada tipo de permissão será administrado e evitar acessos excessivos, especialmente funções equivalentes a Cluster Admin.
Conclusão
Azure RBAC e Kubernetes RBAC resolvem problemas semelhantes, mas operam em modelos de gerenciamento diferentes.
Azure RBAC aproxima o controle de acesso ao modelo de governança do Azure e do Microsoft Entra ID. Kubernetes RBAC mantém a autorização dentro do modelo nativo do Kubernetes.
Em arquiteturas AKS maduras, compreender essa separação ajuda a implementar acesso baseado em menor privilégio, melhorar a governança e reduzir a complexidade operacional.