Use o Privileged Identity Management (PIM) para controlar o acesso aos clusters do Serviço de Kubernetes do Azure (AKS)

Artigo
10/15/2024

Ao configurar permissões para equipes diferentes, convém definir permissões padrão para equipes especificadas e conceder acesso privilegiado a usuários específicos quando necessário. Usar o Serviço de Kubernetes do Azure (AKS) com o Microsoft Entra ID permite configurar o Privileged Identity Management (PIM) para solicitações just-in-time (JIT).

Neste artigo, você aprenderá como:

Defina funções padrão para grupos de exemplo acessarem ou executarem operações em clusters do AKS com base nas associações de grupo do Microsoft Entra.
Configure funções básicas para acessar clusters do AKS.
Funções autoativadas para obter acesso just-in-time aos clusters do AKS.
Defina aprovadores para aprovar ou negar solicitações de aprovação para acesso just-in-time.

Observação

O Microsoft Entra Privileged Identity Management (PIM) tem recursos do Microsoft Entra ID Governance P2 ou do Microsoft Entra ID que exigem um SKU P2 Premium. Para obter mais informações, confira os conceitos básicos de licenciamento do Microsoft Entra ID Governance e o guia de preços.

Pré-requisitos

Este artigo pressupõe que você tenha um cluster AKS existente com a integração do Microsoft Entra ID. Se você não tiver um, confira Criar um cluster do AKS com a integração do Microsoft Entra ID.

Crie grupos de demonstração no Microsoft Entra ID

Nesta seção, criamos três grupos no Microsoft Entra ID:

Padrão: este grupo tem acesso somente leitura (Azure Kubernetes Service RBAC Reader) aos recursos no cluster do AKS.
Administrador: este grupo tem acesso de administrador (Azure Kubernetes Service RBAC Admin) aos recursos no cluster do AKS.
Aprovador: este grupo tem permissões para aprovar ou negar solicitações de acesso just-in-time ao cluster do AKS.

Você pode usar apenas os grupos padrão e de administrador em vez de criar um grupo de aprovadores separado. No entanto, se você incluir permissões de aprovação no grupo de administradores, o membro que obtém acesso just-in-time poderá aprovar suas próprias solicitações e as solicitações de outras pessoas. Não recomendamos usar essa configuração em um ambiente de produção, mas ela é útil para fins de teste.

Criar grupo padrão

Obtenha a ID do recurso do cluster do AKS usando o comando az aks show.

AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

Obtenha a ID do grupo de recursos do cluster do AKS usando o comando az group show.

RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)

Crie o grupo padrão usando o comando az ad group create.

DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

Crie uma atribuição de função do Azure para o grupo padrão usando o comando az role assignment create.

Há três funções que você pode atribuir ao grupo padrão, dependendo de seus requisitos específicos:
- Azure Kubernetes Service RBAC Reader: atribuído no escopo do cluster do AKS e fornece acesso básico somente leitura à maioria dos recursos no cluster.
- Reader: atribuído no escopo do grupo de recursos e fornece acesso somente leitura aos recursos no grupo de recursos.
- Azure Kubernetes Service Cluster User Role: atribuído no escopo do cluster do AKS e dá acesso para obter o contexto kubeconfig para o cluster do AKS.
```
# Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID
```

Criar grupo de administradores

Crie o grupo de administradores usando o comando az ad group create.

ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

Atribua a função Azure Kubernetes Service RBAC Admin ao grupo de administradores usando o comando az role assignment create.

az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID

Observação

Se você quiser permitir que os usuários no grupo de administradores alterem as configurações do pool de nós, como a escala manual, será necessário criar uma atribuição de função Contributor no pool de nós de cluster usando o seguinte comando:

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

Tenha em mente que isso só dá permissão para escalar ou sair do recurso do AKS. Se você quiser permitir a escala dentro ou fora do recurso conjunto de dimensionamento de máquinas virtuais, será necessário criar uma atribuição no nível do conjunto de dimensionamento de máquinas virtuais.

Criar grupo aprovador

Crie o grupo de aprovadores usando o comando az ad group create.

APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

Crie usuários de demonstração no Microsoft Entra ID

Nesta seção, criamos dois usuários no Microsoft Entra ID: um usuário normal com apenas a função padrão, e um usuário privilegiado que pode aprovar ou negar solicitações just-in-time do usuário normal.

Crie o usuário normal usando o comando az ad user create.

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

Adicione o usuário normal ao grupo padrão usando o comando az ad group member add.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Crie o usuário privilegiado usando o comando az ad user create.

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

Adicione o usuário privilegiado ao grupo aprovador usando o comando az ad group member add.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Habilitar o Privileged Identity Management (PIM) para o grupo de administradores

