Windows Authentication nos pods do Amazon EKS Windows

Por Marcio Morales, Principal Solutions Architect da Amazon Web Services e
Bruno Gabriel, Cloud Support Engineer do time de Deployment.

De acordo com a documentação da Microsoft: as redes baseadas no Windows geralmente usam o Active Directory (AD) para facilitar a autenticação e a autorização entre usuários, computadores e outros recursos de rede. Os desenvolvedores de aplicações corporativas geralmente projetam suas aplicações para serem integradas ao AD e executadas em servidores associados ao domínio, afim de aproveitar as vantagens da Autenticação Integrada do Windows, que facilita com que usuários e outros serviços façam login de forma automática e transparente na aplicação, usando as suas próprias identidades. Embora os Windows Containers não possam ingressar ao domínio, eles ainda podem usar identidades de domínio do Active Directory para dar suporte a vários cenários de autenticação.

A autenticação do Windows é um tópico que sempre aparece nas reuniões com clientes sobre Windows Containers no Amazon Kubernetes Service (Amazon EKS), desde que o Kubernetes começou a suportá-la como um recurso Alpha na versão 1.14, e a torná-la estável na 1.18. Neste blogpost, abordaremos todas as configurações necessárias para torná-lo funcional, desde CoreDNS e gMSA Webhooks até um pod Windows capaz de trocar tickets Kerberos com sucesso.

Como vamos alcançar isso?

Pré-requisitos e premissas:

• Instalar e configurar corretamente a versão mais recente para AWS CLI, eksctl, kubectl e AWS Tools for Powershell no Amazon EC2 Windows.
• Instalar e configurar corretamente o AWS CLI e o kubectl no Amazon EC2 Linux
• Active Directory Domain Services (AD DS) já em execução no Amazon EC2 ou no AWS Managed Microsoft AD

Neste blog, faremos as seguintes tarefas:

1. Criar um cluster EKS com worker nodes autogerenciados (self-managed) Windows.
2. Ingressar o worker node Windows a um domínio do Active Directory.
3. Criar e configurar contas gMSA no domínio do Active Directory.
4. Instalar o gMSA CredentialSpec CRD.
5. Instalar o Windows gMSA Webhook Admission controller.
6. Criar recursos de gMSA credential spec.
7. Criar um Kubernetes ClusterRole a ser definido para cada gMSA credential spec.
8. Atribuir o Kubernetes ClusterRole a uma conta de serviço específica para usar gMSA credential specs.
9. Configurar o conditional forwarder com o CoreDNS.
10. Configurar a gMSA credential spec na especificação do pod Windows.
11. Testar a autenticação Windows de dentro do pod Windows.

1. Crie um cluster EKS com worker nodes autogerenciados (self-managed) do Windows

Implemente um cluster EKS com workers nodes Windows autogerenciados. Verifique se ele tem conectividade de rede com o domínio do Active Directory e é capaz de resolver o FQDN do domínio. Embora você possa usar seu cluster Amazon EKS existente, este blog compartilhará uma especificação de configuração, que você pode usar para criar seu próprio cluster Amazon EKS via eksctl.

O arquivo de configuração abaixo cria um cluster EKS usando o Kubernetes versão 1.18, um Worker Node Linux gerenciado e um worker node Windows autogerenciado, reutiliza um keypair EC2 existente e atribui as políticas do IAM para gerenciar, monitorar e realizar o ingresso do worker node em um domínio do Active Directory através do AWS Systems Manager. Você pode editar os valores conforme necessário. Observe que você não deve remover o Linux worker node group gerenciado, pois os clusters mistos do Amazon EKS precisam de pelo menos 1 worker node Linux.

1.1 Crie um arquivo YAML com o conteúdo abaixo, salve como cluster-spec.yaml.

---
    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig
    
    metadata:
      name: EKS_CLUSTER_NAME
      region: AWS_REGION
      version: '1.18'
    availabilityZones: 
       - AZ 1
       - AZ 2 
    managedNodeGroups:
      - name: linux-ng
        instanceType: t2.large
        minSize: 1
    
    vpc:
        cidr: 10.10.0.0/16
    
    nodeGroups:
      - name: windows-ng
        instanceType: m5.large
        minSize: 1
        volumeSize: 100
        amiFamily: WindowsServer2019FullContainer
        ssh:
          allow: true
          publicKeyName: NAME_OF_EXISTING_EC2_KEYPAIR
        iam:
          attachPolicyARNs:
            - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
            - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
            - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
            - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM
            - arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
            - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Observação: substitua o nome do cluster, a região, a zona de disponibilidade, o tipo de instância, o bloco CIDR da VPC e a keypair da instância EC2, conforme necessário.

1.2 Para criar o cluster EKS, execute o seguinte comando:

eksctl create cluster -f cluster-spec.yaml --install-vpc-controllers

1.3 Para gerenciar o cluster EKS via kubectl, um kubeconfig deve ser criado. Execute o seguinte comando:

aws eks --region region-code update-kubeconfig --name cluster_name

1.4 Teste sua configuração. Execute o seguinte comando:

kubectl get svc

2. Ingresse o worker node Windows a um domínio do Active Directory

Depende totalmente de você escolher o método preferido para ingressar o worker node Windows a um domínio do Active Directory. Pode ser por meio de ferramentas de automação ou manualmente. Se você usou o arquivo cluster-spec.yaml na etapa 1 para criar seu cluster, o cluster já possuirá as políticas do IAM necessárias para acessar o worker node via SSM ou manualmente por meio de uma sessão RDP.

Se seu domínio do Active Directory for baseado no AWS Directory Service ou on-premises, usando o AD Connector, você poderá usar o SSM Run Command e executar o documento AWS-JoinDirectoryServiceDomain. Certifique-se de que a VPC criada pelo cluster Amazon EKS se comunique com a VPC em que o domínio do Active Directory reside, por meio de VPC Peering ou de Transit Gateway.

Para verificar se o worker node Windows faz parte do domínio do Active Directory, você pode executar um comando do PowerShell no próprio worker node:

(Get-WmiObject -Class Win32_ComputerSystem).PartOfDomain

A saída deve ser semelhante ao seguinte resultado:

3. Cr3. Crie e configure a conta gMSA no domínio do Active Directory

Se você ainda não criou um gMSA em seu domínio, precisará gerar uma chave raiz do Key Distribution Service (KDS). O KDS é responsável por criar, rotacionar e disponibilizar a senha do gMSA para hosts autorizados. Quando um host de container precisa usar o gMSA para executar um container, ele entrará em contato com o KDS para recuperar a senha atual. Se você estiver usando o AWS Managed AD, você pode pular diretamente para a etapa 3.3. As permissões da Conta de Serviço Gerenciado – group Managed Service Account – (gMSA) são pré-configuradas com o Microsoft Active Directory gerenciado pela AWS. Como resultado, você não precisa gerar a chave raiz do KDS para gerar as senhas gMSA.

3.1 Para verificar se a chave raiz do KDS já foi criada, execute o seguinte cmdlet do PowerShell com privilégios de administrador de domínio em um controlador de domínio usando o módulo do AD no PowerShell:

Get-KdsRootKey

3.2 Se o comando retornar um ID de chave, você está pronto. Caso contrário, crie a chave raiz do KDS. Execute o seguinte comando:

Add-KdsRootKey -EffectiveImmediately

Embora o comando sugere que a chave entrará em vigor imediatamente, você precisará esperar 10 horas antes que a chave raiz do KDS seja replicada e esteja disponível para uso em todos os controladores de domínio. Se você estiver interessado em entender melhor as contas gMSA, consulte a documentação oficial da Microsoft.

3.3 Para criar a conta gMSA e permitir que o worker node Windows recupere a senha gMSA, execute os seguintes comandos do PowerShell:

# Create the AD group
New-ADGroup -Name "Amazon EKS Authorized Worker Nodes" -SamAccountName "EKSWorkerNodes" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "gmsaeks" -DnsHostName "gmsaeks.YOURDOMAIN_FQDN" -ServicePrincipalNames "host/gmsaeks", "host/gmsaeks.YOURDOMAIN_FQDN" -PrincipalsAllowedToRetrieveManagedPassword "EKSWorkerNodes"

# Add your Windows Worker Node the AD group
Add-ADGroupMember -Identity "EKSWorkerNodes" -Members "EKSWORDERNODE01$", "EKSWORDERNODE02$", "EKSWORDERNODE03$"

Nota: Substitua YOURDOMAIN_FQDN pelo seu FQDN. Substitua EKSWORDERNODE01 pelo nome NETBIOS do worker node Windows. Não remova o $ no final, pois ele representa uma conta de computador no Active Directory.

3.4 Reinicie o worker node Windows para que ele obtenha sua nova associação ao grupo.

3.5 Verifique se o host pode usar a conta gMSA. No worker node Windows, instale o RSAT-AD-PowerShell. Execute os seguintes comandos do PowerShell:

# Install the RSAT AD Feature
Install-WindowsFeature RSAT-AD-PowerShell

# Verify the host can use the gMSA account
Test-ADServiceAccount gmsaeks

A saída deve ser semelhante ao seguinte resultado:

4. Instale o gMSA CredentialSpec CRD

Para usar a autenticação do Windows em um cluster Amazon EKS, você deve criar um CustomResourceDefinition (CRD). Os CRDs são extensões da API Kubernetes que armazenam uma coleção de objetos de API de determinado tipo. Eles estendem a API Kubernetes ou permitem que você adicione sua própria API ao cluster. Um CustomResourceDefinition (CRD) para recursos de gMSA credential spec precisa ser configurado no cluster para definir o tipo de recurso personalizado GMSACredentialSpec.

4.1 Crie um arquivo chamado gmsa-crd.yaml com o conteúdo abaixo:

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-eks  #This is an arbitrary name but it will be used as a reference
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: gmsaeks   #Username of the GMSA account
      Scope: ad-domain-netbios  #NETBIOS Domain Name
    - Name: gmsaeks   #Username of the GMSA account
      Scope: ad-domain-fqdn #DNS Domain Name
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: ad-domain-fqdn  #DNS Domain Name
    DnsTreeName: ad-domain-fqdn #DNS Domain Name Root
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID
    MachineAccountName: gmsaeks #Username of the GMSA account
    NetBiosName: ad-domain-netbios  #NETBIOS Domain Name
    Sid: S-1-5-21-857038504-468933455-1338018723-94603 #SID of GMSA

4.2 Crie o CDR no cluster EKS. Execute o seguinte comando:

kubectl apply -f gmsa-crd.yaml

5. Instale o Windows gMSA Webhook Admission controller

De acordo com a documentação de assinatura de certificados do Amazon EKS (https://docs.aws.amazon.com/eks/latest/userguide/cert-signing.html), todos os clusters que executam o Amazon EKS versão 1.22 ou mais recente oferecem suporte ao seguinte signatário beta.eks.amazonaws.com/app-serving for Kubernetes Certificate Signing Requests (CSR). Como resultado, substituiremos kubernetes.io/kubelet-serving signer no arquivo de instalação do webhook de admissão do gMSA pelo signatário beta.eks.amazonaws.com/app-serving compatível com o Amazon EKS.

Execute o comando abaixo para implantar o gMSA Webhook Admission Controller no cluster Amazon EKS e atualizar o signatário:

git clone https://github.com/kubernetes-sigs/windows-gmsa.git
cd windows-gmsa/admission-webhook/deploy
sed -i.back "s/signerName: kubernetes.io\/kubelet-serving/signerName: beta.eks.amazonaws.com\/app-serving/g" create-signed-cert.sh
K8S_GMSA_DEPLOY_DOWNLOAD_REV='v0.4.0' ./deploy-gmsa-webhook.sh --file ./gmsa-manifests --image sigwindowstools/k8s-gmsa-webhook:v0.4.0 --overwrite

6. Crie recursos de gMSA credential spec

Até agora, preparamos o cluster Amazon EKS criando o recurso personalizado a ser usado com a especificação de credencial (etapa 4) e webhooks para preencher e validar o recurso em todo o cluster (etapa 5). A gMSA credential spec não contém dados secretos ou confidenciais. É uma informação que um container runtime pode usar para descrever o gMSA desejado de um container para o Windows. Agora, precisamos criar a credential spec (a mesma usada no Docker Swarm ou no Amazon ECS), mas convertida em YAML.

6.1 No worker node Windows do Amazon EKS, execute o seguinte comando para instalar o módulo de Powershell CredentialSpec:

Install-Module CredentialSpec

6.2 Gere o CredentialSpec executando o seguinte comando:

New-CredentialSpec -Name gmsaeks -AccountName gmsaeks -Domain YOURDOMAIN_FQDN

Nota: Substitua YOURDOMAIN_FQDN pelo seu FQDN. Substitua gmsaeks pelo nome da conta da sua conta gMSA criada na etapa 3.3.

6.3 Para converter o CredentialSpec gerado na etapa 6.2 de JSON para YAML, crie um script Powershell contendo o código abaixo com o nome GenerateCredentialSpecResource.ps1.

<#
.Synopsis
 Renders a GMSA kubernetes resource manifest.
#>
Param(
 [Parameter(Position = 0, Mandatory = $true)] [String] $AccountName,
 [Parameter(Position = 1, Mandatory = $true)] [String] $ResourceName,
 [Parameter(Position = 2, Mandatory = $false)] [String] $ManifestFile,
 [Parameter(Mandatory=$false)] $Domain,
 [Parameter(Mandatory=$false)] [string[]] $AdditionalAccounts = @()
)
# Logging for troubleshooting
Start-Transcript -Path "C:\gmsa\CredSpec.txt"
# exit on error
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
$PSDefaultParameterValues['*:ErrorAction'] = 'Stop'
# generate the name of the output file if not specified
if (-not $ManifestFile -or $ManifestFile.Length -eq 0) {
 $ManifestFile = "gmsa-cred-spec-$ResourceName.yml"
}
# check the out file doesn't exist
if ([System.IO.File]::Exists($ManifestFile)) {
 throw "Output file $ManifestFile already exists, refusing to overwrite it"
}
# install the dependencies we need
if (-not (Get-WindowsFeature rsat-ad-powershell).Installed) {
 Add-WindowsFeature rsat-ad-powershell
}
if (-not (Get-Command ConvertTo-Yaml -errorAction SilentlyContinue)) {
 Install-Module powershell-yaml -Force
}
# download the canonical helper script
Invoke-WebRequest "https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1" -UseBasicParsing -OutFile $env:TEMP\cred.psm1
Import-Module $env:temp\cred.psm1
# generate a unique docker cred spec name
$dockerCredSpecName = "tmp-k8s-cred-spec" + -join ((48..57) + (97..122) | Get-Random -Count 64 | ForEach-Object {[char]$_})
# have the upstream function perform its magic
if (-not $Domain) {
 $Domain = Get-ADDomain
}
New-CredentialSpec -Name $dockerCredSpecName -AccountName $AccountName -Domain $Domain.DnsRoot -AdditionalAccounts $AdditionalAccounts
# parse the JSON file thus generated
$dockerCredSpecPath = (Get-CredentialSpec | Where-Object {$_.Name -like "$dockerCredSpecName*"}).Path
$credSpecContents = Get-Content $dockerCredSpecPath | ConvertFrom-Json
# and clean it up
Remove-Item $dockerCredSpecPath
# generate the k8s resource
$resource = [ordered]@{
 "apiVersion" = "windows.k8s.io/v1alpha1";
 "kind" = 'GMSACredentialSpec';
 "metadata" = @{
 "name" = $ResourceName
 };
 "credspec" = $credSpecContents
}
ConvertTo-Yaml $resource | Set-Content $ManifestFile
Write-Output "K8S manifest rendered at $ManifestFile"

6.4 Para executar o script, execute o seguinte comando:

.\GenerateCredentialSpecResource.ps1

Nota: Substitua AccountName por gmsaeks (a conta gMSA gerada na etapa 3.3). Substitua resourceName pelo nome ao qual você deseja referenciar o CredentialSpec para o cluster EKS. Neste exemplo: gmsaeks-account.

6.5 Um arquivo CredSpec foi gerado em YAML. Aplique-o ao cluster:

kubectl apply -f gmsa-cred-spec-gmsaeks-account.yml

7. Crie um ClusterRole a ser definido para cada especificação de credencial gMSA

Um ClusterRole precisa ser definido para cada recurso de gMSA credential spec. Isso autoriza o verb do tipo use em um recurso gMSA específico por um subject que normalmente é uma conta de serviço.

7.1 Crie um arquivo contendo o código abaixo e salve-o como gmsa-create-clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eksgmsa-role 
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsaeks-account"]

Nota: Substitua ResourceNames pelo gerado na etapa 6.2.

7.2 Para criar a ClusterRole, execute o seguinte comando:

kubectl apply -f gmsa-create-clusterrole.yaml

8. Atribua uma função às contas de serviço para usar gMSA credential specs específicas

A conta de serviço com a qual os pods serão configurados precisa estar vinculada ao ClusterRole que você criou na etapa 7.1, afim de autorizar uma conta de serviço específica a consumir o recurso gMSA spec. Neste blog, usaremos a conta de serviço padrão, mas você pode escolher qualquer outra conta que já tenha no cluster EKS.

8.1 Crie um arquivo contendo o código abaixo e salve-o como gmsa-assign-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmsa-assign-role
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: eksgmsa-role
  apiGroup: rbac.authorization.k8s.io

Nota: Substitua o RoleRef utilizando o nome do ClusterRole que você criou na etapa 7.1

8.2 Para atribuir o ClusterRole a uma conta de serviço, execute o seguinte comando:

kubectl apply -f gmsa-assign-role.yaml

9. Configurar o conditional forwarder com o CoreDNS

No Amazon EKS, o CoreDNS é o serviço DNS padrão que os pods usam para resolução de nomes. Os pods Windows que exigem a autenticação do Windows devem ser capazes de resolver o FQDN do Domínio do Active Directory e, para isso, você deve adicionar um conditional forwarder (encaminhador condicional) no CoreDNS.

9.1 Para modificar o CoreDNS ConfigMap e adicionar a configuração do conditional forwarder, execute o seguinte comando:

kubectl -n kube-system edit configmap coredns

A saída deve ser semelhante à seguinte:

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
  labels:
    eks.amazonaws.com/component: coredns
    k8s-app: kube-dns
  name: coredns
  namespace: kube-system
data:
  Corefile: | .:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } DOMAIN-NAME:53 { errors cache 30 forward . custom-dns-server-IP1 custom-dns-server-IP2 reload }

Nota: Substitua DOMAIN-NAME pelo seu nome de domínio. Substitua Custom-DNS-Server-IP pelo endereço IP do seu servidor DNS personalizado. Salve isso. (Se você estiver usando o Windows para executar o kubectl, certifique-se de editar o arquivo usando um editor YAML em vez do Notepad.)

A saída deve ser semelhante à seguinte:

10. Configure a gMSA credential spec na especificação do pod Windows.

Até aqui, você deve ter todas as configurações de cluster do Amazon EKS necessárias. Vamos implementar um pod Windows que usa o gmsaCredentialSpecName, criando um arquivo YAML de deployment contendo o código abaixo:

10.1 Crie um arquivo contendo o código abaixo e salve-o como Windows-Auth-Pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: amazon-eks-gmsa-test
  name: amazon-eks-gmsa-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: amazon-eks-gmsa-test
  template:
    metadata:
      labels:
        run: amazon-eks-gmsa-test
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsaeks-account
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

Nota: Substitua gmsaCredentialSpecName pelo recurso de credencial gMSA que você criou na etapa 6.2. Neste blog, usamos gmsaeks-account.

10.2 Implemente o pod Windows. Execute o seguinte comando:

kubectl apply -f Windows-Auth-Pod.yaml

11. Teste a autenticação do Windows de dentro do pod Windows

11.1 Execute o seguinte comando para executar uma sessão do PowerShell dentro do containercontainer:

kubectl exec -it PODNAME -- powershell.exe

Nota: Substitua PODNAME pelo nome do seu pod.

11.2 Na sessão do PowerShell, você pode executar o seguinte comando para verificar a identidade gMSA de dentro do container, executando o seguinte comando e verificando o nome do cliente. Neste blog, o gmsaeks é a identidade.

klist get krbtgt

Você pode usar o cmdlet nltest para verificar se a conexão confiável com um DC foi feita com sucesso, executando o seguinte comando:

nltest /sc_verify:YOURDOMAINQFN

Por fim, teste-o acessando o AD SYSVOL, executando o seguinte comando:

dir \\YOURDOMAINFQDN\sysvol

Conclusão

Neste blog, abordamos de ponta a ponta como configurar um cluster Amazon EKS para trocar tickets Kerberos com um domínio do Active Directory, permitindo que os pods Windows usem a autenticação do Windows (Windows Authentication). Muitas aplicações ASP.NET reformuladas para serem executadas no Amazon EKS podem aproveitar essa funcionalidade para continuar oferecendo Windows Authentication com base no protocolo Kerberos v5.

Leitura adicional:

• Criar gMSAs para Windows Containers
• Solucionar problemas de gMSA para Windows Containers
• Configurar o gMSA para Windows Containers e Pods (documentação oficial do Kubernetes)

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Marcio Morales é Principal Solutions Architect da Amazon Web Services. Marcio é um SME global para Windows Containers e ajuda os clientes da AWS a projetar, criar, proteger e otimizar cargas de trabalho de Windows Containers na AWS.

Bruno Gabriel é um Cloud Support Engineer do time de Deployment.

Revisor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Luciano Bernardes