Habilite as Contas de Serviço Gerenciado de Grupo (GMSA) para seus nós do Windows Server no cluster do Serviço Kubernetes do Azure (AKS)

Artigo
10/15/2024

As Contas de Serviço Gerenciado de Grupo (GMSA) são uma conta de domínio gerenciada para vários servidores que fornece gerenciamento automático de senhas, gerenciamento simplificado de SPN (nome principal de serviço) e a capacidade de delegar o gerenciamento a outros administradores. Com o Serviço Kubernetes do Azure (AKS), você pode habilitar o GMSA em seus nós do Windows Server, o que permite que contêineres executados em nós do Windows Server se integrem e sejam gerenciados pelo GMSA.

Pré-requisitos

Kubernetes 1.19 ou superior. Para verificar sua versão, consulte Verificar se há atualizações disponíveis. Para atualizar sua versão, consulte Atualizar cluster AKS.
Azure CLI versão 2.35.0 ou superior. Executar az --version para localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).
Identidades gerenciadas habilitadas em seu cluster AKS.
Permissões para criar ou atualizar um Cofre de Chaves do Azure.
Permissões para configurar o GMSA no Serviço de Domínio Ative Directory ou no Ative Directory local.
O controlador de domínio deve ter os Serviços Web do Ative Directory habilitados e deve estar acessível na porta 9389 pelo cluster AKS.

Nota

A Microsoft também fornece um módulo PowerShell criado especificamente para configurar o gMSA no AKS. Para obter mais informações, consulte gMSA no Serviço Kubernetes do Azure.

Configurar o GMSA no controlador de domínio do Ative Directory

Para usar o GMSA com o AKS, você precisa de uma credencial de usuário de domínio padrão para acessar a credencial GMSA configurada no controlador de domínio. Para configurar o GMSA no controlador de domínio, consulte Introdução às contas de serviço gerenciado de grupo. Para a credencial de usuário de domínio padrão, você pode usar um usuário existente ou criar um novo, desde que ele tenha acesso à credencial GMSA.

Importante

Você deve usar o Serviço de Domínio Ative Directory ou o Ative Directory local. No momento, não é possível usar o Microsoft Entra ID para configurar o GMSA com um cluster AKS.

Armazenar as credenciais de usuário de domínio padrão no Cofre da Chave do Azure

Seu cluster AKS usa as credenciais de usuário de domínio padrão para acessar as credenciais GMSA do controlador de domínio. Para fornecer acesso seguro a essas credenciais para o cluster AKS, você deve armazená-las no Cofre de Chaves do Azure.

Se você ainda não tiver um cofre de chaves do Azure, crie um usando o az keyvault create comando.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
Armazene a credencial de usuário de domínio padrão como um segredo em seu cofre de chaves usando o az keyvault secret set comando. O exemplo a seguir armazena a credencial de usuário do domínio com a chave GMSADomainUserCred no cofre de chaves myGMSAVault .
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Nota

Certifique-se de usar o nome de domínio totalmente qualificado para o domínio.

Opcional: usar uma rede virtual personalizada com DNS personalizado

Você precisa configurar seu controlador de domínio através do DNS para que ele seja acessível pelo cluster AKS. Pode configurar a sua rede e DNS fora do cluster AKS para permitir que o cluster aceda ao controlador de domínio. Como alternativa, você pode usar o Azure CNI para configurar uma VNet personalizada com um DNS personalizado em seu cluster AKS para fornecer acesso ao controlador de domínio. Para obter mais informações, consulte Configurar a rede CNI do Azure no Serviço Kubernetes do Azure (AKS).

Opcional: Configurar mais de um servidor DNS

Se você quiser configurar mais de um servidor DNS para Windows GMSA em seu cluster AKS, não especifique --gmsa-dns-serverou v--gmsa-root-domain-name. Em vez disso, você pode adicionar vários servidores DNS na rede virtual selecionando DNS personalizado e adicionando os servidores DNS.

Opcional: use sua própria identidade kubelet para seu cluster

Para fornecer ao cluster AKS acesso ao seu cofre de chaves, a identidade kubelet do cluster precisa de acesso ao seu cofre de chaves. Quando você cria um cluster com a identidade gerenciada habilitada, uma identidade kubelet é criada automaticamente por padrão.

Você pode conceder acesso ao cofre de chaves para a identidade após a criação do cluster ou criar sua própria identidade para usar antes da criação do cluster usando as seguintes etapas:

Crie uma identidade kubelet usando o az identity create comando.

az identity create --name myIdentity --resource-group myResourceGroup

