Compartilhar via

Usar o logon único do Active Directory para conexão segura com o servidor de API do Kubernetes no AKS habilitado pelo Azure Arc

  • Artigo

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Você pode criar uma conexão segura com o servidor de API do Kubernetes no AKS habilitado pelo Arc usando credenciais de logon único (SSO) do Active Directory (AD).

Visão geral do AD no AKS habilitado pelo Arc

Sem a autenticação do Active Directory, você deve contar com um arquivo kubeconfig baseado em certificado ao se conectar ao servidor de API por meio do kubectl comando. O arquivo kubeconfig contém segredos, como chaves privadas e certificados, que precisam ser distribuídos com cuidado, o que pode ser um risco de segurança significativo.

Como alternativa ao uso do kubeconfig baseado em certificado, você pode usar as credenciais do AD SSO como uma maneira segura de se conectar ao servidor de API. A integração do AD com o AKS Arc permite que os usuários em um computador ingressado no domínio do Windows se conectem ao servidor de API usando kubectl suas credenciais de SSO. Isso elimina a necessidade de gerenciar e distribuir arquivos kubeconfig baseados em certificado que contêm chaves privadas.

A integração do AD usa o AD kubeconfig, que é diferente dos arquivos kubeconfig baseados em certificado e não contém nenhum segredo. No entanto, o arquivo kubeconfig baseado em certificado pode ser usado para fins de backup, como solução de problemas, se houver problemas com a conexão usando credenciais do Active Directory.

Outro benefício de segurança com a integração do AD é que os usuários e grupos são armazenados como identificadores de segurança (SIDs). Ao contrário dos nomes de grupo, os SIDs são imutáveis e exclusivos e, portanto, não apresentam conflitos de nomenclatura.

Observação

A conectividade do AD SSO só tem suporte para clusters de carga de trabalho.

Observação

Não há suporte para o uso de grupos aninhados do AD (criação de um grupo do AD dentro de outro grupo do AD).

Este artigo orienta você pelas etapas para configurar o Active Directory como o provedor de identidade e habilitar o SSO por meio de kubectl:

  • Crie a conta do AD para o servidor de API e, em seguida, crie o arquivo keytab associado à conta. Consulte Criar autenticação do AD usando o arquivo keytab para criar a conta do AD e gerar o arquivo keytab.
  • Use o arquivo keytab para instalar o AD Auth no cluster do Kubernetes. Como parte desta etapa, uma configuração padrão de controle de acesso baseado em função (RBAC) é criada automaticamente.
  • Converta nomes de grupo em SIDs e vice-versa ao criar ou editar configurações RBAC, consulte criar e atualizar a associação de função de grupo do AD para obter instruções.

Antes de começar

Antes de iniciar o processo de configuração das credenciais de SSO do Active Directory, você deve garantir que tenha os seguintes itens disponíveis:

  • O módulo Aks-Hci PowerShell mais recente está instalado. Se você precisar instalá-lo, consulte baixar e instalar o módulo AksHci PowerShell.

  • O host do AKS está instalado e configurado. Se você precisar instalar o host, siga as etapas para configurar sua implantação.

  • O arquivo keytab está disponível para uso. Se não estiver disponível, siga as etapas para criar a conta do AD do servidor de API e o arquivo keytab.

    Observação

    Você deve gerar o arquivo keytab para um SPN (nome da entidade de serviço) específico, e esse SPN deve corresponder à conta AD do servidor de API para o cluster de carga de trabalho. Você também deve garantir que o mesmo SPN seja usado em todo o processo de autenticação do AD. O arquivo keytab deve ser nomeado current.keytab.

  • Uma conta do AD do servidor de API está disponível para cada cluster de carga de trabalho do AKS.

  • O computador cliente deve ser um computador ingressado no domínio do Windows.

Criar AD Auth usando o arquivo keytab

Etapa 1: Criar o cluster de carga de trabalho e habilitar a autenticação do AD

Antes de instalar a autenticação do AD, você deve primeiro criar um cluster de carga de trabalho do AKS e habilitar o complemento de autenticação do AD no cluster. Se você não habilitar a autenticação do AD ao criar o novo cluster, não poderá habilitá-la posteriormente.

Abra o PowerShell como administrador e execute o seguinte usando o -enableADAuth New-AksHciCluster parâmetro do comando:

New-AksHciCluster -name mynewcluster1 -enableADAuth

Para cada cluster de carga de trabalho, verifique se há uma conta do AD do servidor de API disponível.

Para obter informações sobre como criar o cluster de carga de trabalho, consulte Criar clusters do Kubernetes usando o Windows PowerShell.

