Usar o RBAC do Azure em clusters Kubernetes habilitados para Azure Arc (visualização)

Artigo
10/24/2023

Os tipos de objeto Kubernetes ClusterRoleBinding e RoleBinding ajudam a definir a autorização no Kubernetes nativamente. Usando esse recurso, você pode usar a ID do Microsoft Entra 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 controlar granularmente 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, consulte Azure RBAC no Kubernetes habilitado para Azure Arc.

Importante

Os recursos de visualização do Kubernetes habilitados para o Azure Arc estão disponíveis em uma base de autoatendimento e aceitação. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações 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 versão mais recente.
Instale a versão mais recente da extensão CLI do connectedk8s Azure:
```
az extension add --name connectedk8s
```
Se a connectedk8s extensão já estiver instalada, você poderá atualizá-la para a versão mais recente usando o seguinte comando:
```
az extension update --name connectedk8s
```
Ligue um cluster do Kubernetes compatível com o Azure Arc:
- Se ainda não associou um cluster, utilize o nosso início rápido.
- Atualize seus agentes para a versão mais recente.

Nota

Não é possível configurar esse recurso para o Red Hat OpenShift ou para ofertas gerenciadas do Kubernetes 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. Para clusters do Serviço Kubernetes do Azure (AKS), esse recurso está disponível nativamente e não exige que o cluster AKS esteja conectado ao Azure Arc.

Criar um aplicativo de servidor

Crie um novo aplicativo Microsoft Entra e obtenha seu appId valor. Esse valor é 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

Para conceder permissões de API "Entrar e ler perfil de usuário" para o 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"
        }
    ]
}

Atualize as declarações de associação de grupo do aplicativo. Execute os comandos no mesmo diretório que o oauth2-permissions.json arquivo. O RBAC para Kubernetes habilitado para Azure Arc precisa ser definido como AzureADMyOrg:signInAudience

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}}'

Crie uma entidade de serviço e obtenha seu password valor de campo. Esse valor é necessário posteriormente, como serverApplicationSecret quando você está habilitando esse recurso no cluster. Este segredo é válido por um ano por defeito e terá de ser alternado 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) 
```
Conceda permissões de API "Entrar e ler perfil de usuário" para o aplicativo usando 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
```
Nota

Um administrador de aplicativo do Azure precisa executar esta etapa.

Para uso desse recurso na produção, recomendamos que você crie um aplicativo de servidor diferente para cada cluster.

Criar um aplicativo cliente

Crie um novo aplicativo Microsoft Entra e obtenha seu appId valor. Esse valor é 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

Crie uma entidade de serviço para este aplicativo cliente:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

Obtenha o oAuthPermissionId valor para o aplicativo de servidor:

    az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

Conceda as permissões necessárias para o aplicativo cliente. O RBAC para Kubernetes habilitado para Azure Arc precisa ser definido como AzureADMyOrg:signInAudience

    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 um aplicativo de servidor

Crie um novo aplicativo Microsoft Entra e obtenha seu appId valor. Esse valor é 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

Atualize as declarações de associação de grupo do aplicativo:

az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All

Crie uma entidade de serviço e obtenha seu password valor de campo. Esse valor é necessário posteriormente, como serverApplicationSecret quando você está habilitando esse recurso no cluster. Este segredo é válido por um ano por defeito e terá de ser alternado 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 --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)
```
Conceda permissões de API "Entrar e ler perfil de usuário" para o aplicativo usando 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 
```
Nota

Um administrador de aplicativo do Azure precisa executar esta etapa.

Para uso desse recurso na produção, recomendamos que você crie um aplicativo de servidor diferente para cada cluster.

Criar um aplicativo cliente

Crie um novo aplicativo Microsoft Entra e obtenha seu appId valor. Esse valor é usado em etapas posteriores como clientApplicationId.

CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --native-app --reply-urls "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

Crie uma entidade de serviço para este aplicativo cliente:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

Obtenha o oAuthPermissionId valor para o aplicativo de servidor:

az ad app show --id "${SERVER_APP_ID}" --query "oauth2Permissions[0].id" -o tsv

