Use credenciais de inscrição únicas do Ative Directory para AKS em Azure Stack HCI

Aplica-se a: Azure Stack HCI, versões 21H2 e 20H2; Datacenter Windows Server 2022, Windows Server 2019 Datacenter

Sem autenticação ative Directory, os utilizadores devem confiar num ficheiro kubeconfig baseado em certificados quando se ligarem ao servidor API através do comando. O ficheiro Kubeconfig contém segredos como chaves e certificados privados que precisam de ser cuidadosamente distribuídos, o que pode ser um risco significativo para a segurança.

Como alternativa à utilização de kubeconfigbaseado em certificados, pode utilizar credenciais de assinatura única (SSO) do Ative Directory (AD) como forma segura de se ligar ao servidor API. A integração de AD com o Serviço Azure Kubernetes no Azure Stack HCI permite que um utilizador numa máquina Windows ligada ao domínio se conecte ao servidor API kubectl (via) utilizando as suas credenciais SSO. Isto elimina a necessidade de gerir e distribuir ficheiros kubeconfig baseados em certificados que contenham chaves privadas.

A integração de AD utiliza kubeconfigAD , que é diferente dos ficheiros kubeconfig baseados em certificados e não contém nenhum segredo. No entanto, o ficheiro kubeconfig baseado em certificados pode ser usado para fins de backup, como resolução de problemas, se houver problemas de ligação usando credenciais de Ative Directory.

Outro benefício de segurança com a integração da AD é que os utilizadores 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 nomeação.

Nota

Atualmente, a conectividade AD SSO é suportada apenas para clusters de carga de trabalho.

Este documento irá guiá-lo através das seguintes etapas para configurar o Ative Directory como fornecedor de identidade e para permitir o SSO através kubectl de:

  • Crie a conta AD para o servidor API e, em seguida, crie o ficheiro keytab associado à conta. Consulte criar AD Auth utilizando o ficheiro keytab para criar a conta AD e gerar o ficheiro keytab.
  • Utilize o ficheiro keytab para instalar a Ad Auth no cluster Kubernetes. Como parte deste passo, uma configuração de controlo de acesso baseada em funções padrão (RBAC) é criada automaticamente.
  • Converta os nomes de grupo em SIDs e vice-versa ao criar ou editar configurações de RBAC, consulte criar e atualizar a ligação da função de grupo AD para instruções.

Antes de começar

Antes de iniciar o processo de configuração das credenciais SSO do Ative Directory, deve certificar-se de que tem os seguintes itens disponíveis:

  • O mais recente módulo Aks-Hci PowerShell está instalado. Se precisar de o instalar, consulte o download e instale o módulo AksHci PowerShell.

  • O anfitrião AKS está instalado e configurado. Se precisar de instalar o anfitrião, siga os passos para configurar a sua implantação.

  • O ficheiro keytab está disponível para usar e, se não estiver disponível, siga os passos para criar a conta AD do servidor API e o ficheiro keytab.

    Nota

    Deve gerar o ficheiro keytab para um nome principal de serviço específico (SPN), e este SPN deve corresponder à conta AD do servidor API para o cluster de carga de trabalho. Deve também certificar-se de que o mesmo SPN é utilizado durante todo o processo de autenticação de AD. O ficheiro keytab deve ser nomeado current.keytab.

  • Uma conta AD do servidor API está disponível para cada AKS no cluster de carga HCI Azure Stack HCI.

  • A máquina cliente deve ser uma máquina Windows unida ao domínio.

Criar AD Auth usando o ficheiro keytab

Passo 1: Criar o cluster de carga de trabalho e permitir a autenticação de AD

Antes de instalar a autenticação AD, tem primeiro de criar um cluster de carga de carga AKS no Azure Stack HCI e ativar o complemento de autenticação AD no cluster. Se não ativar a autenticação AD quando criar o novo cluster, não poderá ative-lo mais tarde.

Open PowerShell como administrador e executar o seguinte utilizando o parâmetro -enabledAUth do comando:

New-AksHciCluster -name mynewcluster1 -enableADAuth

Para cada cluster de carga de trabalho, certifique-se de que existe uma conta AD do servidor API disponível.

Para obter detalhes sobre a criação do cluster de carga de trabalho, consulte criar clusters Kubernetes utilizando Windows PowerShell.

Passo 2: Instalar autenticação AD

Antes de poder instalar a autenticação AD, o cluster de carga de trabalho tem de ser instalado e a autenticação AD ativada no cluster. Para instalar a autenticação AD, utilize uma das seguintes opções.

Opção 1

Para um cluster Azure Stack HCI, 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 , utilizar o formato SPN k8s/apiserver@ nome do reino <> . Normalmente, < o nome do reino é > maiúscula, no entanto, se estiver com problemas, crie o SPN com letras minúsculas. Kerberos é sensível a casos.

Opção 2

Se o anfitrião do cluster não estiver associado ao domínio, utilize o nome de utilizador ou nome de grupo administrado no formato SID, como mostrado no exemplo abaixo:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8

Para encontrar o SID para a conta de utilizador, consulte o utilizador ou o identificador de segurança do grupo.

Antes de avançar para os próximos passos, deve observar os seguintes itens:

  • Certifique-se de que o ficheiro keytab está nomeado current.keytab.
  • Substitua o SPN que corresponde ao seu ambiente.
  • O parâmetro -adminUser cria uma ligação de função correspondente para o grupo AD especificado com privilégios de administração de cluster. Substitua contoso\bob (como mostrado na opção 1 acima) pelo grupo AD ou utilizador que corresponda ao seu ambiente.

Passo 3: Testar o webhook AD e o ficheiro keytab

Tem de se certificar de que o webhook da AD está a funcionar no servidor API e que o ficheiro keytab é armazenado como um segredo de Kubernetes. Para obter o ficheiro kubeconfig baseado em certificado para o cluster de carga de trabalho, siga estes passos:

  1. Obtenha um ficheiro kubeconfig baseado em certificado usando o seguinte comando. Você usará o ficheiro kubeconfig para se conectar ao cluster como um hospedeiro local.

    Get-AksHciCredential -name mynewcluster1
    
  2. Executar kubectl no servidor a que ligou (utilizando o ficheiro kubectl baseado em certificado que criou anteriormente) e, em seguida, verifique a implementação do webhook AD para se certificar de que está no formato ad-auth-webhook-xxxx.

    kubectl get pods -n=kube-system
    
  3. Corra kubectl para verificar se o ficheiro keytab é implementado como um segredo e está listado como um segredo de Kubernetes:

    kubectl get secrets -n=kube-system
    

Passo 4: Criar o ficheiro AD kubeconfig

Uma vez implementados com sucesso o webhook e o keytab da AD, crie o ficheiro AD kubeconfig. Após a criação do ficheiro, irá copiar o ficheiro AD kubeconfig para a máquina do cliente e usá-lo para autenticar no servidor API. Ao contrário do ficheiro kubeconfig baseado em certificado, o AD kubeconfig não é um segredo e é seguro copiar como texto simples.

Abra o PowerShell como administrador e execute o seguinte comando:

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

Passo 5: Copiar kubeconfig e outros ficheiros para a máquina do cliente

Deverá copiar os três ficheiros listados abaixo do cluster HCI Azure Stack para a sua máquina cliente:

  • Copie o ficheiro AD kubeconfig criado no passo anterior para $env:USERPROFILE.kube\config.

  • Crie o caminho da pasta c:\adsso e copie os seguintes ficheiros do cluster HCI Azure Stack para a sua máquina cliente.

    • Kubectl.exe $env:ProgramFiles\AksHci abaixo de c:\adsso
    • Kubectl-adsso.exe $env:ProgramFiles\AksHci abaixo de c:\adsso

Passo 6: Ligação ao servidor API da máquina do cliente

Depois de ter concluído os passos anteriores, inicie sessão na sua Windows máquina de clientes unida ao domínio utilizando as suas credenciais SSO. Abra o PowerShell e, em seguida, tente aceder ao servidor API utilizando kubectl . Se for solicitado para a autenticação, então você conseguiu configurar a AD SSO com sucesso.

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

Como mencionado no Passo 2, é criada uma ligação de função padrão com privilégios de administração de cluster para o utilizador e/ou o grupo que foi fornecido durante a instalação. A vinculação de papéis em Kubernetes define as políticas de acesso para grupos AD. Este passo descreve como usar o RBAC para criar novas ligações de grupo AD em Kubernetes e para editar as ligações de papéis existentes. Por exemplo, o administrador do cluster pode querer conceder privilégios adicionais aos utilizadores utilizando grupos AD (o que torna o processo mais eficiente). Para saber mais sobre o RBAC, consulte a autorização do RBAC.

Ao criar ou editar mais entradas do grupo AD RBAC, o nome do sujeito deve ser pré-fixado por " microsoft:activedirectory:CONTOSO\\group name " . Note que os nomes devem conter um nome de domínio e um prefixo que são incluídos por citações 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 abaixo mostra como criar um papel personalizado e a ligação de papéis para um espaço de nome com um grupo de AD. No exemplo, o "SREGroup" é um grupo pré-existente no Diretório Ativo contoso. Quando os utilizadores são adicionados ao grupo AD, são imediatamente concedidos 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 
 namespace: sre 
 metadata: 
   name: ad-user-cluster-admin 
 roleRef: 
   apiGroup: rbac.authorization.k8s.io 
   kind: Role 
   name: sre-user-full-access 
 subjects: 
 - apiGroup: rbac.authorization.k8s.io 
   kind: User 
   name: "microsoft:activedirectory:CONTOSO\SREGroup" 

Antes de aplicar o ficheiro yaml, o grupo e os nomes de utilizador devem ser sempre convertidos em SIDs utilizando o comando:

kubectl-adsso nametosid <rbac.yml>

Da mesma forma, para atualizar um RBAC existente, pode converter o SID num nome de grupo fácil de utilizar antes de escoar alterações. Para converter o SID, utilize o comando:

kubectl-adsso sidtoname <rbac.yml>

Alterar a palavra-passe da conta AD associada à conta do servidor API

Quando a palavra-passe for alterada para a conta do servidor API, deve desinstalar o addon de autenticação AD e reinstalá-lo utilizando as teclas atuais e anteriores atualizadas.

Sempre que alterar a palavra-passe, deve mudar o nome da chave atual(current.keytab)para anterior.keytabe, em seguida, certifique-se de que nomeia a nova palavra-passe current.keytab.

Importante

Os ficheiros devem ser nomeados current.keytab e previous.keytab,respectivamente. As vinculações de papel existentes não são afetadas por este facto.

Desinstalar e reinstalar a autenticação AD

Pode querer reinstalar O SSO de AD quando a conta para o servidor API for alterada, quando a palavra-passe é atualizada, ou para resolver problemas de uma falha.

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

Uninstall-AksHciAdAuth -name mynewcluster1

Para reinstalar a autenticação 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

O -previousKeytab parâmetro só é necessário quando se altera a palavra-passe. Isto é para evitar tempo de inatividade se os clientes tiverem bilhetes em cache.

Criar a Conta AD do servidor API e o ficheiro keytab

Há dois passos envolvidos neste processo. Em primeiro lugar, crie uma nova conta/utilizador AD para o servidor API com o nome principal do serviço (SPN) e, em segundo lugar, crie um ficheiro keytab para a conta AD.

Passo 1: Criar uma nova conta de AD ou utilizador para o servidor API

Utilize o comando PowerShell New-ADUser para criar uma nova conta/utilizador AD com o SPN. Eis um exemplo:

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

Passo 2: Criar o ficheiro keytab para a conta AD

Para criar o ficheiro keytab, utilize o comando ktpass Windows.

Aqui está um exemplo usando ktpass:

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

Nota

Se vir este erro, os nomes DsCrackNames devolvidos 0x2 na entrada do nome, certifique-se de que o parâmetro para está em forma onde o DOMÍNIO é a saída do eco mapuser DOMAIN\user%userdomain% .

Determinar o identificador de segurança do utilizador ou do grupo

Utilize uma das duas opções seguintes para encontrar o SID para a sua conta ou para outras contas.

Para encontrar o SID associado à sua conta, a partir de um pedido de comando do seu diretório de casa, digite o seguinte:

whoami /user

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

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

Resolução de problemas (certificados)

O webhook e o servidor API utilizam certificados para validar mutuamente a ligação TLS. Este certificado expira em 500 dias. Para verificar se o certificado expirou, consulte os registos de um ad-auth-webhook contentor:

kubectl logs ad-auth-webhook-xxx

Se vir erros de validação de certificados, complete os passos para desinstalar e reinstalar o webhook e obter novos certificados.

Passos seguintes

Neste guia de como fazer, aprendeu a configurar a Autenticação AD para ligar de forma segura ao servidor API com credenciais SSO. Em seguida, pode: