Usar o RBAC do Azure para clusters de Kubernetes habilitados para Azure Arc (versão prévia)

Os tipos de objeto Kubernetes ClusterRoleBinding e Rolebinding ajudam a definir a autorização no Kubernetes nativamente. Ao usar esse recursos, é possível usar o Microsoft Entra ID e as atribuições de função no Azure para controlar as verificações de autorização no cluster. As atribuições de função do Azure permitem que você controle, de modo granular, quais usuários podem ler, gravar e excluir objetos do Kubernetes como implantação, pod e serviço.

Para obter uma visão geral conceitual desse recurso, confira RBAC do Azure no Kubernetes habilitado para Azure Arc.

Importante

As versões prévias do recurso Kubernetes habilitadas para o Azure Arc estão disponíveis com base em autoatendimento e aceitação. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do Kubernetes habilitadas para o Azure Arc são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço.

Pré-requisitos

  • Instale ou atualize a CLI do Azure para a última versão.

  • Instale a última versão da extensão connectedk8s da CLI do Azure:

    az extension add --name connectedk8s
    

    Se a extensão connectedk8s já estiver instalada, você poderá atualizá-la para a versão mais recente usando o seguinte comando:

    az extension update --name connectedk8s
    
  • Conecte um cluster existente de Kubernetes habilitado para Azure Arc:

Observação

Esse recurso não pode ser configurado para OpenShift do Red Hat ou para ofertas do Kubernetes gerenciado de provedores de nuvem, como o Elastic Kubernetes Service ou o Google Kubernetes Engine, em que o usuário não tem acesso ao servidor de API do cluster. Esse recurso está disponível nativamente para clusters do AKS (Serviço de Kubernetes do Azure), e eles não precisam estar conectados ao Azure Arc.

Configurar aplicativos do Microsoft Entra

Criar um aplicativo de servidor

  1. Crie um novo aplicativo do Microsoft Entra e obtenha seu valor appId. Esse valor será usado em etapas posteriores como serverApplicationId.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
    TENANT_ID="<tenant>"
    SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
    SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
    echo $SERVER_APP_ID
    
  2. Para conceder permissões de API "Entrar e ler perfil de usuário" ao aplicativo de servidor, copie este JSON e salve-o em um arquivo chamado oauth2-permissions.json:

    {
        "oauth2PermissionScopes": [
            {
                "adminConsentDescription": "Sign in and read user profile",
                "adminConsentDisplayName": "Sign in and read user profile",
                "id": "<paste_the_SERVER_APP_ID>",
                "isEnabled": true,
                "type": "User",
                "userConsentDescription": "Sign in and read user profile",
                "userConsentDisplayName": "Sign in and read user profile",
                "value": "User.Read"
            }
        ]
    }
    
  3. Atualize as declarações de associação do grupo de aplicativos. Execute os comandos no mesmo diretório que o arquivo oauth2-permissions.json. O RBAC para Kubernetes habilitado para Azure Arc precisa que signInAudience seja definido como AzureADMyOrg:

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
    az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
    az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
    SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'
    
  4. Crie uma entidade de serviço e obtenha seu valor de campo password. Esse valor será necessário posteriormente, como serverApplicationSecret quando você estiver habilitando esse recurso no cluster. Esse segredo tem validade padrão de um ano e precisará ser alterado depois disso. Para definir uma duração de expiração personalizada, use az ad sp credential reset:

    az ad sp create --id "${SERVER_APP_ID}"
    SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv) 
    
  5. Conceda as permissões de API “Entrar e ler o perfil de usuário” ao aplicativo ao usar az ad app permission:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
    az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read
    

    Observação

    Um administrador de aplicativo do Azure precisa executar esta etapa.

    Para usar esse recurso em produção, recomendamos criar um aplicativo de servidor diferente para cada cluster.

Criar um aplicativo cliente

  1. Crie um novo aplicativo do Microsoft Entra e obtenha seu valor appId. Esse valor será usado em etapas posteriores como clientApplicationId.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
    CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
    echo $CLIENT_APP_ID 
    
  2. Crie uma entidade de serviço para o aplicativo cliente:

    az ad sp create --id "${CLIENT_APP_ID}"
    
  3. Obtenha o valor oAuthPermissionId para o aplicativo de servidor:

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv
    
  4. Conceda as permissões necessárias para o aplicativo cliente. O RBAC para Kubernetes habilitado para Azure Arc precisa que signInAudience seja definido como AzureADMyOrg:

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
        RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
        az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
        az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
        CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
        az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'
    

Criar uma atribuição de função para o aplicativo de servidor

O aplicativo de servidor precisa das permissões Microsoft.Authorization/*/read para que possa confirmar se o usuário que está fazendo a solicitação está autorizado nos objetos do Kubernetes que fazem parte da solicitação.

  1. Crie um arquivo chamado accessCheck.json com os seguintes conteúdos:

    {
    "Name": "Read authorization",
    "IsCustom": true,
    "Description": "Read authorization",
    "Actions": ["Microsoft.Authorization/*/read"],
    "NotActions": [],
    "DataActions": [],
    "NotDataActions": [],
    "AssignableScopes": [
      "/subscriptions/<subscription-id>"
      ]
    }
    

    Substitua <subscription-id> pela ID da assinatura real.

  2. Execute o seguinte comando para criar a nova função personalizada:

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)
    
  3. Crie uma atribuição de função no aplicativo de servidor como assignee usando a função que você criou:

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>
    

Habilitar o RBAC do Azure no cluster

Habilite o RBAC (controle de acesso baseado em função) do Azure no cluster de Kubernetes habilitado para Azure Arc executando o seguinte comando:

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Observação

Antes de executar o comando anterior, verifique se o arquivo kubeconfig no computador está apontando para o cluster em que o recurso de RBAC do Azure será habilitado.

Use --skip-azure-rbac-list com o comando anterior para uma lista separada por vírgulas de nomes de usuário, emails e conexões OpenID que passam por verificações de autorização usando objetos ClusterRoleBinding e RoleBinding nativos do Kubernetes em vez do RBAC do Azure.

Cluster genérico em que nenhum reconciliador está em execução na especificação apiserver

  1. Use o SSH em cada nó mestre do cluster e siga estas etapas:

    Se o kube-apiserver for um pod estático:

    1. O segredo azure-arc-guard-manifests no namespace kube-system contém dois arquivos guard-authn-webhook.yaml e guard-authz-webhook.yaml. Copie esses arquivos para o diretório /etc/guard do nó.

      sudo mkdir -p /etc/guard
      kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
      kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml
      
    2. Abra o manifesto apiserver no modo de edição:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      
    3. Adicione a seguinte especificação em volumes:

      - name: azure-rbac
          hostPath:
          path: /etc/guard
          type: Directory
      
    4. Adicione a seguinte especificação em volumeMounts:

      - mountPath: /etc/guard
          name: azure-rbac
          readOnly: true
      

    Se o kube-apiserver não for um pod estático:

    1. Abra o manifesto apiserver no modo de edição:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      
    2. Adicione a seguinte especificação em volumes:

      - name: azure-rbac
          secret:
          secretName: azure-arc-guard-manifests
      
    3. Adicione a seguinte especificação em volumeMounts:

      - mountPath: /etc/guard
          name: azure-rbac
          readOnly: true
      
  2. Adicione os seguintes argumentos apiserver:

    - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
    - --authentication-token-webhook-cache-ttl=5m0s
    - --authorization-webhook-cache-authorized-ttl=5m0s
    - --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
    - --authorization-webhook-version=v1
    - --authorization-mode=Node,RBAC,Webhook
    

    Se o cluster do Kubernetes for a versão 1.19.0 ou posterior, você também precisará definir o seguinte argumento apiserver:

    - --authentication-token-webhook-version=v1
    
  3. Salve e feche o editor para atualizar o pod apiserver.

Cluster criado usando a API de cluster

  1. Copie o segredo de proteção que contém arquivos de configuração de webhook de autenticação e autorização do cluster de carga de trabalho em seu computador:

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
    
  2. Altere o campo namespace no arquivo azure-arc-guard-manifests.yaml para o namespace no cluster de gerenciamento em que você está aplicando os recursos personalizados para a criação de clusters de carga de trabalho.

  3. Aplique este manifesto:

    kubectl apply -f azure-arc-guard-manifests.yaml
    
  4. Edite o objeto KubeadmControlPlane executando kubectl edit kcp <clustername>-control-plane:

    1. Adicione este snippet ao files:

      - contentFrom:
          secret:
            key: guard-authn-webhook.yaml
            name: azure-arc-guard-manifests
        owner: root:root
        path: /etc/kubernetes/guard-authn-webhook.yaml
        permissions: "0644"
      - contentFrom:
          secret:
            key: guard-authz-webhook.yaml
            name: azure-arc-guard-manifests
        owner: root:root
        path: /etc/kubernetes/guard-authz-webhook.yaml
        permissions: "0644"
      
    2. Adicione este snippet ao apiServer>extraVolumes:

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
          mountPath: /etc/guard/guard-authn-webhook.yaml
          name: guard-authn
          readOnly: true
      - hostPath: /etc/kubernetes/guard-authz-webhook.yaml
          mountPath: /etc/guard/guard-authz-webhook.yaml
          name: guard-authz
          readOnly: true
      
    3. Adicione este snippet ao apiServer>extraArgs:

      authentication-token-webhook-cache-ttl: 5m0s
      authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
      authentication-token-webhook-version: v1
      authorization-mode: Node,RBAC,Webhook
      authorization-webhook-cache-authorized-ttl: 5m0s
      authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
      authorization-webhook-version: v1
      
    4. Salve e feche para atualizar o objeto KubeadmControlPlane. Aguarde até que essas alterações apareçam no cluster de carga de trabalho.

