Use o controle de acesso baseado em função do Kubernetes com o Microsoft Entra ID no Serviço de Kubernetes do Azure
O Serviço de Kubernetes do Azure (AKS) pode ser configurado para usar o Microsoft Entra ID para autenticação de usuário. Nessa configuração, você faz logon em um cluster do AKS usando o token de autenticação do Microsoft Entra. Depois de autenticado, você pode usar o controle de acesso baseado em função interno do Kubernetes (Kubernetes RBAC) para gerenciar o acesso a namespaces e a recursos de cluster com base na identidade ou associação de grupo de um usuário.
Este artigo mostra como:
- Controle o acesso usando o Kubernetes RBAC em um cluster do AKS baseado em associação de grupo do Microsoft Entra.
- Crie exemplos de grupos e usuários no Microsoft Entra ID.
- Criar funções e associações de função em um cluster do AKS para conceder as permissões apropriadas para criar e ver recursos.
Antes de começar
- Você tem um cluster do AKS existente com a integração do Microsoft Entra habilitada. Se você precisar de um cluster do AKS com essa configuração, consulte Integrar o Microsoft Entra ID ao AKS.
- O RBAC do Kubernetes é habilitado por padrão durante a criação do cluster do AKS. Para atualizar seu cluster com a integração do Microsoft Entra e o Kubernetes RBAC, Habilite a integração do Microsoft Entra no seu cluster do AKS existente.
- Verifique se a CLI do Azure versão 2.0.61 ou posterior está instalada e configurada. Execute
az --version
para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure. - No caso do Terraform, instale a versão 2.99.0 ou posterior.
Use o portal do Azure ou a CLI do Azure para verificar se a integração do Microsoft Entra com RBAC do Kubernetes está habilitada.
Para verificar usando o portal do Azure:
- Entre no portal do Azure e navegue até o recurso de cluster do AKS.
- No menu de serviço, em Configurações, selecione Configuração do cluster.
- Na seção Autenticação e Autorização, verifique se a opção Autenticação do Microsoft Entra com o RBAC do Kubernetes está selecionada.
Crie grupos de demonstração no Microsoft Entra ID
Neste artigo, vamos criar duas funções de usuário para mostrar como o Kubernetes RBAC e o Microsoft Entra ID controlam o acesso aos recursos de cluster. As duas funções de exemplo a seguir são usadas:
- Desenvolvedor de aplicativo
- Um usuário chamado aksdev que faz parte do grupo appdev.
- Engenharia de confiabilidade de sites
- Um usuário chamado akssre que faz parte do grupo opssre.
Em ambientes de produção, você pode usar usuários e grupos existentes em um locatário do Microsoft Entra.
Primeiro, obternha o ID do recurso do seu cluster AKS usando o comando
az aks show
. Depois, atribua a ID de recurso a uma variável chamada AKS_ID para que ela possa ser referenciada em outros comandos.AKS_ID=$(az aks show \ --resource-group myResourceGroup \ --name myAKSCluster \ --query id -o tsv)
Crie o primeiro exemplo de grupo no Microsoft Entra ID para os desenvolvedores de aplicativos usando o comando
az ad group create
. O seguinte exemplo cria um grupo chamado appdev:APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
Crie uma atribuição de função do Azure para o grupo appdev usando o comando
az role assignment create
. Essa atribuição permite que qualquer membro do grupo usekubectl
para interagir com um cluster do AKS concedendo a função Usuário do cluster do Serviço de Kubernetes do Azure.az role assignment create \ --assignee $APPDEV_ID \ --role "Azure Kubernetes Service Cluster User Role" \ --scope $AKS_ID
Dica
Se você receber um erro como Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.
, aguarde alguns segundos para a ID de objeto de grupo do Microsoft Entra se propagar por meio do diretório e depois repita o comando az role assignment create
.
Crie um segundo grupo de exemplo para SREs chamado opssre.
OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
Crie uma atribuição de função do Azure para conceder aos membros do grupo a função Usuário do cluster do Serviço de Kubernetes do Azure.
az role assignment create \ --assignee $OPSSRE_ID \ --role "Azure Kubernetes Service Cluster User Role" \ --scope $AKS_ID
Crie usuários de demonstração no Microsoft Entra ID
Agora que temos dois exemplos de grupo no Microsoft Entra ID para nossos desenvolvedores de aplicativos e SREs, vamos criar dois exemplos de usuário. Para testar a integração do RBAC do Kubernetes no final do artigo, você entrará no cluster do AKS com essas contas.
Definir o nome UPN e a senha para os desenvolvedores de aplicativos
Defina o nome principal do usuário (UPN) e a senha para os desenvolvedores de aplicativos. O UPN deve incluir o nome de domínio verificado do seu locatário, por exemplo aksdev@contoso.com
.
O comando a seguir solicita o UPN e o define como AAD_DEV_UPN para que ele possa ser usado em um comando posterior:
echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN
O seguinte comando solicita a senha e a define como AAD_DEV_PW para uso em um comando posterior:
echo "Please enter the secure password for application developers: " && read AAD_DEV_PW
Criar as contas de usuário
- Crie a primeira conta de usuário no Microsoft Entra ID usando o comando
az ad user create
. O exemplo a seguir cria um usuário com o nome de exibição AKs dev e o UPN e a senha segura usando os valores em AAD_DEV_UPN e AAD_DEV_PW:
AKSDEV_ID=$(az ad user create \
--display-name "AKS Dev" \
--user-principal-name $AAD_DEV_UPN \
--password $AAD_DEV_PW \
--query id -o tsv)
- Adicione o usuário ao grupo appdev criado na seção anterior usando o comando
az ad group member add
.
az ad group member add --group appdev --member-id $AKSDEV_ID
- Defina o UPN e a senha para SREs. O UPN deve incluir o nome de domínio verificado do seu locatário, por exemplo
akssre@contoso.com
. O seguinte comando solicita o UPN e define-o como AAD_SRE_UPN para uso em um comando posterior:
echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
- O seguinte comando solicita a senha e define-a como AAD_SRE_PW para uso em um comando posterior:
echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
- Criar uma segunda conta de usuário. O exemplo a seguir cria um usuário com o nome de exibição AKS SRE e o UPN e a senha segura usando os valores em AAD_SRE_UPN e AAD_SRE_PW:
# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
--display-name "AKS SRE" \
--user-principal-name $AAD_SRE_UPN \
--password $AAD_SRE_PW \
--query id -o tsv)
# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID
Criar os recursos de cluster do AKS para desenvolvedores de aplicativos
Já temos nossos grupos e usuários do Microsoft Entra, e temos atribuições de função do Azure criados. Agora, vamos configurar o cluster do AKS para permitir que esses diferentes grupos acessem recursos específicos.
- Obtenha as credenciais de administrador do cluster usando o comando
az aks get-credentials
. Em uma das seções a seguir, você obtém as credenciais do cluster de usuários comuns para ver o fluxo de autenticação do Microsoft Entra em ação.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
- Crie um namespace no cluster AKS usando o comando
kubectl create namespace
. O exemplo a seguir cria um nome de namespace dev:
kubectl create namespace dev
Observação
Em Kubernetes,Funções definem as permissões a serem concedidas e RoleBindings as aplicam aos usuários ou grupos desejados. Essas atribuições podem ser aplicadas a um determinado namespace ou em todo o cluster. Para obter mais informações, confira Usar a autorização do RBAC para Kubernetes.
Se o usuário para o qual você concedeu a associação do Kubernetes RBAC estiver no mesmo locatário do Microsoft Entra, atribua permissões com base no userPrincipalName (UPN). Se o usuário estiver em um locatário diferente do Microsoft Entra, consulte e use a propriedade objectId.
- Crie uma função para o namespace dev, que conceda permissões completas ao namespace. Em ambientes de produção, você pode especificar permissões mais granulares para diferentes usuários ou grupos. Crie um arquivo chamado
role-dev-namespace.yaml
e cole o manifesto YAML a seguir:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-user-full-access
namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
- Crie a Função usando o comando
kubectl apply
e especifique o nome do arquivo do manifesto YAML.
kubectl apply -f role-dev-namespace.yaml
- Obtenha a ID do recurso do grupo appdev usando o comando
az ad group show
. Esse grupo é definido como o assunto de uma Rolebinding na próxima etapa.
az ad group show --group appdev --query id -o tsv
- Crie uma associação de função para o grupo appdev usar a função que foi criada para acesso de namespace. Crie um arquivo chamado
rolebinding-dev-namespace.yaml
e cole o manifesto YAML a seguir. Na última linha, substitua groupObjectId pela saída de ID de objeto de grupo do comando anterior.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-user-access
namespace: dev
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: dev-user-full-access
subjects:
- kind: Group
namespace: dev
name: groupObjectId
Dica
Caso deseje criar a RoleBinding para um só usuário, especifique kind: User e substitua groupObjectId pelo UPN no exemplo acima.
- Crie o RoleBinding usando o comando
kubectl apply
e especifique o nome do arquivo do manifesto YAML:
kubectl apply -f rolebinding-dev-namespace.yaml
Criar os recursos de cluster AKS para os SREs
Agora, repita as etapas anteriores para criar um namespace, uma função e uma associação de função para SREs.
- Crie um namespace para sre usando o comando
kubectl create namespace
.
kubectl create namespace sre
- Crie um arquivo chamado
role-sre-namespace.yaml
e cole o manifesto YAML a seguir:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: sre-user-full-access
namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
- Crie a Função usando o comando
kubectl apply
e especifique o nome do arquivo do manifesto YAML.
kubectl apply -f role-sre-namespace.yaml
- Obtenha a ID do recurso para o grupo opssre usando o comando az ad group show.
az ad group show --group opssre --query id -o tsv
- Crie uma RoleBinding para o grupo opssre para usar a função criada anteriormente para acesso de namespace. Crie um arquivo chamado
rolebinding-sre-namespace.yaml
e cole o manifesto YAML a seguir. Na última linha, substitua groupObjectId pela saída de ID de objeto de grupo do comando anterior.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: sre-user-access
namespace: sre
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: sre-user-full-access
subjects:
- kind: Group
namespace: sre
name: groupObjectId
- Crie a associação de função usando o comando
kubectl apply
e especifique o nome do arquivo do manifesto YAML.
kubectl apply -f rolebinding-sre-namespace.yaml
Interaja com os recursos do cluster usando identidades do Microsoft Entra
Agora, vamos testar se as permissões esperadas funcionam quando você cria e gerencia recursos em um cluster AKS. Nesses exemplos, agendaremos e exibiremos pods no namespace atribuído pelo usuário e tentaremos agendar e exibir pods fora do namespace atribuído.
- Redefina o contexto kubeconfig usando o comando
az aks get-credentials
. Em uma seção anterior, você define o contexto usando as credenciais de administrador do cluster. O usuário administrador ignora os prompts de logon do Microsoft Entra. Sem o parâmetro--admin
, é aplicado o contexto de usuário que exige que todas as solicitações sejam autenticadas usando o Microsoft Entra ID.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
- Agende um pod NGINX básico usando o comando
kubectl run
no namespace dev.
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
- Insira as credenciais da sua conta
appdev@contoso.com
criada no início do artigo como o prompt de entrada. Depois que você entrar com êxito, o token da conta será armazenado em cache para futuros comandoskubectl
. O NGINX é agendado com êxito, conforme mostrado na seguinte saída de exemplo:
$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.
pod/nginx-dev created
- Use o comando
kubectl get pods
para exibir os pods no namespace dev.
kubectl get pods --namespace dev
- Verifique se o status do pod NGINX está Em execução. A saída será parecida com a seguinte:
$ kubectl get pods --namespace dev
NAME READY STATUS RESTARTS AGE
nginx-dev 1/1 Running 0 4m
Criar e exibir recursos de cluster fora do namespace atribuído
Tente ver os pods fora do namespace dev. Use o comando kubectl get pods
novamente, desta vez para ver --all-namespaces
.
kubectl get pods --all-namespaces
A associação de grupo do usuário não tem uma função do Kubernetes que permita essa ação, conforme mostrado na seguinte saída de exemplo:
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope
Da mesma forma, tente agendar um pod em um namespace diferente, como o namespace sre. A associação de grupo do usuário não se alinha a uma função do Kubernetes e a uma associação de função para conceder essas permissões, conforme é mostrado na seguinte saída de exemplo:
$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"
Testar o acesso do SRE aos recursos de cluster do AKS
Para confirmar que a associação ao grupo do Microsoft Entra e o Kubernetes RBAC funcionam corretamente entre diferentes usuários e grupos, tente os comandos anteriores quando estiver conectado como o usuário opssre.
- Redefina o contexto kubeconfig usando o comando
az aks get-credentials
que limpa o token de autenticação armazenado em cache anteriormente para o usuário aksdev.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
- Tente agendar e exibir pods no namespace SRE atribuído. Quando solicitado, entre com suas credenciais do
opssre@contoso.com
criadas no início do artigo.
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre
Conforme mostrado na saída de exemplo a seguir, você pode criar e exibir com êxito o pods:
$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
3. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.
pod/nginx-sre created
$ kubectl get pods --namespace sre
NAME READY STATUS RESTARTS AGE
nginx-sre 1/1 Running 0
- Tente ver ou agendar pods fora do namespace do SRE atribuído.
kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Esses kubectl
comandos falham, conforme mostrado na saída de exemplo a seguir. A associação de grupo do usuário e a função e as associações de função do Kubernetes não concedem permissões para criar ou gerentes de recursos em outros namespaces.
$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope
$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"
Limpar os recursos
Neste artigo, você criou recursos no cluster de AKS e usuários e grupos no Microsoft Entra ID. Para limpar todos esses recursos, execute os seguintes comandos:
# Get the admin kubeconfig context to delete the necessary cluster resources.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.
kubectl delete namespace dev
kubectl delete namespace sre
# Delete the Azure AD user accounts for aksdev and akssre.
az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID
# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.
az ad group delete --group appdev
az ad group delete --group opssre
Próximas etapas
Para obter mais informações de como proteger clusters do Kubernetes, confira Opções de acesso e identidade do AKS.
Para obter as melhores práticas sobre identidade e controle de recursos, confira Melhores práticas para autenticação e autorização no AKS.
Azure Kubernetes Service