Partilhar via


Utilizar um principal do serviço com o Azure Kubernetes Service (AKS)

Os clusters Azure Kubernetes Service (AKS) requerem um principal de serviço Microsoft Entra ou uma identidade gerida para criar e gerir dinamicamente outros recursos Azure. Este artigo descreve como criar um principal de serviço Microsoft Entra e usá-lo com o seu cluster AKS.

Nota

Para uma segurança e facilidade de utilização ótimas, recomendamos o uso de identidades geridas em vez de principais de serviço para autorizar o acesso de um cluster AKS a outros recursos no Azure. Uma identidade gerida é um tipo especial de principal de serviço que pode usar para obter credenciais Microsoft Entra sem necessidade de gerir e proteger as credenciais. Para obter mais informações, consulte Usar uma identidade gerenciada no AKS.

Pré-requisitos

  • Se usar Azure PowerShell, precisa do Azure PowerShell versão 5.0.0 ou superior. Encontre a sua versão usando o Get-InstalledModule -Name Az cmdlet. Se você precisar instalar ou atualizar, consulte Instalar o módulo Azure Az PowerShell.
  • Precisa de permissões para registar uma aplicação junto do seu tenant Microsoft Entra e para atribuir a aplicação a um papel na sua subscrição. Se não tiver as permissões necessárias, precisa de pedir ao administrador do seu ID Microsoft Entra ou ao administrador de subscrição para atribuir as permissões necessárias ou criar a entidade de serviço por si.

Considerações ao utilizar um principal de serviço

Tenha em mente as seguintes considerações ao utilizar um principal de serviço Microsoft Entra com AKS:

  • A entidade de serviço do Kubernetes faz parte da configuração do cluster, mas não use essa identidade para implantar o cluster. Em vez disso, crie primeiro um principal de serviço e depois use esse principal de serviço para criar o cluster AKS.
  • Cada entidade de serviço está associada a um aplicativo Microsoft Entra. Você pode associar a entidade de serviço de um cluster Kubernetes a qualquer nome de aplicativo Microsoft Entra válido (por exemplo: https://www.contoso.org/example). O URL para a aplicação não tem de ser um ponto final real.
  • Quando especificar o ID do cliente principal do serviço, use o valor do ID da aplicação (appId para Azure CLI ou ApplicationId Azure PowerShell).
  • Nas máquinas virtuais (VMs) do nó agente no cluster AKS, as credenciais da entidade de serviço são armazenadas no ficheiro /etc/kubernetes/azure.json.
  • Quando apagas um cluster AKS que criaste usando o az aks create comando ou o New-AzAksCluster cmdlet, o principal de serviço criado não é automaticamente eliminado. Veja os passos para eliminar um principal de serviço.
  • Se você estiver usando uma entidade de serviço de um locatário diferente do Microsoft Entra, há outras considerações sobre as permissões disponíveis quando você implanta o cluster. Pode não ter as permissões adequadas para ler e escrever informações de diretórios. Para obter mais informações, consulte Quais são as permissões de usuário padrão no Microsoft Entra ID?

Criar um principal de serviço

  1. Crie uma entidade de serviço usando o az ad sp create-for-rbac comando.

    # Set environment variable
    SERVICE_PRINCIPAL_NAME=<your-service-principal-name>
    
    # Create the service principal
    az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME
    

    Sua saída deve ser semelhante à saída de exemplo a seguir:

    {
      "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "displayName": "myAKSClusterServicePrincipal",
      "name": "http://myAKSClusterServicePrincipal",
      "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
    
  2. Copie os valores de appId e password a partir da saída para usar ao criar o cluster AKS.

  1. Crie uma entidade de serviço usando o New-AzADServicePrincipal comando.

    # Set environment variable
    $SpName = <your-service-principal-name>
    
    # Create the service principal
    New-AzADServicePrincipal -DisplayName $SpName -OutVariable sp
    

    Sua saída deve ser semelhante à saída de exemplo a seguir:

    Secret                : System.Security.SecureString
    ServicePrincipalNames : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, http://myAKSClusterServicePrincipal}
    ApplicationId         : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    ObjectType            : ServicePrincipal
    DisplayName           : myAKSClusterServicePrincipal
    Id                    : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    Type                  :
    

    Os valores são armazenados numa variável que usa ao criar o cluster AKS.

  2. Descriptografe o valor armazenado na cadeia de caracteres segura Secret usando o seguinte comando.

    $BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret)
    [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
    

Crie um cluster AKS com um principal de serviço já existente

  • Crie um cluster AKS com um principal de serviço existente usando o comando az aks create com os parâmetros --service-principal e --client-secret definidos para especificar os valores appId e password.

    # Set environment variables
    RESOURCE_GROUP=<your-resource-group-name>
    CLUSTER_NAME=<your-aks-cluster-name>
    APP_ID=<app-id>
    CLIENT_SECRET=<password-value>
    
    # Create the AKS cluster
    az aks create \
        --resource-group $RESOURCE_GROUP \
        --name $CLUSTER_NAME \
        --service-principal $APP_ID \
        --client-secret $CLIENT_SECRET \
        --generate-ssh-keys
    
  1. Converta a entidade ApplicationId de serviço e Secret em um objeto PSCredential usando o comando a seguir.

    $Cred = New-Object -TypeName System.Management.Automation.PSCredential ($sp.ApplicationId, $sp.Secret)
    
  2. Crie um cluster AKS com um principal de serviço existente usando o New-AzAksCluster cmdlet e especifique o ServicePrincipalIdAndSecret parâmetro com o objeto PSCredential como seu valor.

    # Set environment variables
    $ResourceGroupName = <your-resource-group-name>
    $ClusterName = <your-aks-cluster-name>
    
    # Create the AKS cluster
    New-AzAksCluster -ResourceGroupName $ResourceGroupName -Name $ClusterName -ServicePrincipalIdAndSecret $Cred
    

Nota

Se estiver a utilizar uma entidade de serviço existente com segredo personalizado, certifique-se de que o segredo não tem mais de 190 bytes.

Delegar acesso a outros recursos do Azure

Você pode usar a entidade de serviço para o cluster AKS para acessar outros recursos. Por exemplo, se quiser implementar o seu cluster AKS numa sub-rede existente de rede virtual Azure (VNet), ligar-se ao ACR, ou aceder chaves ou segredos num cofre de chaves do seu cluster, então precisa de delegar o acesso a esses recursos ao principal do serviço. Para delegar acesso, atribua uma função de controle de acesso baseado em função do Azure (Azure RBAC) à entidade de serviço.

Quando atribui funções, especifica o âmbito para a atribuição de funções, como um grupo de recursos ou recurso VNet. A atribuição de função determina quais permissões a entidade de serviço tem no recurso e em que escopo.

Importante

Permissões concedidas a um principal de serviço associado a um cluster podem demorar até 60 minutos a propagar-se.

Criar uma atribuição de funções

Nota

O âmbito de um recurso precisa de ser um ID de recurso completo, como /subscriptions/\<guid\>/resourceGroups/myResourceGroup ou /subscriptions/\<guid\>/resourceGroups/myResourceGroupVnet/providers/Microsoft.Network/virtualNetworks/myVnet.

  • Crie uma atribuição de função usando o az role assignment create comando. Especifique o valor do ID da aplicação principal do serviço para o --assignee parâmetro e o âmbito para a atribuição de funções ao --scope parâmetro. O exemplo seguinte atribui permissões ao principal de serviço para aceder a segredos num cofre de chaves:

    az role assignment create \
        --assignee <app-id> \
        --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" \
        --role "Key Vault Secrets User"
    
  • Cria uma atribuição de função usando o New-AzRoleAssignment cmdlet. Especifique o valor do ID da aplicação principal do serviço para o -ApplicationId parâmetro e o âmbito para a atribuição de funções ao -Scope parâmetro. O exemplo seguinte atribui permissões ao principal de serviço para aceder a segredos num cofre de chaves:

    New-AzRoleAssignment -ApplicationId <app-id> `
        -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" `
        -RoleDefinitionName "Key Vault Secrets User"
    

Conceder acesso ao Azure Container Registry

Se você usar o Azure Container Registry (ACR) como seu armazenamento de imagens de contêiner, precisará conceder permissões à entidade de serviço para que seu cluster AKS leia e extraia imagens. Recomendamos seguir os passos em Autenticar com o Azure Container Registry a partir do Azure Kubernetes Service para integrar com um registo e atribuir o papel apropriado ao principal do serviço.

Conceder acesso a recursos de rede

Se estiveres a utilizar redes avançadas com uma VNet e uma sub-rede ou endereços IP públicos em diferentes grupos de recursos, podes atribuir o papel incorporado de Network Contributor na sub-rede dentro da VNet. Como alternativa, você pode criar uma função personalizada com permissões para acessar os recursos de rede nesse grupo de recursos. Para obter mais informações, consulte Permissões de serviço AKS.

Conceder acesso a discos de armazenamento

Se você precisar acessar recursos de disco existentes em outro grupo de recursos, atribua um dos seguintes conjuntos de permissões de função:

  • Crie uma função personalizada e defina as permissões de função Microsoft.Compute/disks/read e Microsoft.Compute/disks/write.
  • Atribua a função interna de Colaborador de Máquina Virtual no grupo de recursos.

Conceder acesso ao Azure Container Instances

Se usar o virtual kubelet para se integrar com o AKS e executar o Azure Container Instances (ACI) num grupo de recursos separado do cluster AKS, precisa de atribuir permissões de Contributor ao principal de serviço do AKS para o grupo de recursos do ACI.

Excluir um principal de serviço

  • Procure o ID de cliente do principal de serviço (servicePrincipalProfile.clientId) e elimine o principal de serviço utilizando o comando az ad sp delete com o parâmetro --id. O comando [az aks show][az-aks-show] recupera o ID do cliente para o cluster AKS especificado.

    # Set environment variables
    RESOURCE_GROUP=<your-resource-group-name>
    CLUSTER_NAME=<your-aks-cluster-name>
    
    # Delete the service principal
    az ad sp delete --id $(az aks show \
        --resource-group $RESOURCE_GROUP \
        --name $CLUSTER_NAME \
        --query servicePrincipalProfile.clientId \
        --output tsv)
    
  • Consulte o ID do cliente principal de serviço (ServicePrincipalProfile.ClientId) e elimine o principal de serviço usando o Remove-AzADServicePrincipal cmdlet com o -ApplicationId parâmetro. O cmdlet [Get-AzAksCluster][get-azakscluster] recupera o ID do cliente para o cluster AKS especificado.

    # Set environment variables
    $ResourceGroupName = <your-resource-group-name>
    $ClusterName = <your-aks-cluster-name>
    $ClientId = (Get-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster ).ServicePrincipalProfile.ClientId
    
    # Delete the service principal
    Remove-AzADServicePrincipal -ApplicationId $ClientId
    

Resolver questões de credencial do principal de serviço

A CLI do Azure armazena em cache as credenciais da entidade de serviço para clusters AKS.

O Azure PowerShell armazena em cache as credenciais da entidade de serviço para clusters AKS.

Se estas credenciais expirarem, poderá encontrar erros durante a implementação do cluster AKS. Se houver um problema com as credenciais em cache, pode receber uma mensagem de erro semelhante à seguinte:

Operation failed with status: 'Bad Request'.
Details: The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for more details.
Details: adal: Refresh request failed. Status Code = '401'.

Você pode verificar a data de expiração de suas credenciais da entidade de serviço usando o az ad app credential list comando com a "[].endDateTime" consulta. A saída mostra as endDateTime suas credenciais.

az ad app credential list \
    --id <app-id> \
    --query "[].endDateTime" \
    --output tsv
  • Verifique a data de validade das credenciais do serviço principal usando o comando Get-AzADAppCredential cmdlet. A saída mostra as EndDate suas credenciais.
Get-AzADAppCredential -ApplicationId <app-id> 

O prazo de expiração padrão para as credenciais do principal de serviço é de um ano. Se suas credenciais tiverem mais de um ano, você poderá redefinir as credenciais existentes ou criar uma nova entidade de serviço.