Na Página inicial do portal do Azure, selecione Microsoft Entra ID.
No menu de serviço, em Gerenciar, selecione Grupos e selecione o grupo de administradores.
No menu de serviço, em Atividade, selecione Privileged Identity Management e, em seguida, selecione Habilitar PIM para este grupo.

Definir um aprovador para o grupo de administradores

Na página inicial do portal do Azure, pesquise e selecione Privileged Identity Management.
No menu de serviço, em Gerenciar, selecione Grupos e selecione o grupo de administradores.
No menu de serviço, em Gerenciar, selecione Atribuições>Adicionar atribuições.
Na guia Associação da página Adicionar atribuições, selecione Membro como a função selecionada e padrão como o membro selecionado e selecione Avançar.
Na guia Configurações, selecione Qualificado como o tipo de atribuição e selecione Atribuir.
No menu de serviço, em Gerenciar, selecione Configurações>Membro>Editar.
Na página Editar configuração de função – Membro, selecione a caixa de seleção Exigir aprovação para ativar e adicione o grupo de aprovadores como o aprovador selecionado.

Observação

Se você não selecionar a caixa de seleção Exigir aprovação para ativar, os usuários no grupo padrão poderão ativar automaticamente a função para obter acesso just-in-time ao cluster do AKS sem aprovação. O usuário no grupo de aprovadores precisa ser membro do grupo. Mesmo que você defina o usuário como o proprietário, ele ainda não poderá examinar solicitações just-in-time porque o proprietário do grupo só tem direitos administrativos para o grupo, não a atribuição de função. Você pode definir o usuário como o membro e o proprietário do mesmo grupo sem conflitos.
Faça outras alterações necessárias e selecione Atualizar.

Para obter mais informações sobre a configuração do PIM, confira Configurar o PIM para grupos.

Interagir com recursos de cluster usando a função padrão

Agora, podemos tentar acessar o cluster do AKS usando o usuário normal, que é membro do grupo padrão.

Faça logon no portal do Azure como o usuário normal usando o comando az login.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Obtenha as credenciais de usuário para acessar o cluster usando o comando az aks get-credentials.
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Tente acessar os pods de cluster usando o comando kubectl get.

kubectl get pods --namespace kube-system

Sua saída deve ser semelhante à seguinte saída de exemplo, que mostra os pods no namespace kube-system:

NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

Tente acessar os segredos do cluster usando o comando kubectl get.
```
kubectl get secrets --namespace kube-system
```
Sua saída deve ser semelhante à seguinte saída de exemplo, que mostra uma mensagem de erro porque o usuário não tem permissão para acessar os segredos:
```
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.
```
A função Azure Kubernetes Service RBAC Reader não tem permissão para acessar segredos, portanto, esse erro é esperado.

Solicitar acesso just-in-time ao cluster do AKS

Desta vez, podemos solicitar acesso just-in-time como Azure Kubernetes Service RBAC Admin temporário usando as etapas em Ativar sua associação a um grupo ou propriedade de um grupo no Privileged Identity Management. Para saber como aprovar ou negar solicitações como aprovador, confira Aprovar solicitações de ativação para membros e proprietários do grupo.

Interagir com recursos de cluster usando a função de administrador

Depois de adicionar temporariamente a função Azure Kubernetes Service RBAC Admin, você pode acessar os recursos de cluster que exigem permissões de administrador.

Remova tokens armazenados existentes usando o seguinte comando kubelogin:
```
kubelogin remove-tokens
```
Observação

Se você encontrar um erro devido à falta de permissões, faça logon para atualizar as permissões usando o comando az login.
Tente acessar os segredos do cluster novamente usando o comando kubectl get secrets.
```
kubectl get secrets --namespace kube-system
```
Sua saída deve ser semelhante à seguinte saída de exemplo, que mostra os segredos no namespace kube-system:
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
O usuário agora pode acessar os segredos porque tem a função Azure Kubernetes Service RBAC Admin.

Considerações sobre o tempo de vida do token

Devido ao design de tempo de vida do token, se você estiver concedendo funções a usuários que usam ferramentas da CLI, como kubectl ou kubelogin, tecnicamente, a duração da ativação não poderá ser inferior a 60 minutos. Mesmo que a duração seja definida como menor que 60 minutos, a duração efetiva real permanece entre 60 e 75 minutos.

Quando kubelogin tenta obter tokens da plataforma de identidade da Microsoft e access_token e refresh_token são retornados para uso adicional. O access_token faz solicitações para a API, e refresh_token é usado para obter um novo access_token quando o atual expira. O access_token não pode ser revogado uma vez gerado, mas o refresh_token pode ser revogado. Se o refresh_token for revogado, o usuário precisará se reautenticar para obter um novo refresh_token. Para revogar o refresh_token manualmente, você pode usar Revoke-AzureADUserAllRefreshToken.

Próximas etapas

Para obter mais informações, consulte os seguintes artigos:

Compartilhar via