Conceda as permissões necessárias para o aplicativo cliente:

az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
az ad app permission grant --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}"

Criar uma atribuição de função para a aplicação de servidor

O aplicativo de servidor precisa das Microsoft.Authorization/*/read permissões para que possa confirmar que o usuário que faz a solicitação está autorizado nos objetos Kubernetes incluídos na solicitação.

Crie um arquivo chamado accessCheck.json com o seguinte conteúdo:

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

Substitua <subscription-id> pelo ID de assinatura real.

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)

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>

Ativar o RBAC do Azure no cluster

Habilite o RBAC (controle de acesso baseado em função) do Azure em seu cluster 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}"

Nota

Antes de executar o comando anterior, verifique se o kubeconfig arquivo na máquina está apontando para o cluster no qual você habilitará o recurso RBAC do Azure.

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 e nativos do Kubernetes em ClusterRoleBindingRoleBinding vez do RBAC do Azure.

Cluster genérico onde nenhum reconciliador está sendo executado na `apiserver` especificação

SSH em cada nó mestre do cluster e execute as seguintes etapas:

Se o seu kube-apiserver é um pod estático:

O azure-arc-guard-manifests segredo no kube-system namespace contém dois arquivos: guard-authn-webhook.yaml e guard-authz-webhook.yaml. Copie esses arquivos para o /etc/guard diretório 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

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

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Adicione a seguinte especificação em volumes:

- name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

Adicione a seguinte especificação em volumeMounts:

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

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

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

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Adicione a seguinte especificação em volumes:

- name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

Adicione a seguinte especificação em volumeMounts:

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

Adicione os seguintes apiserver argumentos:

- --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 apiserver argumento:

- --authentication-token-webhook-version=v1

Salve e feche o editor para atualizar o apiserver pod.

Cluster criado usando a API de Cluster

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 para sua máquina:
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
Altere o namespace campo no arquivo azure-arc-guard-manifests.yaml para o namespace dentro do cluster de gerenciamento onde você está aplicando os recursos personalizados para a criação de clusters de carga de trabalho.

Aplique este manifesto:

kubectl apply -f azure-arc-guard-manifests.yaml

Edite o KubeadmControlPlane objeto executando kubectl edit kcp <clustername>-control-plane:

Adicione o seguinte trecho em 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"

Adicione o seguinte trecho em 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

Adicione o seguinte trecho em 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

Salve e feche para atualizar o KubeadmControlPlane objeto. Aguarde até que essas alterações apareçam no cluster de carga de trabalho.

Criar atribuições de funções para os utilizadores acederem ao cluster

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

Funções incorporadas

Função	Description
Azure Arc Kubernetes Viewer	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 `read` a permissão em segredos permitiria o acesso a `ServiceAccount` credenciais no namespace. Essas credenciais, por sua vez, permitiriam o acesso à API por meio desse `ServiceAccount` valor (uma forma de escalonamento de privilégios).
Azure Arc Kubernetes Writer	Permite acesso de leitura/gravação à maioria dos objetos em um namespace. Esta função não permite visualizar ou modificar funções ou associações de funções. No entanto, essa função permite acessar segredos e executar pods como qualquer `ServiceAccount` valor no namespace, para que possa ser usada para obter os níveis de acesso à API de qualquer `ServiceAccount` valor no namespace.
Azure Arc Kubernetes Admin	Permite acesso de administrador. Destina-se a ser concedido dentro de um namespace por meio `RoleBinding`do . Se você usá-lo no `RoleBinding`, ele permitirá acesso de leitura/gravação à maioria dos recursos em um namespace, incluindo a capacidade de criar funções e associações de função dentro do namespace. Essa função não permite acesso de gravação à cota de recursos ou ao namespace em si.
Azure Arc Kubernetes Cluster Admin	Permite o acesso de superusuário para executar qualquer ação em qualquer recurso. Quando você o usa no `ClusterRoleBinding`, ele dá controle total sobre todos os recursos no cluster e em todos os namespaces. Quando você o usa no `RoleBinding`, ele dá controle total sobre todos os recursos no namespace da associação de função, incluindo o namespace em si.

Você pode criar atribuições de função com escopo para o cluster 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 seguintes comandos 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é mesmo o appId valor de uma entidade de serviço.

Aqui está 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>

Nota

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.

Percorra o exemplo a seguir de uma definição de função que permite que um usuário leia apenas implantações. Para obter mais informações, consulte a lista completa de ações de dados que você pode usar para construir uma definição de função.

Copie o seguinte objeto JSON em um arquivo chamado custom-role.json. Substitua o espaço reservado <subscription-id> pela ID de 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) onde 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>"
    ]
}

Crie a definição de função executando o seguinte comando da pasta onde você salvou custom-role.json:
```
az role definition create --role-definition @custom-role.json
```

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 kubectl com credenciais de usuário

Há duas maneiras de obter o arquivo kubeconfig necessário para acessar o cluster:

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

Usar conexão de cluster

Execute o seguinte comando 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 para o cluster.

Usar um arquivo kubeconfig compartilhado

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

Versão do Kubernetes >= 1.26
Kubernetes < v1,26

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>

Abra o arquivo kubeconfig que você criou anteriormente. Em contexts, verifique se o contexto associado ao cluster aponta para as credenciais de usuário que você criou 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>
```

Adicione a configuração do modo de configuração 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

Nota

Exec plugin é uma estratégia de autenticação Kubernetes que permite kubectl executar um comando externo para receber credenciais de usuário para enviar para 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 no 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 client-go plug-in de credencial (exec) que implementa a autenticação do Azure.

Instale o Azure Kubelogin:

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

Para Linux ou Ubuntu, baixe a versão mais recente do kubelogin e execute os seguintes 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

Converta o kubelogin para usar o modo de login apropriado. Por exemplo, para login de código de dispositivo com um usuário do Microsoft Entra, os comandos seriam os seguintes:
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig
```

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>

Abra o arquivo kubeconfig que você criou anteriormente. Em contexts, verifique se o contexto associado ao cluster aponta para as credenciais de usuário que você criou 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>
```

Adicione a configuração do modo de configuração 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

Enviar solicitações para o cluster

Execute qualquer kubectl comando. Por exemplo:
- kubectl get nodes
- kubectl get pods
Depois que for solicitada a autenticação baseada em navegador, copie o URL de login do dispositivo (https://microsoft.com/devicelogin) e abra-o no navegador da Web.
Introduza o código impresso na consola. Copie e cole o código no seu terminal no prompt de entrada de autenticação do dispositivo.
Introduza o nome de utilizador (testuser@mytenant.onmicrosoft.com) e a palavra-passe associada.

Se vir uma mensagem de erro como esta, significa que não está autorizado a aceder ao 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 autorize esse usuário a ter acesso ao recurso.

Usar o Acesso Condicional com o ID do Microsoft Entra

Ao integrar a ID do Microsoft Entra com seu cluster Kubernetes habilitado para Azure Arc, você também pode usar o Acesso Condicional para controlar o acesso ao cluster.

Nota

O Acesso Condicional do Microsoft Entra é um recurso P2 do Microsoft Entra ID.

Para criar um exemplo de política de Acesso Condicional para usar com o cluster:

Na parte superior do portal do Azure, procure e selecione Microsoft Entra ID.
No menu do Microsoft Entra ID no lado esquerdo, selecione Aplicativos corporativos.
No menu para aplicações empresariais no lado esquerdo, selecione Acesso Condicional.
No menu Acesso Condicional, no lado esquerdo, selecione Políticas>Nova política.
Insira um nome para a política, como arc-k8s-policy.
Selecionar Utilizadores e grupos. Em Incluir, escolha Selecionar usuários e grupos. Em seguida, escolha os usuários e grupos onde deseja aplicar a política. Para este exemplo, escolha o mesmo grupo do Microsoft Entra que tem acesso administrativo ao cluster.
Selecione Aplicações na cloud ou ações. Em Incluir, escolha Selecionar aplicativos. Em seguida, procure e selecione o aplicativo de servidor que você criou anteriormente.
Em Controles de acesso, selecione Conceder. Selecione Conceder acesso Exigir que>o dispositivo seja marcado como compatível.
Em Ativar política, selecione Ao>criar.

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

kubectl get nodes

Siga as instruções para iniciar sessão novamente. Uma mensagem de erro indica que você está conectado com êxito, mas o administrador exige que o dispositivo que está solicitando acesso seja gerenciado pela ID do Microsoft Entra para acessar o recurso. Siga estes passos:

No portal do Azure, vá para Microsoft Entra ID.
Selecione Aplicações empresariais. Em seguida, em Atividade, selecione Entrar.
Uma entrada na parte superior mostra Falha para Status e Sucesso para Acesso Condicional. Selecione a entrada e, em seguida, selecione Acesso condicional em Detalhes. Observe que sua política de Acesso Condicional está listada.

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

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

Nota

O Microsoft Entra PIM é um recurso do Microsoft Entra ID P2. Para obter mais informações sobre as SKUs do Microsoft Entra ID, consulte o guia de preços.

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

Na parte superior do portal do Azure, procure e selecione Microsoft Entra ID.
Anote o ID do inquilino. Para o restante dessas instruções, nos referiremos a essa ID como <tenant-id>.
No menu do Microsoft Entra ID no lado esquerdo, em Gerenciar, selecione Novo grupo de grupos>.
Certifique-se de que Segurança está selecionada para Tipo de grupo. Insira um nome de grupo, como myJITGroup. Em Microsoft Entra funções podem ser atribuídas a este grupo (Pré-visualização), selecione Sim. Por fim, selecione Criar.
Você será levado de volta à página Grupos . Selecione o grupo recém-criado e anote o ID do objeto. Para o resto destas instruções, referir-nos-emos a este ID como <object-id>.
De volta ao portal do Azure, no menu Atividade do lado esquerdo, selecione Acesso privilegiado (visualização). Em seguida, selecione Ativar acesso privilegiado.
Selecione Adicionar atribuições para começar a conceder acesso.
Selecione uma função de Membro e selecione os usuários e grupos aos quais você deseja conceder acesso ao cluster. Um administrador de grupo pode modificar essas atribuições a qualquer momento. Quando estiver pronto para seguir em frente, selecione Avançar.
Escolha um tipo de atribuição de Ativo, escolha a duração desejada e forneça uma justificação. Quando estiver pronto para continuar, selecione Atribuir. Para obter mais informações sobre tipos de atribuição, consulte Atribuir elegibilidade para um grupo de acesso privilegiado (visualização) no Privileged Identity Management.

Depois de fazer as atribuições, verifique se o acesso just-in-time está funcionando acessando o cluster. Por exemplo, use o kubectl get nodes comando para exibir 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, você verá 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.

CLI >do Azure = v2.3.7
CLI < do Azure v2.3.7

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

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 quaisquer parâmetros opcionais configurados quando o comando foi originalmente executado.

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

Próximos passos

Conecte-se com segurança ao cluster usando o Cluster Connect.
Leia sobre a arquitetura do Azure RBAC no Kubernetes habilitado para Arc.

Usar o RBAC do Azure em clusters Kubernetes habilitados para Azure Arc (visualização)

Pré-requisitos

Configurar aplicações do Microsoft Entra

Criar um aplicativo de servidor

Criar um aplicativo cliente

Criar uma atribuição de função para a aplicação de servidor

Ativar o RBAC do Azure no cluster

Cluster genérico onde nenhum reconciliador está sendo executado na apiserver especificação

Cluster criado usando a API de Cluster

Criar atribuições de funções para os utilizadores acederem ao cluster

Funções incorporadas

Funções personalizadas

Configurar kubectl com credenciais de usuário

Usar conexão de cluster

Usar um arquivo kubeconfig compartilhado

Enviar solicitações para o cluster

Usar o Acesso Condicional com o ID do Microsoft Entra

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

Atualizar o segredo do aplicativo de servidor

Próximos passos

Recursos adicionais

Cluster genérico onde nenhum reconciliador está sendo executado na `apiserver` especificação