Obtenha a ID da identidade usando o az identity list comando e defina-a como uma variável chamada MANAGED_ID.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```

Conceda à identidade acesso ao cofre de chaves usando o az keyvault set-policy comando.

az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get

Habilitar o GMSA em um novo cluster AKS

Crie credenciais de administrador para usar durante a criação do cluster. Os comandos a seguir solicitam um nome de usuário e o definem como WINDOWS_USERNAME para uso em um comando posterior.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Crie um cluster AKS usando o comando com os az aks create seguintes parâmetros:
- --enable-windows-gmsa: Habilita o GMSA para o cluster.
- --gmsa-dns-server: O endereço IP do servidor DNS.
- --gmsa-root-domain-name: O nome de domínio raiz do servidor DNS.
```
DNS_SERVER=<IP address of DNS server>
ROOT_DOMAIN_NAME="contoso.com"

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure \
    --load-balancer-sku standard \
    --windows-admin-username $WINDOWS_USERNAME \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME \
    --generate-ssh-keys
```
Nota
- Se você estiver usando uma VNet personalizada, precisará especificar a ID da VNet usando o vnet-subnet-id parâmetro e talvez também precise adicionar os docker-bridge-addressparâmetros , dns-service-ipe service-cidr dependendo da sua configuração.
- Se você criou sua própria identidade para a identidade kubelet, use o assign-kubelet-identity parâmetro para especificar sua identidade.
- Quando você especifica os --gmsa-dns-server parâmetros e --gmsa-root-domain-name , uma regra de encaminhamento DNS é adicionada kube-system/coredns ao ConfigMap. Esta regra encaminha as solicitações de DNS dos $ROOT_DOMAIN_NAME pods para o $DNS_SERVER.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Adicione um pool de nós do Windows Server usando o az aks nodepool add comando.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwin \
    --node-count 1

Habilitar o GMSA no cluster existente

Habilite o GMSA em um cluster existente com nós do Windows Server e identidades gerenciadas habilitados usando o az aks update comando.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME

Conceda acesso ao seu cofre de chaves para a identidade kubelet

Nota

Ignore esta etapa se você forneceu sua própria identidade para a identidade kubelet.

Conceda acesso ao seu cofre de chaves para a identidade kubelet usando o az keyvault set-policy comando.

MANAGED_ID=$(az aks show -g myResourceGroup -n myAKSCluster --query "identityProfile.kubeletidentity.objectId" -o tsv)
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get

Instalar GMSA cred spec

Configure kubectl para se conectar ao cluster do Kubernetes usando o az aks get-credentials comando.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Crie um novo YAML chamado gmsa-spec.yaml e cole no YAML a seguir. Certifique-se de substituir os espaços reservados por seus próprios valores.

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: aks-gmsa-spec  # This name can be changed, but it will be used as a reference in the pod spec
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $NETBIOS_DOMAIN_NAME
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $DNS_DOMAIN_NAME
    HostAccountConfig:
      PluginGUID: '{CCC2A336-D7F3-4818-A213-272B7924213E}'
      PortableCcgVersion: "1"
      PluginInput: "ObjectId=$MANAGED_ID;SecretUri=$SECRET_URI"  # SECRET_URI takes the form https://$akvName.vault.azure.net/secrets/$akvSecretName
  CmsPlugins:
 - ActiveDirectory
  DomainJoinConfig:
    DnsName: $DNS_DOMAIN_NAME
    DnsTreeName: $DNS_ROOT_DOMAIN_NAME
    Guid:  $AD_DOMAIN_OBJECT_GUID
    MachineAccountName: $GMSA_ACCOUNT_USERNAME
    NetBiosName: $NETBIOS_DOMAIN_NAME
    Sid: $GMSA_SID

Nota

AKS atualizou o apiVersion de GMSACredentialSpec windows.k8s.io/v1alpha1 para windows.k8s.io/v1 na versão v20230903.

Crie um novo YAML chamado gmsa-role.yaml e cole no YAML a seguir.

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

Crie um novo YAML chamado gmsa-role-binding.yaml e cole no YAML a seguir.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-aks-gmsa-spec
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: aks-gmsa-role
  apiGroup: rbac.authorization.k8s.io

Aplique as alterações de gmsa-spec.yaml, gmsa-role.yaml e gmsa-role-binding.yaml usando o kubectl apply comando.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

Verificar a instalação do GMSA

Crie um novo YAML chamado gmsa-demo.yaml e cole no YAML a seguir.

---
kind: ConfigMap
apiVersion: v1
metadata:
  labels:
   app: gmsa-demo
  name: gmsa-demo
  namespace: default
data:
  run.ps1: |
   $ErrorActionPreference = "Stop"

   Write-Output "Configuring IIS with authentication."

   # Add required Windows features, since they are not installed by default.
   Install-WindowsFeature "Web-Windows-Auth", "Web-Asp-Net45"

   # Create simple ASP.NET page.
   New-Item -Force -ItemType Directory -Path 'C:\inetpub\wwwroot\app'
   Set-Content -Path 'C:\inetpub\wwwroot\app\default.aspx' -Value 'Authenticated as <B><%=User.Identity.Name%></B>, Type of Authentication: <B><%=User.Identity.AuthenticationType%></B>'

   # Configure IIS with authentication.
   Import-Module IISAdministration
   Start-IISCommitDelay
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/windowsAuthentication').Attributes['enabled'].value = $true
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/anonymousAuthentication').Attributes['enabled'].value = $false
   (Get-IISServerManager).Sites[0].Applications[0].VirtualDirectories[0].PhysicalPath = 'C:\inetpub\wwwroot\app'
   Stop-IISCommitDelay

   Write-Output "IIS with authentication is ready."

   C:\ServiceMonitor.exe w3svc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gmsa-demo
  template:
    metadata:
      labels:
        app: gmsa-demo
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: aks-gmsa-spec
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: IfNotPresent
        command:
         - powershell
        args:
          - -File
          - /gmsa-demo/run.ps1
        volumeMounts:
          - name: gmsa-demo
            mountPath: /gmsa-demo
      volumes:
      - configMap:
          defaultMode: 420
          name: gmsa-demo
        name: gmsa-demo
      nodeSelector:
        kubernetes.io/os: windows
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: gmsa-demo
  type: LoadBalancer

Aplique as alterações de gmsa-demo.yaml usando o kubectl apply comando.
```
kubectl apply -f gmsa-demo.yaml
```

Obtenha o endereço IP do aplicativo de exemplo usando o kubectl get service comando.

kubectl get service gmsa-demo --watch

Inicialmente, o EXTERNAL-IP para o gmsa-demo serviço mostra como pendente:

NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
gmsa-demo          LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s

Quando o EXTERNAL-IP endereço mudar de pendente para um endereço IP público real, use CTRL-C para interromper o kubectl processo de monitoramento.

A saída de exemplo a seguir mostra um endereço IP público válido atribuído ao serviço:
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Abra um navegador da Web para o endereço IP externo do gmsa-demo serviço.
Autentique-se com a e senha e confirme $NETBIOS_DOMAIN_NAME\$AD_USERNAME que você vê Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

Desativar o GMSA em um cluster existente

Desative o GMSA em um cluster existente com nós do Windows Server usando o az aks update comando.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-windows-gmsa

Nota

Você pode reativar o GMSA em um cluster existente usando o comando az aks update .

Resolução de Problemas

Se a página carregar, mas você não for solicitado a autenticar, use o kubectl logs POD_NAME comando para exibir os logs do seu pod e verificar se o IIS com autenticação está pronto.

Nota

Por predefinição, os contentores do Windows não mostrarão os registos no kubectl. Para permitir que os contentores do Windows mostrem registos, tem de incorporar a ferramenta Monitorização de Registos na imagem do Windows. Para obter mais informações, consulte Ferramentas de contêiner do Windows.

Tempo limite de conexão ao tentar carregar a página

Se você receber um tempo limite de conexão ao tentar carregar a página, verifique se o aplicativo de exemplo está sendo executado usando o kubectl get pods --watch comando. Às vezes, o endereço IP externo para o serviço de aplicativo de exemplo está disponível antes que o pod de aplicativo de exemplo esteja em execução.

Pod falha ao iniciar e um erro winapi aparece nos eventos pod

Se o pod não iniciar depois de executar o kubectl get pods --watch comando e esperar vários minutos, use o kubectl describe pod POD_NAME comando. Se você vir um erro winapi nos eventos pod, é provável que seja um erro na configuração de especificação cred do GMSA. Verifique se todos os valores de substituição no gmsa-spec.yaml estão corretos, execute kubectl apply -f gmsa-spec.yamlnovamente e reimplante o aplicativo de exemplo.

Próximos passos

Para obter mais informações, consulte Considerações sobre contêineres do Windows com o Serviço Kubernetes do Azure (AKS).

Partilhar via

Habilite as Contas de Serviço Gerenciado de Grupo (GMSA) para seus nós do Windows Server no cluster do Serviço Kubernetes do Azure (AKS)

Pré-requisitos

Configurar o GMSA no controlador de domínio do Ative Directory

Armazenar as credenciais de usuário de domínio padrão no Cofre da Chave do Azure

Opcional: usar uma rede virtual personalizada com DNS personalizado

Opcional: Configurar mais de um servidor DNS

Opcional: use sua própria identidade kubelet para seu cluster

Habilitar o GMSA em um novo cluster AKS

Habilitar o GMSA no cluster existente

Conceda acesso ao seu cofre de chaves para a identidade kubelet

Instalar GMSA cred spec

Verificar a instalação do GMSA

Desativar o GMSA em um cluster existente

Resolução de Problemas

Nenhuma autenticação é solicitada ao carregar a página

Tempo limite de conexão ao tentar carregar a página

Pod falha ao iniciar e um erro winapi aparece nos eventos pod

Próximos passos

Recursos adicionais