Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve como o AKS (Serviço de Kubernetes do Azure) decide o que um chamador autenticado tem permissão para fazer na API do Kubernetes. Aborda os dois modelos de autorização suportados pelo AKS e o controle personalizado e detalhado de recursos por meio das condições do Azure ABAC.
Para saber como o AKS autentica os chamadores em primeiro lugar, consulte os conceitos de autenticação de cluster.
Para obter uma orientação em todos os quatro cenários de identidade do AKS, consulte as opções de acesso e identidade do AKS.
Autorizar a API do Kubernetes
Depois que um chamador é autenticado, o AKS avalia se o chamador está autorizado a executar a ação solicitada. O AKS dá suporte a dois modelos de autorização para a API do Kubernetes:
- RBAC (controle de acesso baseado em função) do Kubernetes. O modelo de autorização do Kubernetes nativo. As permissões são definidas como objetos
RoleeClusterRolee são concedidas a entidades através de objetosRoleBindingeClusterRoleBindingarmazenados em cada cluster. - Autorização de identidade do Microsoft Entra. Um webhook de autorização do AKS que delega as decisões de autorização ao Microsoft Entra ID. As permissões são concedidas como atribuições de função do Azure para identidades do Entra ID e podem ser opcionalmente refinadas com condições ABAC do Azure.
Você pode usar ambos os modelos no mesmo cluster. Recomendamos a autorização do Microsoft Entra ID como padrão e reservamos o RBAC do Kubernetes para permissões intra-cluster refinadas. O restante desta seção explica por que e quando usar cada uma delas.
RBAC do Kubernetes
O RBAC do Kubernetes é o modelo de autorização principal do Kubernetes. Você cria objetos Role ou ClusterRole que concedem verbos (como get, list, create) em recursos (como pods e deployments), e os associa a entidades (usuários, grupos ou contas de serviço) usando objetos RoleBinding ou ClusterRoleBinding. O autorizador de RBAC interno do servidor de API do Kubernetes avalia essas associações em cada solicitação.
Use o RBAC do Kubernetes quando desejar:
- Controle de acesso detalhado, intra-cluster e por namespace, definido em manifestos do Kubernetes juntamente com as cargas de trabalho que protegem.
- Autorização gerenciada por GitOps que reside na mesma fonte de verdade que a configuração da sua aplicação.
- Permissões para contas de serviço no cluster que as cargas de trabalho usam para chamar a API do Kubernetes.
As permissões RBAC do Kubernetes têm como escopo um único cluster. Para aplicar a mesma política a muitos clusters, você deve aplicar os manifestos a cada cluster (normalmente por meio do GitOps). Use usuários e grupos do Microsoft Entra como assuntos nos objetos RoleBinding e ClusterRoleBinding do Kubernetes para que as identidades de pessoas continuem a ser provenientes do seu diretório central.
Para obter informações sobre o modelo RBAC do Kubernetes, consulte a documentação oficial do RBAC do Kubernetes. Para configurar no AKS, consulte Usar o RBAC do Kubernetes com integração ao Microsoft Entra.
Autorização do Microsoft Entra ID para a API do 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 do Kubernetes ao Microsoft Entra ID. Quando uma solicitação chega ao servidor da API, o webhook chama a API checkaccess do Entra ID para avaliar as atribuições de funções do Azure do solicitante (e quaisquer condições ABAC associadas) e retorna uma decisão de permissão ou recusa.
A autorização de ID do Entra oferece os seguintes benefícios em comparação com o gerenciamento de manifestos RBAC do Kubernetes em cada cluster:
- Plano de identidade única. Os mesmos usuários, grupos e entidades de serviço do Microsoft Entra que regem o acesso aos recursos do Azure também regem o acesso à API do Kubernetes. Não há nenhum diretório de usuário separado para provisionar ou rotacionar.
- Configure uma vez, gerencie vários clusters. As atribuições de função do Azure podem ser feitas na assinatura, no grupo de gerenciamento ou no escopo do grupo de recursos. Uma única atribuição de função em um escopo de grupo de recursos concede acesso a todos os clusters atuais e futuros do AKS nesse grupo de recursos. Com o RBAC do Kubernetes, você deve aplicar manifestos a cada cluster individualmente.
- Acesso condicional e PIM (Privileged Identity Management). O acesso ao cluster herda automaticamente as políticas de acesso condicional do Entra ID existentes na sua organização (como autenticação multifatorial ou restrições baseadas na localização) e pode ser ampliado no momento certo por meio do PIM.
- Auditoria centralizada. Cada alteração de atribuição de função é registrada no Log de Atividades do Azure juntamente com outras alterações de recursos do Azure, portanto, você tem uma trilha de auditoria para a governança de acesso ao cluster.
- Restrições de recursos personalizados refinadas. Com as condições ABAC, você pode restringir o acesso a grupos e tipos específicos de recursos personalizados (CRD) sem precisar gravar manifestos RBAC por cluster do Kubernetes.
O AKS fornece as seguintes funções internas para autorização da ID do Entra:
| Função | Descrição |
|---|---|
| RBAC "Leitor do Serviço de Kubernetes do Azure" | Acesso somente leitura à maioria dos objetos em um namespace. Não permite exibir funções, associações de função ou Secrets. |
| Autor de RBAC do Azure Kubernetes Service | Acesso de leitura/gravação à maioria dos objetos em um namespace. Não permite exibir ou modificar funções ou associações de função. |
| Administrador do RBAC do Azure Kubernetes Service | Acesso de leitura/gravação à maioria dos recursos em um namespace, além da capacidade de criar funções e associações de função dentro do namespace. |
| Administrador de Cluster RBAC do Azure Kubernetes Service | Controle total sobre todos os recursos do cluster, em todos os namespaces. |
Para padrões de permissão personalizados, você pode criar definições de função personalizadas direcionadas a grupos de API do Kubernetes específicos usando as Microsoft.ContainerService ações de dados do provedor de recursos. Para obter exemplos passo a passo de configuração e de funções personalizadas, consulte Usar a autorização de identificação do Microsoft Entra para a API do Kubernetes.
Comparison
| Capacidade | RBAC do Kubernetes | Autorização do ID do Entra |
|---|---|---|
| Origem da identidade | Usuários, grupos, contas de serviço do Kubernetes | Identidades do Microsoft Entra ID |
| Escopo de uma única concessão | Um cluster | Recurso, grupo de recursos, assinatura ou grupo de gerenciamento |
| Governança de vários clusters | Aplicar manifestos a cada cluster (normalmente GitOps) | Uma atribuição de função em um escopo mais alto rege muitos clusters |
| Acesso condicional/PIM | Sem suporte | Herdado da ID do Entra |
| Trilha de auditoria | Log de auditoria de cluster | Log de atividades do Azure |
| Filtrar o acesso por grupo ou tipo de CRD | Objetos por autor por objetos Role CRD |
Usar atributos de condição ABAC na atribuição de função |
Restringir o acesso a recursos personalizados com condições ABAC
Quando você conceder acesso amplo de leitura por meio da autorização do Microsoft Entra ID, mas quiser restringir quais recursos personalizados (CRDs) o destinatário pode ler, anexe uma condição do Azure ABAC à atribuição da função.
Sem as condições ABAC, a concessão de permissão de leitura em recursos personalizados requer um curinga como Microsoft.ContainerService/managedClusters/*/read, que abrange todos os CRDs em todos os clusters no escopo. Com o ABAC, você pode definir uma condição que restrinja o acesso a grupos e tipos específicos de CRD — por exemplo, permitir templates.gatekeeper.sh ao mesmo tempo em que bloqueia kyverno.io — sem precisar escrever manifestos RBAC do Kubernetes para cada cluster.
Para autorização da API do Kubernetes, você pode filtrar o acesso a recursos personalizados por seu grupo de API e tipo usando os seguintes atributos:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Para obter informações sobre o ABAC do Azure, confira Quais são as condições de atribuição de função do Azure?. Para a configuração passo a passo, consulte Restringir o acesso a recursos personalizados usando condições ABAC.