Partilhar via

Usar o logon único do Ative 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 seu servidor de API do Kubernetes no AKS habilitado pelo Arc usando credenciais de logon único (SSO) do Ative Directory (AD).

Visão geral do AD no AKS habilitado pelo Arc

Sem a autenticação do Ative Directory, você deve confiar em um arquivo kubeconfig baseado em certificado quando 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 cuidadosamente distribuídos, 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 uma máquina associada ao 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 é distinto dos arquivos kubeconfig baseados em certificado e não contém segredos. 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 Ative 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 únicos e, portanto, não apresentam conflitos de nomenclatura.

Nota

A conectividade AD SSO só é suportada para clusters de carga de trabalho.

Nota

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

Este artigo orienta você pelas etapas para configurar o Ative 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.
  • Converter nomes de grupo em SIDs e vice-versa ao criar ou editar configurações RBAC, consulte Criar e atualizar a vinculaçã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 Ative 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 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.

    Nota

    Você deve gerar o arquivo keytab para um SPN (nome da entidade de serviço) específico, e esse SPN deve corresponder à conta do 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 chamado current.keytab.

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

  • A máquina cliente deve ser uma máquina associada a um domínio do Windows.

Criar autenticação do AD 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 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 mais tarde.

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 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 seguintes opções.

Opção 1

Para um cluster do Azure Stack HCI ou Windows Server associado a um 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

Nota

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. Kerberos diferencia maiúsculas de minúsculas.

Opção 2

Se o host do cluster não estiver associado ao domínio, use o nome de usuário ou o nome do grupo admin 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 de usuário ou grupo.

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

  • Verifique se o arquivo keytab é chamado 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 webhook do AD e o arquivo keytab

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, em seguida, verifique a implantação do webhook do AD para certificar-se de que está 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 administrador e execute o seguinte comando:

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

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

Você deve copiar os três arquivos a seguir do cluster de carga de trabalho AKS para sua máquina 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 AKS para sua máquina cliente:

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

    Nota

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

Etapa 6: Conectar-se ao servidor de API a partir da máquina cliente

Depois de concluir as etapas anteriores, use suas credenciais de SSO para entrar na máquina cliente associada ao 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, configure o AD SSO corretamente.

Criar e atualizar a vinculação de função de 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ção 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 RBAC, consulte Usando a autorização RBAC.

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

Veja a seguir 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 Ative Directory da Contoso. Quando os usuários são adicionados ao grupo AD, eles recebem imediatamente privilégios.

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 é alterada para a conta do servidor de API, você deve desinstalar o complemento de autenticação do AD e reinstalá-lo usando as guias de tecla atuais e anteriores atualizadas.

Toda vez que você alterar a senha, você deve 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 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

Nota

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.

Criar 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, em segundo lugar, 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 PowerShell para criar uma nova conta/usuário do AD com o SPN. Eis 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 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

Nota

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

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

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

  • Para encontrar 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.

Melhores práticas e limpeza

  • Use uma conta exclusiva para cada cluster.
  • Não reutilize a senha da conta do servidor de API em 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 Ative Directory que foi criado para o servidor de API. Para obter mais informações, consulte Remove-ADUser.

Próximos passos

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