Use o PIM, Gerenciamento Privilegiado de Identidades (PIM), para controlar o acesso aos clusters do Serviço Kubernetes do Azure (AKS)

Artigo
09/04/2024

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

Neste artigo, vai aprender a:

Defina funções padrão, por exemplo, grupos para acessar ou executar operações em clusters AKS com base em associações de grupo do Microsoft Entra.
Configure funções básicas para acessar clusters AKS.
Autoative funções para obter acesso just-in-time a clusters AKS.
Defina os aprovadores para aprovar ou negar solicitações de aprovação para acesso just-in-time.

Nota

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

Pré-requisitos

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

Criar 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 AKS.
Admin: Este grupo tem acesso de administrador (Azure Kubernetes Service RBAC Admin) aos recursos no cluster AKS.
Aprovador: Este grupo tem permissões para aprovar ou negar solicitações de acesso just-in-time ao cluster AKS.

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

Criar grupo padrão

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

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

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

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

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

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 az role assignment create comando.

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 AKS e fornece acesso básico somente leitura à maioria dos recursos no cluster.
- Reader: Atribuído no escopo do grupo de recursos e dá acesso somente leitura aos recursos no grupo de recursos.
- Azure Kubernetes Service Cluster User Role: Atribuído no escopo do cluster AKS e dá acesso para obter o contexto kubeconfig para o cluster 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 az ad group create comando.

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

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

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

Nota

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

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

Lembre-se de que isso só dá permissão para aumentar ou diminuir a escala a partir do recurso AKS. Se quiser permitir o dimensionamento para dentro ou para fora a partir do recurso Conjunto de Dimensionamento de Máquina Virtual, será necessário criar uma atribuição no nível do Conjunto de Dimensionamento de Máquina Virtual.

Criar grupo de aprovador

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

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

Criar 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 az ad user create comando.

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 az ad group member add comando.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

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

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 de aprovadores usando o az ad group member add comando.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Habilitar o PIM, Gerenciamento de Identidade Privilegiado (PIM) para o grupo de administradores

Na home page do portal do Azure, selecione Microsoft Entra ID.
No menu de serviço, em Gerir, selecione Grupos e, em seguida, selecione o grupo de administradores .
No menu de serviço, em Atividade, selecione Gerenciamento privilegiado de identidades e, em seguida, selecione Habilitar PIM para este grupo.

Definir um aprovador para o grupo de administradores

Na home page do portal do Azure, procure e selecione Privileged Identity Management.
No menu de serviço, em Gerir, selecione Grupos e, em seguida, 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, em seguida, selecione Avançar.
No separador Definições, selecione Elegível como o tipo de atribuição e, em seguida, selecione Atribuir.
No menu de serviço, em Gerenciar, selecione Configurações>de edição de membro.>
Na página Editar configuração de função - Membro , marque a caixa de seleção Exigir aprovação para ativar e adicione o grupo de aprovador como o aprovador selecionado.

Nota

Se você não marcar a caixa de seleção Exigir aprovação para ativar , os usuários do grupo padrão poderão autoativar a função para obter acesso just-in-time ao cluster AKS sem aprovação. O usuário no grupo de aprovador deve ser um membro do grupo. Mesmo que você defina o usuário como proprietário, ele ainda não poderá revisar 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 membro e proprietário do mesmo grupo sem conflito.
Faça quaisquer outras alterações necessárias e selecione Atualizar.

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

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

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

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

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

kubectl get pods --namespace kube-system

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

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 kubectl get comando.
```
kubectl get secrets --namespace kube-system
```
Sua saída deve ser semelhante à saída de exemplo a seguir, 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 Azure Kubernetes Service RBAC Reader função não tem permissão para acessar segredos, portanto, esse erro é esperado.

Solicitar acesso just-in-time ao cluster AKS

Desta vez, podemos solicitar acesso just-in-time como temporário Azure Kubernetes Service RBAC Admin usando as etapas em Ativar sua associação de grupo ou propriedade no Privileged Identity Management. Para saber como aprovar ou negar solicitações como aprovador, consulte 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 Azure Kubernetes Service RBAC Admin função, você pode acessar os recursos de cluster que exigem permissões de administrador.

Remova os tokens armazenados existentes usando o seguinte kubelogin comando:
```
kubelogin remove-tokens
```
Nota

Se você encontrar um erro devido à falta de permissões, faça login para atualizar as permissões usando o az login comando.
Tente acessar os segredos do cluster novamente usando o kubectl get secrets comando.
```
kubectl get secrets --namespace kube-system
```
Sua saída deve ser semelhante à saída de exemplo a seguir, que mostra os segredos no kube-system namespace:
```
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 eles têm a Azure Kubernetes Service RBAC Admin função.

Considerações sobre o tempo de vida do token

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

Quando kubelogin tenta obter tokens da plataformaaccess_token de identidade da Microsoft e refresh_token são retornados para uso posterior. O access_token faz solicitações para a API, e o 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 terá que autenticar novamente para obter um novo refresh_token. Para revogar manualmente o refresh_token, você pode usar Revoke-AzureADUserAllRefreshTokeno .

Próximos passos

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

Partilhar via