Criar atribuições de função para usuários acessarem o cluster

Os proprietários do recurso de Kubernetes habilitado para Azure Arc podem usar funções internas ou funções personalizadas para permitir a outros usuários acesso ao cluster de Kubernetes.

Funções internas

Função Descrição
Visualizador do Kubernetes do Azure Arc Permite acesso somente leitura para ver a maioria dos objetos em um namespace. Essa função não permite a exibição de segredos porque a permissão read nos segredos permitiria o acesso às credenciais ServiceAccount no namespace. Essas credenciais, por sua vez, permitirão o acesso à API por meio desse valor ServiceAccount (uma forma de elevação de privilégio).
Gravador do Kubernetes do Azure Arc Permite acesso de leitura/gravação à maioria dos objetos em um namespace. Essa função não permite exibir ou modificar funções ou associações de função. No entanto, essa função permite acessar segredos e executar pods como qualquer valor ServiceAccount no namespace, de modo que ela pode ser usada para obter os níveis de acesso de API de qualquer ServiceAccount no namespace.
Administrador do Kubernetes do Azure Arc Permite o acesso de administrador. Destinado a ser concedido em um namespace por meio de RoleBinding. Se usado em RoleBinding, permitirá acesso de leitura/gravação para a maioria dos recursos em um namespace, incluindo a capacidade de criar funções e associações de função no namespace. Essa função não permite acesso de gravação à cota de recursos ou ao próprio namespace.
Administrador do Cluster do Kubernetes do Azure Arc Permite o acesso de superusuário para executar ações em qualquer recurso. Quando você o utiliza no ClusterRoleBinding, ele fornece controle total sobre cada recurso no cluster e em todos os namespaces. Quando você o utiliza em RoleBinding, ele dá controle total sobre cada recurso no namespace da associação de função, incluindo o próprio namespace.

Você pode criar atribuições de função com escopo para o cluster de Kubernetes habilitado para Azure Arc no portal do Azure, no painel Controle de acesso (IAM) do recurso de cluster. Você também pode usar os comandos a seguir da CLI do Azure:

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

Nesses comandos, AZURE-AD-ENTITY-ID pode ser um nome de usuário (por exemplo, testuser@mytenant.onmicrosoft.com) ou até o valor appId de uma entidade de serviço.

Veja outro exemplo de criação de uma atribuição de função com escopo para um namespace específico dentro do cluster:

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Observação

Você pode criar atribuições de função com escopo para o cluster usando o portal do Azure ou a CLI do Azure. No entanto, somente a CLI do Azure pode ser usada para criar atribuições de função com escopo para namespaces.

Funções personalizadas

Você pode optar por criar sua própria definição de função para uso em atribuições de função.

Veja o exemplo a seguir de definição de função que permite que um usuário leia somente implantações. Para saber mais, confira a lista completa de ações de dados que você pode usar para criar uma definição de função.

Copie o objeto JSON a seguir para um arquivo chamado custom-role.json. Substitua o espaço reservado <subscription-id> pela ID da assinatura real. A função personalizada usa uma das ações de dados e permite exibir todas as implantações no escopo (cluster ou namespace) em que a atribuição de função é criada.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}
  1. Crie a definição de função executando o comando abaixo da pasta em que você salvou custom-role.json:

    az role definition create --role-definition @custom-role.json
    
  2. Crie uma atribuição de função usando esta definição de função personalizada:

    az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
    

Configurar o kubectl com as credenciais do usuário

Há duas maneiras de obter o arquivo kubeconfig de que você precisa para acessar o cluster:

  • Use o recurso Cluster Connect (az connectedk8s proxy) do cluster do Kubernetes habilitado para o Azure Arc.
  • O administrador do cluster compartilha o arquivo kubeconfig com todos os outros usuários.

Usar Cluster Connect

Execute o comando a seguir para iniciar o processo de proxy:

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

Depois que o processo de proxy estiver em execução, você poderá abrir outra guia no console para começar a enviar suas solicitações ao cluster.

Usar um arquivo kubeconfig compartilhado

O uso de um kubeconfig compartilhado requer etapas ligeiramente diferentes, dependendo da sua versão do Kubernetes.

  1. Execute o seguinte comando para definir as credenciais para o usuário:

    kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
    --auth-provider=azure \
    --auth-provider-arg=environment=AzurePublicCloud \
    --auth-provider-arg=client-id=<clientApplicationId> \
    --auth-provider-arg=tenant-id=<tenantId> \
    --auth-provider-arg=apiserver-id=<serverApplicationId>
    
  2. Abra o arquivo kubeconfig que você criou anteriormente. Em contexts, verifique o contexto associado a pontos de cluster para as credenciais de usuário criadas na etapa anterior. Para definir o contexto atual para essas credenciais de usuário, execute o seguinte comando:

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
    
  3. Adicione a configuração config-mode em user>config:

    name: testuser@mytenant.onmicrosoft.com
    user:
        auth-provider:
        config:
            apiserver-id: $SERVER_APP_ID
            client-id: $CLIENT_APP_ID
            environment: AzurePublicCloud
            tenant-id: $TENANT_ID
            config-mode: "1"
        name: azure
    

Observação

O plug-in exec é uma estratégia de autenticação do Kubernetes que permite que kubectl execute um comando externo para receber credenciais do usuário a serem enviadas a apiserver. A partir do Kubernetes versão 1.26, o plug-in de autorização padrão do Azure não está mais incluído em client-go e kubectl. Com versões posteriores, para usar o plug-in exec para receber credenciais de usuário, você deve usar o Azure Kubelogin, um plug-in de credencial (exec) de client-go que implementa a autenticação do Azure.

  1. Instalar o Azure Kubelogin:

    • Para Windows ou Mac, siga as instruções de instalação do Azure Kubelogin.

    • Para Linux ou Ubuntu, baixe a versão mais recente do kubelogin e execute os seguinte comandos:

      curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 
      
      unzip kubelogin-linux-amd64.zip 
      
      sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 
      
      sudo chmod +x /usr/local/bin/kubelogin 
      
  2. Converter o kubelogin para usar o modo de logon apropriado. Por exemplo, para logon de código do dispositivo com um usuário do Microsoft Entra, os comandos seriam os seguintes:

    export KUBECONFIG=/path/to/kubeconfig
    
    kubelogin convert-kubeconfig
    

Enviar solicitações ao cluster

  1. Execute qualquer comando kubectl. Por exemplo:

    • kubectl get nodes
    • kubectl get pods
  2. Uma vez solicitada uma autenticação baseada em navegador, copie a URL de logon do dispositivo (https://microsoft.com/devicelogin) e abra-a no navegador da Web.

  3. Insira o código impresso no console. Copie e copie o código em seu terminal no prompt de entrada de autenticação do dispositivo.

  4. Insira o nome de usuário (testuser@mytenant.onmicrosoft.com) e a senha associada.

  5. Se uma mensagem de erro como esta for exibida, você não terá autorização para acessar o recurso solicitado:

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.
    

    Um administrador precisa criar uma nova atribuição de função que autoriza esse usuário a ter acesso ao recurso.

Usar o acesso condicional com o Microsoft Entra ID

Ao integrar o Microsoft Entra ID ao cluster do Kubernetes habilitado para Azure Arc, use também o acesso condicional para controlar o acesso ao cluster.

Observação

O Acesso Condicional do Microsoft Entra é uma funcionalidade do Microsoft Entra ID P2.

Para criar um exemplo de política de acesso condicional para usar com o cluster:

  1. Na parte superior do portal do Azure, pesquise e selecione Microsoft Entra ID.

  2. No menu do Microsoft Entra ID no lado esquerdo, selecione Aplicativos empresariais.

  3. No menu de aplicativos empresariais no lado esquerdo, selecione Acesso condicional.

  4. No menu de Acesso condicional no lado esquerdo, selecione Políticas>Nova política.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Insira um nome para a política, como arc-k8s-policy.

  6. Selecione Usuários e grupos. Em Incluir, escolha Selecionar usuários e grupos. Em seguida, escolha os usuários e grupos nos quais deseja aplicar a política. Para este exemplo, escolha o mesmo grupo do Microsoft Entra que tem acesso administrativo ao seu cluster.

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. Selecione Aplicativos na nuvem ou ações. Em Incluir, clique em Selecionar aplicativos. Em seguida, pesquise e selecione o aplicativo de servidor que você criou anteriormente.

    Screenshot showing how to select a server application in the Azure portal.

  8. Em Controles de acesso, selecione Conceder. Selecione Conceder acesso>Exigir que o dispositivo seja marcado como compatível.

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. Em Habilitar política, selecione Ativar>Criar.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

Acesse o cluster novamente. Por exemplo, execute o comando kubectl get nodes para exibir os nós no cluster:

kubectl get nodes

Siga as instruções para entrar novamente. Uma mensagem de erro informa que você foi conectado com êxito, mas seu administrador exige que o dispositivo que solicita acesso seja gerenciado pelo Microsoft Entra ID para acessar o recurso. Siga estas etapas:

  1. No portal do Azure, acesse Microsoft Entra ID.

  2. Selecione Aplicativos empresariais. Em seguida, em Atividade, selecione Entradas.

  3. Uma entrada na parte superior mostra Falha para Status e Êxito para Acesso condicional. Selecione a entrada e escolha Acesso condicional em Detalhes. Observe que sua política de Acesso condicional está listada.

    Screenshot showing a failed sign-in entry in the Azure portal.

Configurar o acesso do cluster just-in-time com o Microsoft Entra ID

Outra opção de controle de acesso ao cluster é usar o PIM (Privileged Identity Management) para solicitações Just-In-Time.

Observação

Microsoft Entra ID PIM é uma funcionalidade do Microsoft Entra ID P2. Para obter mais informações sobre SKUs do Microsoft Entra ID, confira o guia de preços.

Para configurar solicitações de acesso just-in-time para o cluster, conclua as seguintes etapas:

  1. Na parte superior do portal do Azure, pesquise e selecione Microsoft Entra ID.

  2. Anote a ID de locatário. Para o restante dessas instruções, vamos nos referir a essa ID como <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. No menu do Microsoft Entra ID no lado esquerdo, em Gerenciar, selecione Grupos>Novo grupo.

  4. Verifique se a Segurança está selecionada para o Tipo de grupo. Insira um nome de grupo, como myJITGroup. Em Funções do Microsoft Entra podem ser atribuídas a este grupo (versão prévia), selecione Sim. Por fim, selecione Criar.

    Screenshot showing details for the new group in the Azure portal.

  5. Você é levado de volta à página Grupos. Selecione o grupo criado recentemente e anote a ID de objeto. Para o restante dessas instruções, vamos nos referir a essa ID como <object-id>.

    Screenshot showing the object ID for the new group in the Azure portal.

  6. De volta ao portal do Azure, no menu de atividade no lado esquerdo, selecione Acesso privilegiado (versão prévia). Em seguida, selecione Habilitar acesso privilegiado.

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. Selecione Adicionar atribuições para começar a conceder acesso.

    Screenshot showing how to add active assignments in the Azure portal.

  8. Selecione uma função de Membro e selecione os usuários e grupos aos quais deseja conceder acesso ao cluster. Um administrador de grupo pode modificar essas atribuições a qualquer momento. Selecione Avançar quando estiver pronto para continuar.

    Screenshot showing how to add assignments in the Azure portal.

  9. Escolha o tipo de atribuição Ativo, escolha a duração desejada e forneça uma justificativa. Quando estiver pronto para continuar, selecione Atribuir. Para saber mais sobre os tipos de atribuição, confira Atribuir qualificação para um grupo de acesso privilegiado (versão prévia) no Privileged Identity Management.

    Screenshot showing assignment properties in the Azure portal.

Após as atribuições serem feitas, verifique se o acesso just-in-time está funcionando acessando o cluster. Por exemplo, use o comando kubectl get nodes para exibir os nós no cluster:

kubectl get nodes

Observe o requisito de autenticação e siga as etapas para autenticar. Se a autenticação for bem-sucedida, será exibida uma saída semelhante a esta:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

Atualizar o segredo do aplicativo de servidor

Se o segredo da entidade de serviço do aplicativo de servidor tiver expirado, você precisará girá-lo.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Atualize o segredo no cluster. Inclua todos os parâmetros opcionais configurados quando o comando foi executado originalmente.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Próximas etapas