Compartilhar via

Usar o RBAC do Azure para clusters de Kubernetes habilitados para Azure Arc

  • Artigo

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.

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

O RBAC do Azure não está disponível para Red Hat OpenShift ou ofertas de Kubernetes gerenciadas onde o acesso do usuário ao servidor API é restrito (por exemplo: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)).

O RBAC do Azure atualmente não suporta clusters Kubernetes que operam na arquitetura ARM64. Use o RBAC do Kubernetes para gerenciar o controle de acesso para clusters Kubernetes baseados em ARM64.

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.

Habilitar o RBAC do Azure no cluster

  1. Obtenha a identidade MSI do cluster executando o seguinte comando:

    az connectedk8s show -g <resource-group> -n <connected-cluster-name>

  2. Obtenha o ID (identity.principalId) da saída e execute o seguinte comando para atribuir a função Leitor de Verificação de Identidade Gerenciada de Cluster Conectado à MSI do cluster:

    az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>

  3. 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

    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:

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

    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. Especifique serverApplicationId como 6256c85f-0aad-4d50-b960-e6e9b21efe35 e clientApplicationId como 3f4439ff-e698-4d6d-84fe-09c9d574f06b:

    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.

  4. 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

  5. O Kubelogin pode ser usado para autenticar com clusters habilitados para Azure Arc, solicitando um token de prova de posse (PoP). Converter o kubeconfig usando 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 --pop-enabled --pop-claims 'u=<ARM ID of cluster>"

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.

    Captura de tela mostrando como adicionar uma política de acesso condicional no portal do Azure.

  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.

    Captura de tela que mostra a seleção de usuários ou grupos para aplicar a política de acesso condicional.

  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.

    Captura de tela mostrando como selecionar um aplicativo de servidor no portal do Azure.

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

    Captura de tela mostrando como permitir apenas dispositivos compatíveis no portal do Azure.

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

    Captura de tela mostrando como habilitar uma política de acesso condicional no portal do Azure.

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.

    Captura de tela mostrando uma entrada com falha no portal do Azure.

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>.

    Captura de tela mostrando os detalhes do Microsoft Entra ID no portal do Azure.

  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.

    Captura de tela mostrando detalhes do novo grupo no portal do Azure.

  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>.

    Captura de tela mostrando a ID do objeto do novo grupo no portal do Azure.

  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.

    Captura de tela mostrando seleções para habilitar o acesso privilegiado no portal do Azure.

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

    Captura de tela mostrando como adicionar atribuições ativas no portal do Azure.

  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.

    Captura de tela mostrando como adicionar atribuições no portal do Azure.

  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.

    Captura de tela mostrando as propriedades de atribuição no portal do Azure.

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

Próximas etapas