Etapa 2: instalar a autenticação do AD

Antes de instalar a autenticação do AD, o cluster de carga de trabalho deve ser instalado e a autenticação do AD habilitada no cluster. Para instalar a autenticação do AD, use uma das opções a seguir.

Opção 1

Para um cluster do Azure Stack HCI ou do Windows Server ingressado no domínio, abra o PowerShell como administrador e execute o seguinte comando:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Observação

Para SPN k8s/apiserver@CONTOSO.com, use o formato SPN k8s/apiserver@<realm name>. Na primeira tentativa, especifique <realm name> em letras maiúsculas. No entanto, se você tiver problemas com letras maiúsculas, crie o SPN com letras minúsculas. O Kerberos diferencia maiúsculas de minúsculas.

Opção 2

Se o host do cluster não estiver ingressado no domínio, use o nome de usuário administrador ou o nome do grupo no formato SID, conforme mostrado no exemplo a seguir.

Usuário administrador:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Grupo de administradores:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Para localizar o SID da conta de usuário, consulte Determinar o identificador de segurança do usuário ou do grupo.

Antes de prosseguir para as próximas etapas, anote os seguintes itens:

  • Certifique-se de que o arquivo keytab esteja nomeado current.keytab.
  • Substitua o SPN que corresponde ao seu ambiente.
  • O -adminGroup parâmetro cria uma associação de função correspondente para o grupo do AD especificado com privilégios de administrador de cluster. Substitua contoso\bob (conforme mostrado na Opção 1 acima) pelo grupo ou usuário do AD que corresponde ao seu ambiente.

Etapa 3: Testar o arquivo de webhook e keytab do AD

Verifique se o webhook do AD está em execução no servidor de API e se o arquivo keytab está armazenado como um segredo do Kubernetes. Para obter o arquivo kubeconfig baseado em certificado para o cluster de carga de trabalho, siga estas etapas:

  1. Obtenha um arquivo kubeconfig baseado em certificado usando o comando a seguir. Use o arquivo kubeconfig para se conectar ao cluster como um host local:

    Get-AksHciCredential -name mynewcluster1

  2. Execute kubectl no servidor ao qual você se conectou (usando o arquivo kubeconfig baseado em certificado que você criou anteriormente) e verifique a implantação do webhook do AD para garantir que ela esteja no formato ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Execute kubectl para verificar se o arquivo keytab está implantado como um segredo e está listado como um segredo do Kubernetes:

    kubectl get secrets -n=kube-system

Etapa 4: Criar o arquivo kubeconfig do AD

Depois que o webhook e o keytab do AD forem implantados com êxito, crie o arquivo kubeconfig do AD. Depois que o arquivo for criado, copie o arquivo kubeconfig do AD para a máquina cliente e use-o para autenticar no servidor de API. Ao contrário do arquivo kubeconfig baseado em certificado, o AD kubeconfig não é um segredo e é seguro copiar como texto sem formatação.

Abra o PowerShell como um administrador e execute o seguinte comando:

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Etapa 5: Copiar kubeconfig e outros arquivos para a máquina cliente

Você deve copiar os três arquivos a seguir do cluster de carga de trabalho do AKS para o computador cliente:

  • Copie o arquivo kubeconfig do AD criado na etapa anterior para $env:USERPROFILE.kube\config.

  • Crie o caminho da pasta c:\adsso e copie os seguintes arquivos do cluster de carga de trabalho do AKS para o computador cliente:

    • Kubectl.exe em $env:ProgramFiles\AksHci para c:\adsso.
    • Kubectl-adsso.exe em $env:ProgramFiles\AksHci para c:\adsso.

    Observação

    O arquivo adsso.exe é gerado no servidor quando você executa o Get-AksHciCredential cmdlet.

Etapa 6: Conectar-se ao servidor de API a partir do computador cliente

Depois de concluir as etapas anteriores, use suas credenciais de SSO para entrar no computador cliente ingressado no domínio do Windows. Abra o PowerShell e tente acessar o servidor de API usando kubectlo . Se a operação for concluída com êxito, você configurará o SSO do AD corretamente.

Criar e atualizar a associação de função do grupo do AD

Conforme mencionado na Etapa 2, uma associação de função padrão com privilégios de administrador de cluster é criada para o usuário e/ou o grupo que foi fornecido durante a instalação. A vinculação de funções no Kubernetes define as políticas de acesso para grupos do AD. Esta etapa descreve como usar o RBAC para criar novas associações de função de grupo do AD no Kubernetes e editar associações de função existentes. Por exemplo, o administrador do cluster pode querer conceder privilégios adicionais aos usuários usando grupos do AD (o que torna o processo mais eficiente). Para obter mais informações sobre o RBAC, consulte usando a autorização RBAC.

