Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve como o Azure Kubernetes Service (AKS) decide o que um chamador autenticado pode fazer contra a API Kubernetes. Abrange os dois modelos de autorização que o AKS suporta e o controlo personalizado de recursos detalhado com as condições Azure ABAC.
Para saber como o AKS autentica os chamadores em primeiro lugar, veja conceitos de autenticação em cluster.
Para uma orientação em todos os quatro cenários de identidade do AKS, consulte Opções de Acesso e identidade para o AKS.
Autorizar a API do Kubernetes
Após a autenticação do chamador, o AKS avalia se está autorizado a realizar a ação solicitada. O AKS suporta dois modelos de autorização para a API Kubernetes:
- Kubernetes controlo de acesso baseado em funções (RBAC). O modelo nativo de autorização do Kubernetes. As permissões são definidas como
RoleeClusterRoleobjetos e concedidas a sujeitos através deRoleBindingeClusterRoleBindingobjetos armazenados em cada cluster. - Autorização do Microsoft Entra ID. Um webhook de autorização AKS que delega decisões de autorização ao Microsoft Entra ID. As permissões são concedidas como atribuições de funções Azure às identidades do Entra ID, e podem ser opcionalmente refinadas com as condições do Azure ABAC.
Podes usar ambos os modelos no mesmo cluster. Recomendamos a autorização Microsoft Entra ID como padrão e reservamos o Kubernetes RBAC para permissões intra-cluster detalhadas. O resto desta secção explica porquê e quando usar cada um.
RBAC do Kubernetes
O Kubernetes RBAC é o modelo de autorização Kubernetes originário. Authoras objetos como Role ou ClusterRole que concedem verbos (como get, list, create) em recursos (como pods, deployments) e ligas-os a sujeitos (utilizadores, grupos ou contas de serviço) utilizando objetos RoleBinding ou ClusterRoleBinding. O autorizador RBAC incorporado do servidor API Kubernetes avalia estas ligações em cada pedido.
Usa o RBAC do Kubernetes quando quiseres:
- Controlo de acesso detalhado, intra-cluster e por namespace, criado como Kubernetes, manifesta-se juntamente com as cargas de trabalho que protegem.
- Autorização gerida pelo GitOps que reside na mesma fonte de referência da configuração da sua aplicação.
- Permissões para contas de serviço dentro do cluster que as cargas de trabalho utilizam para aceder à API do Kubernetes.
As permissões RBAC do Kubernetes são atribuídas a um único cluster. Para aplicar a mesma política a muitos clusters, deve aplicar os manifestos a cada cluster (tipicamente através do GitOps). Use utilizadores e grupos do Microsoft Entra como sujeitos em objetos do Kubernetes RoleBinding e ClusterRoleBinding para que as identidades humanas continuem a vir do seu diretório central.
Para informações sobre o modelo RBAC do Kubernetes, consulte a documentação oficial do RBAC do Kubernetes. Para a configuração no AKS, veja o artigo Usar o RBAC do Kubernetes com a integração do Microsoft Entra.
Autorização do Microsoft Entra ID para API Kubernetes
Com a autorização do Entra ID, o AKS implementa um webhook de autorização que delega as decisões de autorização da API Kubernetes ao Microsoft Entra ID. Quando um pedido chega ao servidor API, o webhook chama a API Entra ID checkaccess para avaliar as atribuições de funções Azure do utilizador (e quaisquer condições ABAC anexadas) e retorna uma decisão de permitir ou recusar.
Diagrama que mostra o fluxo de autorização do webhook Entra ID para a API do Kubernetes.
A autorização Entra ID oferece-lhe os seguintes benefícios em comparação à gestão de manifestos RBAC do Kubernetes em cada cluster:
- Plano de identidade única. Os mesmos utilizadores, grupos e entidades de serviço do Microsoft Entra que regulam o acesso aos seus recursos Azure também regulam o acesso à sua API Kubernetes. Não existe um diretório de utilizador separado para provisionar ou alternar.
- Atribua uma vez, governe vários clusters. As atribuições de funções no Azure podem ser feitas no âmbito de subscrição, grupo de gestão ou grupo de recursos. Uma única atribuição de função no âmbito de um grupo de recursos concede acesso a todos os clusters AKS atuais e futuros desse grupo de recursos. Com o Kubernetes RBAC, tens de aplicar manifestos a cada cluster individualmente.
- Acesso Condicional e Gestão de Identidade Privilegiada (PIM). O acesso a clusters herda automaticamente as políticas existentes de Acesso Condicional do Entra ID da sua organização (como autenticação multifator ou restrições baseadas em localização) e pode ser elevado em tempo real através do PIM.
- Auditoria centralizada. Cada alteração de atribuição de função é registada no Azure Activity Log juntamente com outras alterações de recursos Azure, por isso tens um registo de auditoria para a governação de acesso ao cluster.
- Restrições de recursos personalizadas e detalhadas. Com as condições ABAC, pode restringir o acesso aos grupos e tipos específicos de recursos personalizados (CRD) sem precisar escrever os manifestos RBAC de Kubernetes por cluster.
AKS fornece as seguintes funções integradas para a autorização do Entra ID:
| Função | Description |
|---|---|
| Azure Kubernetes Service RBAC Reader | Acesso apenas de leitura à maioria dos objetos num namespace. Não permite visualizar funções, atribuições de funções, ou ainda Secrets. |
| Escritor RBAC do Serviço Azure Kubernetes | Acesso de leitura/escrita à maioria dos objetos num namespace. Não permite ver ou alterar funções ou ligações de funções. |
| Azure Kubernetes Service RBAC Admin | Acesso de leitura/escrita à maioria dos recursos num espaço de nomes, além da capacidade de criar papéis e associações de funções dentro do espaço de nomes. |
| Azure Kubernetes Service Administrador do Cluster RBAC | Controlo total sobre todos os recursos do cluster, em todos os namespaces. |
Para padrões de permissões personalizados, pode criar definições de funções personalizadas que visem grupos específicos da API Kubernetes usando as Microsoft.ContainerService ações de dados do fornecedor de recursos. Para exemplos de configuração passo a passo e funções personalizadas, consulte Usar autorização Microsoft Entra ID para a API Kubernetes.
Comparison
| Capacidade | RBAC do Kubernetes | Autorização Entra ID |
|---|---|---|
| Fonte de Identidade | Utilizadores, grupos, contas de serviço Kubernetes | Identidades do Microsoft Entra ID |
| Âmbito de uma única subvenção | Um aglomerado | Recurso, grupo de recursos, subscrição ou grupo de gestão |
| Governação multi-cluster | Aplicar manifestos a cada cluster (tipicamente GitOps) | Uma atribuição de função num âmbito mais elevado governa muitos clusters |
| Acesso Condicional / PIM | Não suportado | Herdado da Entra ID |
| Registo de auditoria | Registo de auditoria do cluster | Registo de Atividades do Azure |
| Filtrar o acesso por grupo ou tipo CRD | Objetos por autor por CRD Role |
Use atributos de condição ABAC na atribuição de funções |
Restringa o acesso a recursos personalizados com condições ABAC
Quando conceder acesso de leitura ampla através da autorização Microsoft Entra ID mas quiser restringir quais os recursos personalizados (CRDs) que o cedente pode ler, anexe uma condição Azure ABAC à atribuição de funções.
Sem as condições ABAC, conceder leitura de recursos personalizados requer um wildcard como Microsoft.ContainerService/managedClusters/*/read, que abrange todos os CRDs em cada cluster considerado. Com o ABAC, pode anexar uma condição que restrinja o acesso a grupos e tipos específicos de CRD — por exemplo, permitir templates.gatekeeper.sh enquanto bloqueia kyverno.io — sem a necessidade de escrever manifestos Kubernetes RBAC para cada cluster.
Para a autorização da API Kubernetes, pode filtrar o acesso a recursos personalizados pelo seu grupo e tipo de API usando os seguintes atributos:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Para contexto sobre o Azure ABAC, veja Quais são as condições de atribuição de funções do Azure?. Para configuração passo a passo, veja Restringir o acesso a recursos personalizados usando condições ABAC.