Como implantar apps ASP.NET com a autenticação do Windows em contêineres do GKE para Windows

Padrão

Neste tutorial, mostramos como criar um aplicativo da Web ASP.NET que use IIS com a Autenticação integrada do Windows e como implantá-lo usando um contêiner do Windows para um cluster do Google Kubernetes Engine (GKE) que tenha nós do Windows Server associados ao domínio. Essa configuração é útil para implantar aplicativos ASP.NET em contêineres do Windows no Google Cloud para que os aplicativos possam se autenticar em outros recursos do Windows. No tutorial, também mostramos como criar uma conta de serviço gerenciada em grupo (gMSA) no Active Directory e como configurar a implantação de aplicativos da Web no GKE para usá-la.

Este tutorial é destinado a administradores do sistema. Para acompanhá-lo, é necessário ter familiaridade com o Active Directory e experiência com o Google Kubernetes Engine (GKE).

Objetivos

Criar um cluster do GKE que tenha nós do Windows Server associados ao domínio e configurar o cluster para aceitar gMSAs do Active Directory.
Crie e implante uma imagem de contêiner de aplicativo da Web ASP.NET que use o IIS com a autenticação integrada do Windows.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Compute Engine
GKE
Artifact Registry
Outros custos associados ao tutorial relacionado Como configurar o Active Directory para VMs para ingressar automaticamente em um domínio:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

Siga as etapas no tutorial Como configurar o Active Directory para VMs para ingressar automaticamente em um domínio para criar o serviço do Cloud Run associado ao domínio do Active Directory.

Observação: não execute as etapas da seção Limpeza, porque recursos deste tutorial serão utilizados.
Se você estiver executando este tutorial em um projeto do Google Cloud diferente daquele em que você criou uma VM para testar a associação automática de domínios, execute as etapas para ativar um projeto para a associação automática de domínio do seu projeto do Google Cloud.

Ao concluir o outro tutorial, você terá um novo serviço do Cloud Run e o URL ficará impresso na janela do PowerShell (o valor da variável $RegisterUrl). Anote o endereço do serviço, porque você o usará neste tutorial.
Verifique se você ativou as APIs para o Compute Engine, GKE, Cloud Build, Artifact Registry e a API Cloud Resource Manager:

Ativar as APIs

Ao concluir este tutorial, exclua os recursos criados para evitar a continuidade no faturamento. Para mais informações, consulte Como fazer a limpeza.

Arquitetura

Aplicativos baseados em Windows executados em um Windows Server associado ao domínio geralmente usam identidades do Microsoft Active Directory (AD) para autenticar usuários e aplicativos. Os casos de uso comuns são os seguintes:

Criar aplicativos da Web ASP.NET que usam a Autenticação integrada do Windows para autenticar usuários do Active Directory quando eles tentam fazer login no aplicativo da Web.
Criar aplicativos que usam a conta de computador do Active Directory do servidor para acessar recursos pela rede, como um compartilhamento remoto de SMB ou uma instância remota do Microsoft SQL Server.

Os contêineres do Windows não podem ser associados ao domínio e, portanto, não têm contas de computador no Active Directory. Por isso, os aplicativos da Web ASP.NET executados em contêineres do Windows não podem autenticar os usuários do Active Directory por meio da Autenticação integrada do Windows e, portanto, não podem acessar recursos protegidos na rede. Para mais informações sobre como o ASP.NET acessa recursos protegidos, consulte Identidades do pool de aplicativos na documentação da Microsoft.

Em vez de usar uma conta de computador, os contêineres do Windows podem usar uma identidade de conta de serviço gerenciada (gMSA) do grupo do Active Directory para acessar o Active Directory e outros recursos protegidos na rede, como compartilhamentos de arquivos e o SQL Server. . Para mais informações, consulte Visão geral das contas de serviço gerenciadas em grupo na documentação da Microsoft.

O diagrama de arquitetura a seguir mostra os recursos usados neste tutorial:

Contêineres de Windows Server associados ao domínio ativo no GKE.

O diagrama mostra os seguintes elementos:

VM de desenvolvimento. Neste tutorial, você cria uma VM do Windows Server usada para criar a imagem do contêiner do aplicativo da Web ASP.NET e para criar o gMSA.
Cluster e nós do GKE. Neste tutorial, o cluster do GKE tem um pool de nós do Linux e um do Windows Server das seguintes maneiras:
- Os nós do Linux executam componentes do sistema que são executados apenas nos sistemas operacionais Linux, como o servidor de métricas do GKE.
- Os nós do Windows Server são usados para hospedar contêineres do Windows Server e são associados a um domínio do Active Directory.
Infraestrutura do Active Directory. Para fazer com que os nós do Windows do GKE sejam conectados ao domínio, primeiro siga o tutorial Como configurar o Active Directory para VMs para ingressar automaticamente em um domínio. Nesse tutorial, você cria um serviço do Cloud Run responsável por registrar novos computadores (instâncias) no Active Directory e fornecer a cada nova instância uma senha temporária que a instância usa para concluir a associação ao domínio processo. Cada nova instância no pool de nós do Windows Server chama o serviço Cloud Run para ingressar no domínio do Active Directory.
Balanceador de carga de rede. Quando um usuário local abre o navegador e navega até o aplicativo da Web ASP.NET, o tráfego passa por um balanceador de carga de rede. O balanceador de carga é criado pelo GKE quando você cria um serviço LoadBalancer do GKE para o aplicativo da Web. O usuário também se autentica no aplicativo da Web passando as credenciais do Active Directory para o aplicativo da Web.

Como criar a infraestrutura

Depois de concluir o tutorial relacionado, crie os componentes da infraestrutura para o tutorial atual, que inclui o seguinte:

Uma VM do Windows Server que tem uma imagem de contêiner de aplicativo da Web ASP.NET.
Um cluster do GKE que tem um pool de nós do Windows Server.
Regras de firewall que concedem aos pods do GKE acesso ao Active Directory.
Um webhook no cluster do GKE que processa a configuração e o preenchimento de recursos do gMSA nas implantações.

Criar uma VM de desenvolvimento

A imagem do contêiner do Windows Server criada precisa corresponder à versão do Windows Server da VM em que a imagem do contêiner é criada. Essa versão também precisa corresponder à versão do Windows Server dos nós do Windows Window do GKE. Criar uma imagem de contêiner ou executar um contêiner em uma versão diferente do Windows Server resulta em um erro. Para mais informações sobre os requisitos de compatibilidade dos contêineres do Windows, consulte Como corresponder a versão do host do contêiner com as versões de imagem do contêiner.

Neste tutorial, usamos a versão de Canal de Manutenção de Longo Prazo (LTSC, na sigla em inglês) 2022 do Windows Server para a VM, os nós do Windows Server no GKE e a imagem do contêiner. Para mais informações, consulte mapeamento de versões entre versões do Windows Server e do GKE.

No Console do Google Cloud, ative o Cloud Shell.

Ativar o Cloud Shell

Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.
Se o PowerShell estiver aberto, feche-o digitando exit.
Defina variáveis de ambiente para o nome da rede e da sub-rede e para o URL do serviço do Active Directory:
```
export NETWORK_NAME=NETWORK-NAME
export SUBNETWORK_NAME=SUBNETWORK-NAME
export AD_JOIN_SERVICE_URL=AD-JOIN-SERVICE-URL
```
Substitua:
- NETWORK-NAME: a rede VPC em que as VMs serão implantadas.
- SUBNETWORK-NAME: a sub-rede em que as VMs serão implantadas.
- AD-JOIN-SERVICE-URL: o URL do serviço CloudCloud Run que você implantou na seção Antes de começar.
Defina o ID do projeto e a região do Google Cloud para o ambiente atual:
```
gcloud config set project PROJECT-ID
gcloud config set compute/zone ZONE-NAME
```
Substitua:
- PROJECT-ID pelo ID do projeto do Google Cloud.
- ZONE-NAME: a zona em que todas as VMs serão implantadas. Para reduzir a latência, recomendamos que você selecione uma zona na mesma região em que implantou o serviço do Cloud Run de associação de domínio do Active Directory.

Crie uma conta de serviço para a VM de desenvolvimento:

export SERVICE_ACCOUNT_NAME=dev-vm
export SERVICE_ACCOUNT_EMAIL=$SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \
    --display-name="Development VM Service Account"

Conceda à conta de serviço acesso ao Artifact Registry:

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
    --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
    --role="roles/artifactregistry.writer"

Conceda à conta de serviço acesso ao GKE:
```
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
    --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
    --role="roles/container.admin"
```
A conta de serviço recebe o papel container.admin porque esse papel tem permissões para criar clusters do GKE no projeto e gerenciar recursos em clusters, incluindo recursos de controle de acesso baseado em papéis (RBAC, na sigla em inglês). Os recursos do RBAC são necessários para controlar qual pod tem permissão para usar um gMSA.
Crie uma nova VM do Windows Server 2022:
```
gcloud compute instances create gmsa-dev-vm \
    --image-project windows-cloud \
    --image-family windows-2022-core \
    --machine-type n1-standard-2 \
    --boot-disk-type=pd-ssd \
    --boot-disk-size=100GB \
    --network $NETWORK_NAME \
    --subnet $SUBNETWORK_NAME \
    --service-account=$SERVICE_ACCOUNT_EMAIL \
    --scopes https://www.googleapis.com/auth/cloud-platform \
    --metadata sysprep-specialize-script-ps1="iex((New-Object System.Net.WebClient).DownloadString('$AD_JOIN_SERVICE_URL')); Add-WindowsFeature RSAT-AD-PowerShell"
```
Observação: se as VMs na sua VPC tiverem maneiras de acessar a Internet sem um endereço IP externo, como através do uso do Cloud NAT, remova o endereço IP externo ou adicione o parâmetro --no-address ao comando antes de executá-lo.

Se você planeja implantar seus aplicativos conteinerizados em contêineres do Windows Server 2019, altere o valor do parâmetro --image-family para windows-2019-core-for-containers.

O escopo https://www.googleapis.com/auth/cloud-platform permite que a instância acesse todas as APIs do Google Cloud, dependendo dos papéis do IAM definidos para a conta de serviço da instância.

A VM é criada com um endereço IP externo para permitir que ela se comunique com a Internet. A VM precisa ter acesso à Internet para fazer o download de vários utilitários, como git e kubectl, e fazer o download do aplicativo da Web ASP.NET no GitHub.

Durante o estágio sysprep, a nova instância é associada ao domínio do Active Directory para permitir o acesso remoto a ela usando sua conta de domínio. O script no comando sysprep também instala o módulo PowerPower para o Active Directory.

Criar um repositório do Artifact Registry no Docker

No Cloud Shell, defina o local padrão para novos repositórios do Artifact Registry:
```
gcloud config set artifacts/location LOCATION
```
Substitua LOCATION por uma região onde você queira criar o repositório do Artifact Registry. Para reduzir a latência, recomendamos selecionar a mesma região em que você implantou a VM de desenvolvimento.

Criar o repositório do Docker no Artifact Registry:

gcloud artifacts repositories create windows-container-images \
    --repository-format=docker

Criar um cluster do GKE

No Cloud Shell, defina uma variável de ambiente para o nome do cluster do GKE:
```
export GKE_CLUSTER_NAME=cluster-1
```
Crie o cluster do GKE:
```
gcloud container clusters create $GKE_CLUSTER_NAME \
    --release-channel rapid \
    --network $NETWORK_NAME \
    --subnetwork $SUBNETWORK_NAME \
    --enable-ip-alias
```
Ao definir o parâmetro --release-channel como rapid, o cluster do GKE é implantado com a versão mais recente do Kubernetes. O parâmetro --enable-ip-alias ativa o IP do alias. O IP do alias é necessário para os nós do Windows Server.

Criar um pool de nós do Windows Server no GKE

Quando você cria um novo cluster do GKE por meio da CLI, o cluster é criado com um pool de nós do Linux. Para usar o Windows Server no GKE, crie um pool de nós do Windows Server.

Os clusters do GKE precisam ter pelo menos um nó do Linux para executar os contêineres internos (sistema) do cluster. Um cluster do GKE não pode ser criado apenas com nós do Windows Server.

No Cloud Shell, defina uma variável de ambiente para o nome do pool de nós do servidor Windows:
```
export NODE_POOL_NAME=windows-server-pool
```
Crie um pool de nós do GKE do Windows Server:
```
gcloud container node-pools create $NODE_POOL_NAME \
    --cluster $GKE_CLUSTER_NAME \
    --machine-type n1-standard-2 \
    --image-type WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022 \
    --num-nodes 2 \
    --no-enable-autoupgrade \
    --metadata sysprep-specialize-script-ps1="iex((New-Object System.Net.WebClient).DownloadString('$AD_JOIN_SERVICE_URL'))"
```
Se você planeja implantar seus aplicativos conteinerizados em contêineres do Windows Server 2019, altere o parâmetro --windows-os-version para ltsc2019.

A chave de metadados sysprep-specialize-script-ps1 é uma chave integrada que aponta para um script do PowerShell executado durante a etapa GCESysprep, antes da primeira inicialização da instância.

O cmdlet iex faz o download do script do PowerShell do serviço de junção de domínios do Active Directory que você implantou no Cloud Run. Em seguida, ele executa o script que une a nova instância ao domínio do Active Directory.

O parâmetro --no-enable-autoupgrade desativa o upgrade automático do nó para todos os nós no pool. Isso é feito porque o upgrade da imagem do Windows de um nó pode causar incompatibilidade entre a versão do Windows Server do nó e a versão do Windows Server do pod. Para mais informações, consulte Como fazer upgrade de pools de nós do Windows Server.

Depois que cada nó é criado, o script domain-join do PowerShell associa o nó ao domínio.

Aguarde alguns minutos até que o pool de nós seja criado e execute o seguinte comando para verificar se todos os nós ingressaram no domínio:

kubectl get node \
-l cloud.google.com/gke-nodepool=$NODE_POOL_NAME \
-o custom-columns=":metadata.name" --no-headers \
    | xargs -I{} gcloud compute instances get-serial-port-output {} --port 1 \
    | grep "sysprep-specialize-script-ps1:.*success" --ignore-case

Se os nós tiverem sido unidos ao domínio, a saída será a seguinte:

timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Successfully registered computer account.
timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Computer successfully joined to domain

Specify --start=152874 in the next get-serial-port-output invocation to get only the new output starting from here.

Se você quiser ver a saída completa do script, remova .*success do comando grep.

Conceder aos pods do GKE acesso ao Active Directory

Você precisa criar uma regra de firewall que permita que os pods do cluster do GKE acessem seus controladores de domínio usando os seguintes protocolos:

Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
GC do LDAP (TCP/3268)
Serviços Web do Active Directory (TCP/9389)

É possível aplicar a regra com base em uma conta de serviço atribuída aos seus controladores de domínio ou aplicá-la usando uma tag de rede, como feito neste tutorial. Para saber mais sobre as portas relacionadas ao Active Directory, consulte a documentação sobre requisitos de porta e protocolo do Active Directory e como usar o Active Directory em firewalls.

Se você estiver usando o Serviço gerenciado para o Microsoft Active Directory (Microsoft AD gerenciado), ignore este procedimento.

No Cloud Shell, consiga o intervalo de endereços IP do pod do cluster do GKE:

CLUSTER_IP_RANGE=`gcloud container clusters describe $GKE_CLUSTER_NAME --format="value(clusterIpv4Cidr)"`

Crie uma regra de firewall para conceder aos pods do GKE acesso ao Active Directory:

gcloud compute firewall-rules create allow-gke-pods-to-ad \
    --network $NETWORK_NAME \
    --allow udp:88,tcp:88,udp:123,tcp:135,tcp:49152-65535,udp:389,tcp:389,udp:445,tcp:445,tcp:3268,tcp:9389 \
    --source-ranges=$CLUSTER_IP_RANGE \
    --target-tags DC-TAG

Substitua DC-TAG pela tag de rede atribuída às VMs dos controladores de domínio.

Configurar o GKE para oferecer suporte ao uso do gMSAs

Para usar um gMSA nos nós do Windows Server, você precisa criar o objeto gMSA no Active Directory, criar um recurso gMSA correspondente no GKE e ativar pods recém-criados para buscar as credenciais do gMSA.

No Cloud Shell, faça o download do script do webhook do gMSA e execute-o:
```
export K8S_GMSA_DEPLOY_DOWNLOAD_REV=b685a27adc40511bb5756dfb3ada2e8578ee72e1
curl https://raw.githubusercontent.com/kubernetes-sigs/windows-gmsa/$K8S_GMSA_DEPLOY_DOWNLOAD_REV/admission-webhook/deploy/deploy-gmsa-webhook.sh -o deploy-gmsa-webhook.sh && chmod +x deploy-gmsa-webhook.sh

./deploy-gmsa-webhook.sh --file ./gmsa-webhook.yml --namespace gmsa-webhook --overwrite
rm -drf gmsa-webhook-certs
```
O script adiciona o manifesto da definição de recurso personalizado (CRD, na sigla em inglês) do gMSA ao cluster do GKE e implanta um webwebhook que fornece as especificações do gMSA aos pods. Agora é possível armazenar especificações do gMSA no cluster e configurar gMSAs para pods e contêineres.

Para saber mais sobre o Kubernetes e os gMSAs, consulte Configurar o GMSA para pods e contêineres do Windows.

O cluster do GKE agora está pronto para executar aplicativos do Windows que exigem o uso de um gMSA. Por exemplo, é possível executar um aplicativo da Web ASP.NET nos nós do Windows Server. É possível configurar o aplicativo para fazer login de usuários com a autenticação do Windows ou fazer com que o aplicativo use o gMSA do pod para acessar um compartilhamento de rede remoto ou um banco de dados do SQL Server.

Integração com o Active Directory

Em seguida, crie um gMSA para o aplicativo da Web do ASP.NET no Active Directory, configure como ele pode ser usado e por quem e, em seguida, adicione a configuração dele ao GKE.

Faça login e inicie o PowerShell

Conecte-se à VM gmsa-dev-vm.
Faça login no Windows usando uma conta do Active Directory que tenha permissão para criar um gMSA.

Sua conta precisa ser membro do grupo Domain Admins ou ser capaz de criar objetos msDS-GroupManagedServiceAccount. Para mais informações, consulte Como provisionar contas de serviço gerenciadas de grupo.

Se você usa o Managed Microsoft AD, sua conta precisa ser membro do grupo Cloud Service Managed Service Account Administrators Para mais informações, consulte Delegar a administração de contas de serviço gerenciadas.
Digite 15 para sair do menu para a linha de comando (PowerShell).

Instalar um ambiente de execução de contêiner

O Windows Server 2022 exige um ambiente de execução de contêiner, como o Docker Community Edition (CE), para criar e executar contêineres do Windows. Para mais informações sobre como instalar um ambiente de execução de contêiner no Windows Server, consulte Primeiros passos: preparar o Windows para contêineres, na documentação da Microsoft.

Se você tiver criado a VM de desenvolvimento usando a imagem windows-2019-core-for-containers, pule o procedimento a seguir, porque a imagem já tem o Docker instalado.

Instale o Docker Community Edition (CE):

Invoke-WebRequest -UseBasicParsing -o install-docker-ce.ps1 `
   "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1"
.\install-docker-ce.ps1

Se a conexão da área de trabalho remota for fechada durante o processo de instalação, reconecte-se à VM.

Aguarde a conclusão do processo de instalação e digite exit para fechar a nova janela do PowerShell.
Digite 15 para sair do menu para a linha de comando (PowerShell).

Criar uma chave raiz do KDS

Antes de criar um gMSA, verifique se o controlador de domínio do Active Directory tem uma chave raiz dos Serviços de Distribuição de Chaves (KDS). O Active Directory usa a chave raiz do KDS para gerar senhas para gMSAs.

Se você estiver usando o Microsoft AD gerenciado, pule o procedimento a seguir porque ele cria a chave raiz KDS quando você cria o domínio.

Em gmsa-dev-vm, verifique se o Active Directory já tem a chave raiz do KDS:
```
Get-KdsRootKey
```
Esse comando exibirá o ID da chave, se houver.
Se você não receber um ID de chave em resposta, crie a chave:
```
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
```

Criar o gMSA

Ao criar um gMSA, você precisa fornecer os nomes dos computadores que têm acesso a ele. Como prática recomendada de segurança, conceda permissão ao gMSA apenas às instâncias em que o aplicativo é executado. Quando você cria um pool de nós do Windows Server, associado a um domínio, um novo grupo do Active Directory é criado para os computadores do pool de nós. O nome do grupo corresponde ao nome do grupo de instâncias gerenciadas (MIG) que o GKE cria para o pool de nós.

No PowerShell, defina variáveis para o ID do projeto do Google Cloud, o nome do cluster, o nome do pool de nós do Windows, o nome do gMSA e o nome de domínio do AD:
```
$ProjectId = "PROJECT-ID"
$GkeClusterName = "cluster-1"
$PermittedNodePool = "windows-server-pool"
$GmsaName = "WebApp-01"
$AdDomain = (Get-ADDomain).DNSRoot
```
Substitua PROJECT-ID pelo ID do projeto do Google Cloud.
Defina a configuração do cluster para a ferramenta gcloud:
```
gcloud config set project $ProjectId
gcloud config set compute/zone "ZONE-NAME"
```
Substitua ZONE-NAME pela zona em que você implantou o cluster do GKE.

Recupere o nome de domínio do grupo do Active Directory que foi criado para o pool de nós:

$InstanceGroupUri = gcloud container node-pools describe $PermittedNodePool `
    --cluster $GkeClusterName `
    --format="value(instanceGroupUrls)"
$InstanceGroupName=([System.Uri]$instanceGroupUri).Segments[-1]
$GroupDN=(Get-ADGroup -Filter "name -eq '$InstanceGroupName'")

Write-Host $GroupDN.DistinguishedName

Crie o gMSA:

New-ADServiceAccount -Name $GmsaName `
-DNSHostName "$GmsaName.$AdDomain" `
-PrincipalsAllowedToRetrieveManagedPassword $GroupDN

Verifique se o gMSA foi criado:

Get-ADServiceAccount -Identity $GmsaName

Se o gMSA tiver sido criado, a saída será semelhante a esta:

DistinguishedName : CN=WebApp01,CN=Managed Service Accounts,DC=corp,DC=example,DC=com
Enabled           : True
Name              : WebApp01
ObjectClass       : msDS-GroupManagedServiceAccount
ObjectGUID        : 5afcff45-cf15-467d-aaeb-d65e53288253
SamAccountName    : WebApp01$
SID               : S-1-5-21-780151012-601164977-3226406772-2103
UserPrincipalName :

Adicionar o gMSA ao GKE

Para usar um gMSA em um cluster do Kubernetes, você precisa criar um recurso gMSA no Kubernetes e configurar quais namespaces e contas podem usá-lo.

No gmsa-dev-vm, instale a ferramenta git no PowerShell:

Install-Script -Name Install-Git -Force
Install-Git.ps1
$env:Path += ";c:\program files\git\bin"

Instale a ferramenta kubectl:

$version = (Invoke-WebRequest -UseBasicParsing -Uri "https://dl.k8s.io/release/stable.txt").Content
$uri = "https://dl.k8s.io/release/$version/bin/windows/amd64/kubectl.exe"
New-Item -Type Directory $env:ProgramFiles\kubectl
Start-BitsTransfer -Source $uri -Destination $env:ProgramFiles\kubectl\
$env:Path += ";$env:ProgramFiles\kubectl"

Instale o binário gke-gcloud-auth-plugin:
```
gcloud components install gke-gcloud-auth-plugin
```
Aguarde alguns minutos até que o processo de instalação seja concluído.
Inicialize a ferramenta kubectl com as credenciais do cluster do GKE:
```
gcloud container clusters get-credentials $GkeClusterName
```
Crie o arquivo de especificação de credenciais do gMSA:
```
Install-Module CredentialSpec -Force
$GmsaName = $GmsaName.ToLower()
$CredSpecFile = Join-Path $env:TEMP "$GmsaName-credspec.json"
New-CredentialSpec -AccountName $GmsaName -Path $CredSpecFile

$CredentialsSpec=@{
"apiVersion" = "windows.k8s.io/v1";
"kind" = "GMSACredentialSpec";
"metadata" = @{"name" = $GmsaName}
"credspec" = (Get-Content $CredSpecFile | ConvertFrom-Json)
}

$CredentialsSpec | ConvertTo-Json -Depth 5 | Set-Content $CredSpecFile
```
O nome do recurso GMSACredentialSpec no Kubernetes precisa usar caracteres minúsculos.

O script altera o uso de letras maiúsculas da variável $GmsaName para obedecer a essa restrição.

O script exibe uma mensagem de aviso informando que o teste da conta de serviço gerenciada falhou, o que é esperado. Sua VM de desenvolvimento não é membro do grupo atribuído ao gMSA. Portanto, não é possível testar o gMSA a partir da VM. A mensagem de aviso não impede que o comando gere a especificação de credenciais do gMSA.
Adicione a especificação de credenciais do gMSA ao cluster do GKE:
```
kubectl apply -f $CredSpecFile
```

Clone o repositório do GitHub:

git clone https://github.com/GoogleCloudPlatform/gke-aspnet-gmsa.git
cd gke-aspnet-gmsa

Adicione os objetos RBAC gMSA ao cluster:
```
kubectl apply -f gmsa-rbac-webapp-01.yaml
```
O gmsa-rbac-webapp-01.yaml cria um objeto RBAC ClusterRole para o gMSA e vincula o novo papel de cluster à conta de serviço padrão no namespace default. Se você estiver implantando seu aplicativo em um namespace diferente, edite o arquivo gmsa-rbac-webapp-01.yaml e altere o namespace para a vinculação de papel e para a conta de serviço.

Como implantar e usar o aplicativo da Web

Em seguida, crie o aplicativo da Web e a imagem do contêiner, implante a nova imagem do contêiner no cluster do GKE e abra o aplicativo da Web no navegador para verificar se o aplicativo da Web pode usar o gMSA.

Criar e implantar o aplicativo da Web ASP.NET

No gmsa-dev-vm, no PowerShell, defina variáveis para o local e nome do registro e a tag de imagem:
```
$RegistryLocation = "LOCATION-docker.pkg.dev"
$ProjectsRegistry = "$RegistryLocation/$ProjectId"
$ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
```
Substitua LOCATION pelo local onde você criou o repositório do Artifact Registry.
Crie a imagem do contêiner:
```
docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
```
Para criar imagens do contêiner do Windows Server 2019, defina o valor do parâmetro -f como Dockerfile-WINDOWS_LTSC2019.

Envie a imagem do contêiner para o Artifact Registry

gcloud auth configure-docker $RegistryLocation --quiet
docker push $ImageTag

Faça o download do arquivo YAML do aplicativo e atualize-o com a configuração do gMSA:
```
$ApplicationYaml = Join-Path $env:TEMP "gmsa-test-webapp-01.yaml"

(Get-Content gmsa-test-webapp-01.yaml.template) `
-Replace '\${image_path}',$ImageTag | `
Set-Content $ApplicationYaml
```
Se você criar nós do Windows Server 2019 no GKE, edite o arquivo YAML do aplicativo e altere o valor de cloud.google.com/gke-windows-os-version de 2022 para 2019.
Implante o aplicativo da Web no seu cluster do GKE:
```
kubectl apply -f $ApplicationYaml
```

Verifique se o aplicativo da Web ASP.NET está em execução

O aplicativo da Web é exposto à Internet por meio de um serviço LoadBalancer. Antes de navegar para o aplicativo da Web, aguarde o pod e o serviço serem implantados. A implantação do pod pode levar vários minutos porque as imagens de contêiner do Windows Server Core são grandes (a imagem do aplicativo da Web é maior que 7 GB) e leva algum tempo para que o nó faça o download da imagem e crie o contêiner.

Verifique o status do pod:
```
kubectl get pods --selector=app=gmsa-test-webapp-01
```
Repita o comando até que a saída mostre que o status do pod é Running:
```
NAME                                   READY     STATUS    RESTARTS   AGE
gmsa-test-webapp-01-76c6d64975-zrtgq   1/1       Running   0          28s
```
Se o status do pod permanecer Pending e não for alterado para ContainerCreating ou Running, verifique a imagem de origem do nó do Windows para garantir que ele seja o Windows Server 2022. Você também pode verificar a tabela de mapeamento de versões para ver como as versões do GKE são mapeadas para as versões do Windows Server. Se as versões não forem correspondentes, duplique o arquivo Dockerfile-WINDOWS_LTSC2022, defina a imagem de contêiner base no novo arquivo para que ela corresponda à versão do Windows Server dos nós e repita as etapas para criar e implantar o aplicativo da Web ASP.NET.

Verifique o status do serviço:

kubectl get service --selector=app=gmsa-test-webapp-01

Repita o comando até que a saída mostre que o serviço tem um endereço IP externo:

NAME                   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
gmsa-test-webapp-01    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s

Anote o valor de external-ip na saída. você precisará desse valor mais tarde.

Executar testes preliminares no aplicativo da Web ASP.NET

O pod agora está em execução e pode ser acessado pela Internet por meio de um balanceador de carga de rede. Em seguida, você executa testes preliminares para verificar se o contêiner foi implantado com êxito e se tem permissões para usar o gMSA.

Em um navegador, acesse http://EXTERNAL-IP para ver o aplicativo da Web de teste gMSA.

Substitua EXTERNAL-IP pelo endereço IP que você recebeu no procedimento anterior.

Role até a seção Verificações de simulação e clique no botão Executar verificações de simulação para verificar se todos os testes foram aprovados.

Se os testes forem aprovados, a saída será a seguinte:

[PASS]  Active Directory RSAT PowerShell Module Installed

[PASS]  IIS Document Root found
        C:\inetpub\wwwroot\

[PASS]  PowerShell Scripts Folder found
        C:\inetpub\wwwroot\Powershell\

[PASS]  Container Diagnostic Script found
        C:\inetpub\wwwroot\Powershell\\containerDiag.ps1

[PASS]  Domain Diagnostic Script found
        C:\inetpub\wwwroot\Powershell\\domainDiag.ps1

[RES]   Result: PASS   All checks passed! Please proceed to run the different tests.

Role até a seção Informações do contêiner e clique no botão Executar script. Verifique se você vê informações sobre o contêiner e o nó e se nenhum erro é exibido.

Usar o gMSA em contêineres do Windows

Agora é possível verificar se a configuração do gMSA está funcionando corretamente executando vários testes no aplicativo da Web. Cada um dos testes usa o gMSA para uma finalidade diferente. Se todos os testes forem bem-sucedidos, você configurou o gMSA corretamente.

Validar a configuração do contêiner do gMSA

Role até a seção Domain Connectivity, digite o nome do gMSA (WebApp-01) na caixa Account Name e clique em Run Script. Aguarde alguns segundos para que os testes sejam concluídos.

A resposta será semelhante a:
```
*****   C O N T A I N E R   D I A G N O S T I C S   *****

[INFO]  Starting script execution at 01-05-2021-13:53:11

[INFO]  Using gMSA: WebApp-01

[PASS]  gMSA Account found in Active Directory
        CN=WebApp01,CN=Managed Service Accounts,DC=corp,DC=example,DC=com

[PASS]  This Container (gmsa-test-webapp01-5bc485b8d5-9lbb7) is running on a GKE Windows Node that is authorized to use WebApp01

[INFO]  Script execution complete at 01-05-2021-13:53:12

*****      E N D   O F   D I A G N O S T I C S      *****
```
O script usa dois cmdlets do PowerShell para testar o acesso ao gMSA:
- Get-ADServiceAccount: este cmdlet recupera informações sobre um gMSA. Se esse cmdlt for executado com sucesso, o contêiner estará em execução com um gMSA válido.
- Test-ADServiceAccount: este cmdlet testa se pode recuperar as credenciais do gMSA. Se o cmdlt for executado com êxito, o contêiner estará em execução em um nó do Windows Server que tem permissão para acessar as credenciais do gMSA.

Fazer login dos usuários com a autenticação do Windows

Na barra de navegação superior da página, clique em Login.
Quando você for solicitado a inserir as credenciais, digite o nome de usuário e a senha do domínio.
Se você vir a página Segura com as informações da conta e não for necessário fornecer credenciais, significa que o navegador fez login automaticamente usando sua identidade atual.

Após a autenticação, você verá a página Proteger. Confira as três seções a seguir:
- Informações do usuário: exibe seu nome de usuário e o tipo de autenticação usado.
- Grupos: exibe a lista de grupos aos quais você pertence. Os nomes de grupos na lista são recuperados do Active Directory.
- Declarações de usuário: exibe a lista de declarações do usuário, conforme fornecido pelo Active Directory durante o login. As declarações de associação ao grupo mostram o SID do grupo do Active Directory, não os nomes delas.

Além de suportar a Autenticação Integrada do Windows, o aplicativo da Web ASP.NET pode usar o gMSA para autenticação ao chamar servidores remotos. Usando o gMSA, o aplicativo da Web e qualquer outro aplicativo em execução no contêiner do Windows pode acessar recursos na rede que exigem autenticação do Windows, como instâncias do SQL Server e compartilhamentos de rede baseados em SMB.

Solução de problemas

Se você encontrar mensagens de erro durante o processo de configuração ou ao testar o aplicativo da Web, consulte as seguintes páginas de solução de problemas:

Como solucionar problemas do Windows Server no GKE
Documentação do Kubernetes sobre como solucionar problemas de contêineres do Windows Server
Documentação da Microsoft sobre solução de problemas do gMSAs para contêineres do Windows

Outras considerações para aplicativos de produção

As instruções que você seguiu foram escritas para fornecer um caminho ideal para fins do tutorial. Para um ambiente de produção, é possível fazer alterações em alguns dos procedimentos para tornar o resultado mais robusto, conforme descrito nas seções a seguir.

Considerações sobre o pool de nós do Windows Server

Se você planeja implantar seu próprio aplicativo que usa um gMSA e o aplicativo é compatível com sessões do cliente, recomendamos que você crie pelo menos dois nós no pool de nós. Ter vários nós permite usar o armazenamento de sessão fora de processo para verificar se o aplicativo pode processar sessões distribuídas corretamente.

Neste tutorial, você cria um único pool de nós do Windows Server para hospedar seus aplicativos. No entanto, pode haver situações em que você queira criar vários pools de nós do Windows Server no cluster, por exemplo, um pool de nós com discos permanentes HDD e outro pool de nós com DPs SSD. Se você precisar implantar seu aplicativo em vários pools de nós, forneça uma matriz de objetos de grupo do Active Directory para o parâmetro PrincipalsAllowedToRetrieveManagedPassword, ao criar o gMSA usando o cmdlet New-ADServiceAccount.

Considerações sobre o gMSA e o nome principal do serviço (SPN)

Se o aplicativo exigir que você autentique usuários usando o Kerberos (por exemplo, para oferecer suporte à delegação de identidade), você precisará acessar seu aplicativo usando um DNS personalizado e configurar o gMSA com um nome principal do serviço (SPN). Por exemplo, se o balanceador de carga expõe o aplicativo no GKE por meio de https://my-web-app/, você precisa criar um SPN chamado HTTP/my-web-app de uma das seguintes maneiras:

Para um novo gMSA, crie o gMSA com os SPNs necessários. Exemplo:

New-ADServiceAccount -Name $GmsaName `
-DNSHostName "$GmsaName.$AdDomain" `
-PrincipalsAllowedToRetrieveManagedPassword $Groups `
-ServicePrincipalNames "HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"

Para um gMSA existente, chame Set-ADServiceAccount para adicionar os SPNs necessários ao gMSA. Exemplo:

Set-ADServiceAccount $GmsaName -ServicePrincipalNames @{Add="HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"}

Dependendo da configuração do DNS, talvez seja necessário criar um SPN para HTTP/www.my-web-app e HTTP/www.my-web-app.$AdDomain.

Para protocolos não HTTP, como um serviço WCF configurado com vinculação TCP e autenticação do Windows, talvez seja necessário criar outros tipos de SPNs, como um SPN HOST/.

Como escolher a identidade do pool de aplicativos do IIS

Os aplicativos da Web ASP.NET são executados no Windows no servidor da Web IIS. No IIS, você configura grupos de aplicativos da Web que compartilham o mesmo processo. Esse grupo é chamado de pool de aplicativos. Cada pool de aplicativos é hospedado em um processo dedicado chamado w3wp. Os pools de aplicativos do IIS fornecem a configuração do processo, por exemplo, se ele é de 32 ou 64 bits e fornece a identidade do processo. Ao executar um aplicativo da Web em um contêiner do Windows, defina a identidade do processo do pool de aplicativos para usar a conta de Serviço de rede integrada.

As contas de identidade do pool de aplicativos locais, que também são compatíveis com o IIS, não são necessárias em contêineres do Windows. As contas de identidade do pool de aplicativos foram criadas pelo IIS como forma de impor um limite de segurança local ao executar vários aplicativos da Web na mesma instância do IIS. Com os contêineres do Windows, em que cada aplicativo da Web é hospedado em um contêiner separado, não é necessário criar um limite de segurança no contêiner, porque o próprio contêiner fornece o limite de segurança.

Mesmo que a identidade do pool de aplicativos esteja configurada para usar a conta de serviço de rede, se o aplicativo fizer uma solicitação a um recurso externo que requer autenticação, o aplicativo fará a autenticação usando o gMSA configurado para o Contêiner do Windows.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

No Console do Google Cloud, acesse a página Gerenciar recursos.
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Como remover recursos individuais

Se você quiser manter seu projeto do Google Cloud, mas não quiser excluir os recursos do Google Cloud criados para este tutorial, remova os recursos individualmente.

Reverter alterações do Active Directory

Conecte-se à VM de desenvolvimento e faça login como um usuário que tenha acesso administrativo ao seu domínio do Active Directory.
Na VM gmsa-dev-vm, se o PowerShell ainda não estiver aberto, abra-o:
```
PowerShell
```

Exclua o gMSA:

Remove-ADServiceAccount -Identity "WebApp-01" -Confirm:$false

Excluir recursos da nuvem

No Console do Google Cloud, ative o Cloud Shell.

Ativar o Cloud Shell
Inicialize o ambiente gcloud:
```
gcloud config set project PROJECT-ID
gcloud config set compute/zone ZONE-NAME
gcloud config set artifacts/location LOCATION
```
Substitua:
- PROJECT-ID pelo ID do projeto do Google Cloud.
- ZONE-NAME pela zona onde você implantou o cluster do GKE e a VM de desenvolvimento.
- LOCATION pela região onde você implantou o repositório do Artifact Registry.

Exclua a VM de desenvolvimento:

gcloud compute instances delete gmsa-dev-vm --quiet

Exclua a conta de serviço:

gcloud iam service-accounts delete dev-vm@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --quiet

Exclua o cluster do GKE:

gcloud container clusters delete cluster-1 --quiet

Se você tiver criado uma regra de firewall para os controladores do Active Directory, exclua-a:
```
gcloud compute firewall-rules delete allow-gke-pods-to-ad --quiet
```

Excluir o repositório do Docker do Artifact Registry:

gcloud artifacts repositories delete windows-container-images --quiet

Para concluir, siga as etapas de limpeza em Como configurar o Active Directory para VMs para ingressar automaticamente em um domínio.

A seguir

Leia mais sobre os contêineres do Windows Server no GKE.
Saiba mais sobre como criar um cluster do GKE usando pools de nós do Windows Server.
Leia outras maneiras de implantar aplicativos do Windows Server.
Consulte nossas práticas recomendadas para implantar uma floresta de recursos do Active Directory no Google Cloud.
Explore os scripts de teste usados pelo aplicativo da Web ASP.NET no GitHub.