Quando você cria ou edita outras entradas RBAC do grupo do AD, o nome da entidade deve ter o prefixo de nome microsoft:activedirectory:CONTOSO\group. Observe que os nomes devem conter um nome de domínio e um prefixo entre aspas duplas.

Veja dois exemplos:

Exemplo 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Exemplo 2

O exemplo a seguir mostra como criar uma função personalizada e uma associação de função para um namespace com um grupo do AD. No exemplo, SREGroup é um grupo pré-existente no Active Directory da Contoso. Quando os usuários são adicionados ao grupo do AD, eles recebem privilégios imediatamente.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Antes de aplicar o arquivo YAML, os nomes de grupo e usuário devem sempre ser convertidos em SIDs usando o comando:

kubectl-adsso nametosid <rbac.yml>

Da mesma forma, para atualizar um RBAC existente, você pode converter o SID em um nome de grupo amigável antes de fazer alterações. Para converter o SID, use o comando:

kubectl-adsso sidtoname <rbac.yml>

Alterar a senha da conta do AD associada à conta do servidor de API

Quando a senha da conta do servidor de API é alterada, você deve desinstalar o complemento de autenticação do AD e reinstalá-lo usando as guias de teclas atuais e anteriores atualizadas.

Toda vez que você alterar a senha, deverá renomear o keytab atual (current.keytab) para previous.keytab. Em seguida, certifique-se de nomear a nova senha current.keytab.

Importante

Os arquivos devem ser nomeados current.keytab e previous.keytab, respectivamente. As associações de função existentes não são afetadas por essa alteração.

Desinstalar e reinstalar a autenticação do AD

Talvez você queira reinstalar o AD SSO quando a conta do servidor de API for alterada, quando a senha for atualizada ou para solucionar uma falha.

Para desinstalar a autenticação do AD, abra o PowerShell como administrador e execute o seguinte comando:

Uninstall-AksHciAdAuth -name mynewcluster1

Para reinstalar a autenticação do AD, abra o PowerShell como administrador e execute o seguinte comando:

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Observação

Para evitar tempo de inatividade se os clientes tiverem tíquetes armazenados em cache, o -previousKeytab parâmetro será necessário somente quando você alterar a senha.

Crie a conta do AD do servidor de API e o arquivo keytab

Duas etapas estão envolvidas na criação da conta do AD e do arquivo keytab. Primeiro, crie uma nova conta/usuário do AD para o servidor de API com o SPN (nome da entidade de serviço) e, segundo, crie um arquivo keytab para a conta do AD.

Etapa 1: criar uma nova conta ou usuário do AD para o servidor de API

Use o comando New-ADUser do PowerShell para criar uma nova conta/usuário do AD com o SPN. Veja um exemplo:

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Etapa 2: criar o arquivo keytab para a conta do AD

Para criar o arquivo keytab, use o comando ktpass do Windows.

Aqui está um exemplo usando ktpass:

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Observação

Se você vir o erro DsCrackNames retornado 0x2 na entrada de nome, certifique-se de que o parâmetro para /mapuser está em form mapuser DOMAIN\user, onde DOMAIN é a saída de echo %userdomain%.

Determinar o identificador de segurança do usuário ou do grupo

Use uma das duas opções a seguir para encontrar o SID da sua conta ou de outras contas:

  • Para localizar o SID associado à sua conta, em um prompt de comando do seu diretório base, digite o seguinte comando:

    whoami /user

  • Para localizar o SID associado a outra conta, abra o PowerShell como administrador e execute o seguinte comando:

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Solucionar problemas de certificados

O webhook e o servidor de API usam certificados para validar mutuamente a conexão TLS. Este certificado expira em 500 dias. Para verificar se o certificado expirou, exiba os logs de um ad-auth-webhook contêiner:

kubectl logs ad-auth-webhook-xxx

Se você vir erros de validação de certificado, conclua as etapas para desinstalar e reinstalar o webhook e obter novos certificados.

Práticas recomendadas e limpeza

  • Use uma conta exclusiva para cada cluster.
  • Não reutilize a senha da conta do servidor de API entre clusters.
  • Exclua a cópia local do arquivo keytab assim que criar o cluster e verifique se as credenciais de SSO funcionam.
  • Exclua o usuário do Active Directory que foi criado para o servidor de API. Para obter mais informações, consulte Remove-ADUser.

Próximas etapas

Neste guia de instruções, você aprendeu a configurar a Autenticação do AD para se conectar com segurança ao servidor de API com credenciais de SSO. Em seguida, você pode: