Implemente apps ASP.NET com a autenticação do Windows em contentores Windows do GKE

Arquitetura

As aplicações baseadas no Windows que são executadas num Windows Server associado a um domínio usam frequentemente identidades do Microsoft Active Directory (AD) para autenticar utilizadores e aplicações. Seguem-se alguns exemplos de utilização comuns:

• Criar aplicações Web ASP.NET que usam a autenticação integrada do Windows para autenticar utilizadores do Active Directory à medida que tentam iniciar sessão na aplicação Web.
• Criar aplicações que usam a conta de computador do Active Directory do servidor para aceder a recursos através da rede, como uma partilha SMB remota ou uma instância remota do Microsoft SQL Server.

Não é possível associar contentores do Windows a um domínio e, por isso, não têm contas de computador no Active Directory. Por este motivo, as aplicações Web ASP.NET executadas em contentores Windows não podem autenticar utilizadores do Active Directory através da autenticação integrada do Windows e, por conseguinte, não podem aceder a recursos protegidos na rede. Para mais informações sobre como o ASP.NET acede a recursos protegidos, consulte o artigo Identidades do conjunto de aplicações na documentação da Microsoft.

Em vez de usar uma conta de computador, os contentores Windows podem usar uma identidade de conta de serviço gerida (gMSA) de grupo do Active Directory para aceder ao Active Directory e a outros recursos seguros na rede, como partilhas de ficheiros e instâncias do SQL Server. Para mais informações, consulte o artigo Vista geral das contas de serviço geridas por grupos na documentação da Microsoft.

O diagrama de arquitetura seguinte mostra os recursos usados neste tutorial:

O diagrama mostra os seguintes elementos:

• VM de desenvolvimento. Neste tutorial, vai criar uma VM do Windows Server que vai usar para criar a imagem do contentor da aplicação Web ASP.NET e para criar o gMSA.
• Cluster e nós do GKE. O cluster do GKE neste tutorial tem um conjunto de nós do Linux e um conjunto de nós do Windows Server que são usados das seguintes formas:
  • Os nós Linux executam componentes do sistema que só são executados nos sistemas operativos Linux, como o servidor de métricas do GKE.
  • Os nós do Windows Server são usados para alojar contentores do Windows Server e estão associados a um domínio do Active Directory.
• Infraestrutura do Active Directory. Para que os nós do GKE Windows sejam associados a um domínio, primeiro, execute o tutorial Configurar o Active Directory para que as VMs sejam automaticamente associadas a um domínio. Nesse tutorial, cria um serviço do Cloud Run responsável por registar novos computadores (instâncias) no Active Directory e fornecer a cada nova instância uma palavra-passe temporária que a instância usa para concluir o processo de associação ao domínio. Cada nova instância no conjunto de nós do Windows Server chama o serviço do Cloud Run para se juntar ao domínio do Active Directory.
• Balanceador de carga de rede. Quando um utilizador no local abre o navegador e navega para a aplicação Web ASP.NET, o tráfego passa por um equilibrador de carga de rede. O balanceador de carga é criado pelo GKE quando cria um serviço LoadBalancer do GKE para a sua aplicação Web. O utilizador também se autentica na aplicação Web transmitindo as respetivas credenciais do Active Directory à aplicação Web.

Criar a infraestrutura

Depois de concluir o tutorial relacionado, cria os componentes de infraestrutura para o tutorial atual, que incluem o seguinte:

• Uma VM do Windows Server com uma imagem de contentor de aplicação Web ASP.NET.
• Um cluster do GKE com um node pool 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 gMSA em implementações.

Crie uma VM de desenvolvimento

A imagem do contentor do Windows Server que criar tem de corresponder à versão do Windows Server da VM onde cria a imagem do contentor. Esta versão também tem de corresponder à versão do Windows Server dos seus nós do Windows Server do GKE. A criação de uma imagem de contentor ou a execução de um contentor numa versão diferente do Windows Server resulta num erro. Para mais informações sobre os requisitos de compatibilidade dos contentores Windows, consulte o artigo Fazer corresponder a versão do anfitrião do contentor com as versões da imagem do contentor.

Este tutorial usa a versão 2022 do Long-Term Servicing Channel (LTSC) do Windows Server para a VM, os nós do Windows Server no GKE e a imagem do contentor. Para mais informações, consulte o artigo sobre a mapeamento de versões entre as versões do Windows Server e as versões do GKE.

1. In the Trusted Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Trusted Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Se o PowerShell estiver aberto, feche-o escrevendo exit.

3. Defina as variáveis de ambiente para o nome da rede e da sub-rede, bem como 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 o seguinte:

   • NETWORK-NAME: a rede VPC na qual implementar as VMs.
   • SUBNETWORK-NAME: a sub-rede na qual implementar as VMs.
   • AD-JOIN-SERVICE-URL: o URL do serviço do Cloud Run que implementou na secção Antes de começar.

4. Defina o Trusted Cloud ID do projeto e a região para o ambiente atual:

   gcloud config set project PROJECT-ID
   gcloud config set compute/zone ZONE-NAME
   

   Substitua o seguinte:

   • PROJECT-ID: o ID do seu Trusted Cloud projeto.
   • ZONE-NAME: a zona na qual implementar todas as VMs. Para reduzir a latência, recomendamos que selecione uma zona na mesma região onde implementou o serviço do Cloud Run de associação ao domínio do Active Directory.

5. 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.s3ns.iam.gserviceaccount.com
   
   gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \
       --display-name="Development VM Service Account"
   

6. 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"
   

7. 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"
   

   É concedida à conta de serviço a função container.admin porque esta função tem autorizações para criar clusters do GKE no projeto e gerir recursos em clusters, incluindo recursos de controlo de acesso baseado em funções (RBAC). Os recursos RBAC são necessários para controlar que Pod tem autorização para usar um gMSA.

8. 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"
   

   Se planeia implementar as suas aplicações em contentores no Windows Server 2019, altere o valor do parâmetro --image-family para windows-2019-core-for-containers.

   O âmbito https://www.googleapis.com/auth/cloud-platformpermite que a instância aceda a todas as Trusted Cloud APIs, consoante as funções do IAM definidas para a conta de serviço da instância.

   A VM é criada com um endereço IP externo para lhe permitir comunicar com a Internet. A VM precisa de ter acesso à Internet para poder transferir várias utilidades, como o git e o kubectl, e para transferir a aplicação Web ASP.NET do GitHub.

   Durante a fase sysprep, a nova instância é associada ao domínio do Active Directory para lhe permitir aceder remotamente à instância através da sua conta de domínio. O script no comando sysprep também instala o módulo do PowerShell para o Active Directory.

Crie um repositório Docker do Artifact Registry

1. No Cloud Shell, defina a localização predefinida para novos repositórios do Artifact Registry:

   gcloud config set artifacts/location LOCATION
   

   Substitua LOCATION por uma region onde quer criar o repositório do Artifact Registry. Para reduzir a latência, recomendamos que selecione a mesma região onde implementou a VM de desenvolvimento.

2. Crie o repositório Docker do Artifact Registry:

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

Crie um cluster do GKE

1. No Cloud Shell, defina uma variável de ambiente para o nome do cluster do GKE:

   export GKE_CLUSTER_NAME=cluster-1
   

2. Crie o cluster do GKE:

   gcloud container clusters create $GKE_CLUSTER_NAME \
       --release-channel rapid \
       --network $NETWORK_NAME \
       --subnetwork $SUBNETWORK_NAME \
       --enable-ip-alias
   

   Definir o parâmetro --release-channel como rapid implementa o cluster do GKE com a versão mais recente do Kubernetes. O parâmetro --enable-ip-alias ativa o IP de alias. O IP de alias é obrigatório para nós do Windows Server.

Crie um node pool do Windows Server no GKE

Quando cria um novo cluster do GKE através da CLI, o cluster é criado com um conjunto de nós do Linux. Para usar o Windows Server no GKE, crie um node pool do Windows Server.

Os clusters do GKE têm de ter, pelo menos, um nó Linux para executar os contentores internos (do sistema) do cluster. Não é possível criar um cluster do GKE apenas com nós do Windows Server.

1. No Cloud Shell, defina uma variável de ambiente para o nome do conjunto de nós do servidor Windows:

   export NODE_POOL_NAME=windows-server-pool
   

2. Crie um node pool do Windows Server do GKE:

   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 planeia implementar as suas aplicações em contentores no Windows Server 2019, altere o parâmetro --windows-os-version para ltsc2019.

   A chave de metadados sysprep-specialize-script-ps1 é uma chave incorporada que aponta para um script do PowerShell executado durante o passo GCESysprep antes de a instância ser iniciada pela primeira vez.

   O cmdlet iex transfere o script do PowerShell do serviço de associação ao domínio do Active Directory que implementou no Cloud Run. Em seguida, executa o script que associa a nova instância ao domínio do Active Directory.

   O parâmetro --no-enable-autoupgrade desativa a atualização automática de nós para todos os nós no conjunto. Isto acontece porque a atualização de uma 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 o artigo Atualizar pools de nós do Windows Server.

   Depois de cada nó ser criado, o script do domain-joinPowerShell junta o nó ao domínio.

3. Aguarde vários minutos até que o conjunto de nós seja criado e, em seguida, execute o comando seguinte para verificar se todos os nós aderiram ao 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 associados ao domínio, o resultado é o 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 quiser ver o resultado do script completo, remova .*success do comando grep.

Conceda aos pods do GKE acesso ao Active Directory

Tem de criar uma regra de firewall que permita que os pods do cluster do GKE acedam aos controladores de domínio através dos 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)
• LDAP GC (TCP/3268)
• Serviços Web do Active Directory (TCP/9389)

Pode aplicar a regra com base numa conta de serviço que atribuiu aos controladores de domínio ou pode aplicá-la através de uma etiqueta de rede, como é feito neste tutorial. Para saber mais sobre as portas relacionadas com o Active Directory, consulte a documentação sobre os requisitos de portas e protocolos do Active Directory e a utilização do Active Directory em firewalls.

Se estiver a usar o Serviço gerido para o Microsoft Active Directory (Microsoft AD gerido), pode ignorar este procedimento.

1. No Cloud Shell, obtenha o intervalo de endereços IP dos pods do cluster do GKE:

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

2. Crie uma regra de firewall para dar 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 etiqueta de rede atribuída às VMs dos controladores de domínio.

Configure o GKE para suportar a utilização de gMSAs

Para usar uma gMSA em nós do Windows Server, tem de criar o objeto gMSA no Active Directory, criar um recurso gMSA correspondente no GKE e permitir que os pods recém-criados obtenham as respetivas credenciais gMSA.

1. No Cloud Shell, transfira e execute o script do webhook gMSA:

   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 recursos personalizados (CRD) gMSA ao cluster do GKE e implementa um webhook que fornece as especificações do gMSA aos pods. Agora, pode armazenar especificações de gMSA no cluster e configurar gMSAs para pods e contentores.

   Para saber mais sobre o Kubernetes e os gMSAs, consulte o artigo Configure o GMSA para pods e contentores do Windows.

O cluster do GKE já está pronto para executar aplicações Windows que requerem a utilização de uma gMSA. Por exemplo, pode executar uma aplicação Web ASP.NET nos seus nós do Windows Server. Pode configurar a aplicação para iniciar sessão nos utilizadores com a autenticação do Windows ou fazer com que a aplicação use o gMSA do pod para aceder a uma partilha de rede remota ou a uma base de dados do SQL Server.

Integração com o Active Directory

Em seguida, cria um gMSA para a sua aplicação Web ASP.NET no Active Directory, configura como pode ser usado e por quem e, depois, adiciona a respetiva configuração ao GKE.

Inicie sessão e inicie o PowerShell

1. Estabeleça ligação à VM gmsa-dev-vm.

2. Inicie sessão no Windows com uma conta do Active Directory que tenha autorização para criar um gMSA.

   A sua conta tem de ser membro do grupo Domain Admins ou tem de poder criar objetos msDS-GroupManagedServiceAccount. Para mais informações, consulte o artigo Aprovisionar contas de serviço geridas de grupo.

   Se usar o Microsoft AD gerido, a sua conta tem de ser membro do grupo Cloud Service Managed Service Account Administrators. Para mais informações, consulte o artigo Delegue a administração de contas de serviço geridas.

3. Escreva 15 para sair do menu para a linha de comandos (PowerShell).

Instale um tempo de execução de contentores

O Windows Server 2022 requer um tempo de execução de contentores, como o Docker Community Edition (CE), para criar e executar contentores Windows. Para mais informações sobre a instalação de um tempo de execução de contentores no Windows Server, consulte o artigo Introdução: prepare o Windows para contentores na documentação da Microsoft.

Se criou a VM de desenvolvimento com a imagem windows-2019-core-for-containers, pode ignorar o procedimento seguinte, porque a imagem já tem o Docker instalado.

1. 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, durante o processo de instalação, a ligação ao ambiente de trabalho remoto for fechada, volte a ligar-se à VM.

2. Aguarde pela conclusão do processo de instalação e, em seguida, escreva exit para fechar a nova janela do PowerShell.

3. Escreva 15 para sair do menu para a linha de comandos (PowerShell).

Crie uma chave raiz do KDS

Antes de criar um gMSA, tem de se certificar de que 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 principal do KDS para gerar palavras-passe para gMSAs.

Se estiver a usar o Managed Microsoft AD, pode ignorar o procedimento seguinte, porque o Managed Microsoft AD cria a chave principal do KDS quando cria o domínio.

1. No gmsa-dev-vm, verifique se o Active Directory já tem a chave raiz do KDS:

   Get-KdsRootKey
   

   Este comando apresenta o ID da chave, se existir.

2. Se não receber um ID da chave em resposta, crie a chave:

   Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
   

Crie o gMSA

Quando cria um gMSA, tem de indicar os nomes dos computadores que têm acesso ao gMSA. Como prática recomendada de segurança, deve conceder autorização à gMSA apenas às instâncias onde a sua aplicação é executada. Quando cria um node pool do Windows Server associado a um domínio, é criado um novo grupo do Active Directory para os computadores do node pool. O nome do grupo corresponde ao nome do grupo de instâncias geridas (MIG) que o GKE cria para o conjunto de nós.

1. No PowerShell, defina variáveis para o Trusted Cloud ID do projeto, o nome do cluster, o nome do conjunto de nós do Windows, o nome do gMSA e o nome do 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 seu Trusted Cloud projeto.

2. 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 onde implementou o cluster do GKE.

3. Recupere o nome do domínio do grupo do Active Directory que foi criado para o conjunto 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
   

4. Crie o gMSA:

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

5. Verifique se a gMSA foi criada:

   Get-ADServiceAccount -Identity $GmsaName
   

   Se o gMSA foi criado, o resultado é semelhante ao seguinte:

   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 :
   

Adicione o gMSA ao GKE

Para usar um gMSA num cluster do Kubernetes, tem de criar um recurso gMSA no Kubernetes e configurar que espaços de nomes e contas têm autorização para o usar.

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

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

2. 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"
   

3. Instale o ficheiro binário gke-gcloud-auth-plugin:

   gcloud components install gke-gcloud-auth-plugin
   

   Aguarde vários minutos até que o processo de instalação termine.

4. Inicialize a ferramenta kubectl com as credenciais do cluster do GKE:

   gcloud container clusters get-credentials $GkeClusterName
   

5. Crie o ficheiro de especificação das credenciais 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 tem de usar carateres em minúsculas.

   O script altera a capitalização da variável $GmsaName para estar em conformidade com esta restrição.

   O script apresenta uma mensagem de aviso a indicar que o teste da conta de serviço gerido falhou, o que é esperado. A sua VM de desenvolvimento não é membro do grupo atribuído ao gMSA e, por isso, não pode testar o gMSA a partir da VM. A mensagem de aviso não impede que o comando gere a especificação das credenciais do gMSA.

6. Adicione a especificação das credenciais de gMSA ao cluster do GKE:

   kubectl apply -f $CredSpecFile
   

7. Clone o repositório do GitHub:

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd kubernetes-engine-samples/windows/aspnet-gmsa/
   

8. Adicione os objetos CABF gMSA ao seu cluster:

   kubectl apply -f gmsa-rbac-webapp-01.yaml
   

   O gmsa-rbac-webapp-01.yaml cria um objeto CABF para o gMSA e, em seguida, associa a nova função de cluster à conta de serviço predefinida no espaço de nomes default.ClusterRole Se estiver a implementar a sua aplicação num espaço de nomes diferente, edite o ficheiro gmsa-rbac-webapp-01.yaml e altere o espaço de nomes para a associação de funções e para a conta de serviço.

Implementar e usar a aplicação Web

Em seguida, cria a aplicação Web e a imagem do contentor, implementa a nova imagem do contentor no cluster do GKE e abre a aplicação Web no navegador para verificar se a aplicação Web pode usar o gMSA.

Crie e implemente a aplicação Web ASP.NET

1. No gmsa-dev-vm, no PowerShell, defina as variáveis para a localização do registo, o nome do registo e a etiqueta da imagem:

   $RegistryLocation = "LOCATION-docker.pkg.dev"
   $ProjectsRegistry = "$RegistryLocation/$ProjectId"
   $ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
   

   Substitua LOCATION pela localização onde criou o repositório do Artifact Registry.

2. Crie a imagem de contentor:

   docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
   

   Para criar imagens de contentores para o Windows Server 2019, defina o valor do parâmetro -f como Dockerfile-WINDOWS_LTSC2019.

3. Envie a imagem de contentor para o Artifact Registry:

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

4. Transfira o ficheiro YAML da aplicação e atualize-o com a configuração da 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 criar nós do Windows Server 2019 no GKE, edite o ficheiro YAML da aplicação e altere o valor de cloud.google.com/gke-windows-os-version de 2022 para 2019.

5. Implemente a aplicação Web no seu cluster do GKE:

   kubectl apply -f $ApplicationYaml
   

Verifique se a aplicação Web ASP.NET está em execução

A aplicação Web está exposta à Internet através de um serviço LoadBalancer. Antes de poder navegar para a aplicação Web, tem de aguardar a implementação do pod e do serviço. A implementação do pod pode demorar vários minutos porque as imagens do contentor do Windows Server Core são grandes (a imagem da aplicação Web é superior a 7 GB) e o nó demora algum tempo a transferir a imagem e a criar o contentor.

1. Verifique o estado do Pod:

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

   Repita o comando até o resultado mostrar que o estado do pod é Em execução:

   NAME                                   READY     STATUS    RESTARTS   AGE
   gmsa-test-webapp-01-76c6d64975-zrtgq   1/1       Running   0          28s
   

   Se o estado do Pod permanecer Pendente e não mudar para ContainerCreating ou Running, verifique a imagem de origem do seu nó do Windows para se certificar de que é o Windows Server 2022. Também pode consultar 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 corresponderem, duplique o ficheiro Dockerfile-WINDOWS_LTSC2022, defina a imagem do contentor base no novo ficheiro para corresponder à versão do Windows Server dos seus nós e, de seguida, repita os passos para criar e implementar a aplicação Web ASP.NET.

2. Verifique o estado do serviço:

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

   Repita o comando até que o resultado 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
   

3. Tome nota do valor external-ip no resultado. Vai precisar deste valor mais tarde.

Execute testes preliminares na aplicação Web ASP.NET

O pod está agora em execução e é acessível a partir da Internet através de um balanceador de carga de rede. Em seguida, execute testes preliminares para verificar se o contentor foi implementado com êxito e se tem autorizações para usar a gMSA.

1. Num navegador, aceda a http://EXTERNAL-IP para ver a aplicação Web de teste gMSA.

   Substitua EXTERNAL-IP pelo endereço IP que obteve no procedimento anterior.

2. Desloque a página até à secção Verificações prévias e, de seguida, clique no botão Executar verificações prévias para verificar se todos os testes foram aprovados.

   Se os testes forem aprovados, o resultado é o 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.
   

3. Desloque a página até à secção Informações do contentor e, de seguida, clique no botão Executar script. Verifique se vê informações sobre o contentor e o nó, e se não é apresentado nenhum erro.

Use a gMSA em contentores do Windows

Agora, pode verificar se a configuração da gMSA está a funcionar corretamente executando vários testes na aplicação Web. Cada um dos testes usa o gMSA para um objetivo diferente. Se todos os testes forem bem-sucedidos, significa que configurou a gMSA corretamente.

Valide a configuração do contentor gMSA

• Desloque a página até à secção Conetividade do domínio, escreva o nome do seu gMSA (WebApp-01) na caixa Nome da conta e, de seguida, clique em Executar script. Aguarde alguns segundos para que os testes terminem.

  O resultado é semelhante ao seguinte:

  *****   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 obtém informações sobre um gMSA. Se este cmdlt for executado com êxito, o contentor está a ser executado com um gMSA válido.
  • Test-ADServiceAccount: Este cmdlet testa se consegue obter as credenciais da gMSA. Se o comando for executado com êxito, significa que o contentor está a ser executado num nó do Windows Server que tem autorização para aceder às credenciais da gMSA.

Permita que os utilizadores iniciem sessão com a autenticação do Windows

1. Na barra de navegação superior da página, clique em Iniciar sessão.
2. Quando lhe for pedido que introduza as suas credenciais, introduza o nome de utilizador e a palavra-passe do domínio.

3. Se vir a página Seguro com as informações da sua conta e não lhe for pedido que introduza credenciais, significa que o navegador iniciou sessão automaticamente com a sua identidade atual.

   Depois de se autenticar, vê a página Seguro. Certifique-se de que vê as três secções seguintes:

   • Informações do utilizador: apresenta o seu nome de utilizador e o tipo de autenticação que foi usado.
   • Grupos: apresenta a lista de grupos aos quais pertence. Os nomes dos grupos na lista são obtidos a partir do Active Directory.
   • Reivindicações do utilizador: apresenta a lista de reivindicações do utilizador, conforme fornecidas pelo Active Directory durante o início de sessão. As reivindicações de associação a grupos mostram o grupo do Active Directory SID, e não os respetivos nomes.

Além de suportar a autenticação integrada do Windows, a aplicação Web ASP.NET pode usar a respetiva gMSA para autenticação quando chama servidores remotos. Com a gMSA, a aplicação Web e qualquer outra aplicação em execução no contentor do Windows podem aceder a recursos na rede que requerem autenticação do Windows, como instâncias do SQL Server e partilhas de rede baseadas em SMB.

Resolução de problemas

Se encontrar mensagens de erro durante o processo de configuração ou ao testar a aplicação Web, consulte as seguintes páginas de resolução de problemas:

• Resolução de problemas do Windows Server no GKE
• Documentação do Kubernetes sobre a resolução de problemas de contentores do Windows Server
• Documentação da Microsoft sobre a resolução de problemas de gMSAs para contentores Windows

Considerações adicionais para aplicações de produção

As instruções que seguiu foram escritas para oferecer um caminho ideal para fins do tutorial. Para um ambiente de produção, pode fazer alterações a alguns dos procedimentos para tornar o resultado mais robusto, conforme descrito nas secções seguintes.

Considerações sobre o node pool do Windows Server

Se planeia implementar a sua própria aplicação que usa um gMSA e a aplicação suporta sessões de cliente, recomendamos que crie, pelo menos, dois nós no conjunto de nós. Ter vários nós permite-lhe usar o armazenamento de sessões fora do processo para verificar se a sua aplicação consegue processar corretamente as sessões distribuídas.

Neste tutorial, cria um único conjunto de nós do Windows Server para alojar as suas aplicações. No entanto, podem existir situações em que queira criar vários conjuntos de nós do Windows Server no seu cluster, por exemplo, um conjunto de nós com discos persistentes (DPs) de HDD e outro conjunto de nós com DPs de SSD. Se precisar de implementar a sua aplicação em vários conjuntos de nós, forneça uma matriz de objetos de grupo do Active Directory ao parâmetro PrincipalsAllowedToRetrieveManagedPassword quando criar o gMSA com o cmdlet New-ADServiceAccount.

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

Se a sua aplicação exigir que autentique os utilizadores através do Kerberos (por exemplo, para suportar a delegação de identidade), tem de aceder à sua aplicação através de um DNS personalizado e configurar o gMSA com um nome principal do serviço (SPN). Por exemplo, se o balanceador de carga expuser a aplicação no GKE através de https://my-web-app/, tem de criar um SPN denominado HTTP/my-web-app de uma das seguintes formas:

• Para um novo gMSA, crie o gMSA com os SPNs necessários. Por exemplo:

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

• Para um gMSA existente, ligue para Set-ADServiceAccount para adicionar os SPNs necessários ao gMSA. Por exemplo:

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

Consoante a configuração de DNS, também pode ter de 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 a associação TCP e a autenticação do Windows, pode ter de criar outros tipos de SPNs, como um SPN HOST/.

Escolher a identidade do conjunto de aplicações do IIS

As aplicações Web ASP.NET são executadas no Windows no servidor Web IIS. No IIS, pode configurar grupos de aplicações Web que partilham o mesmo processo. Este grupo é denominado pool de aplicações. Cada conjunto de aplicações está alojado num processo dedicado denominado w3wp. Os conjuntos de aplicações do IIS fornecem a configuração do processo, como se o processo é de 32 ou 64 bits, e fornecem a identidade do processo. Quando executa uma aplicação Web num contentor do Windows, define a identidade do processo do conjunto de aplicações para usar a conta Serviço de rede integrada.

As contas de identidade do conjunto de aplicações locais, que o IIS também suporta, não são necessárias em contentores Windows. As contas de identidade do conjunto de aplicações foram criadas pelo IIS como um meio de aplicar um limite de segurança local quando executa várias aplicações Web na mesma instância do IIS. Com os contentores do Windows, em que cada aplicação Web está alojada num contentor separado, não é necessário criar um limite de segurança no contentor, porque o próprio contentor fornece o limite de segurança.

Embora a identidade do conjunto de aplicações esteja configurada para usar a conta Network Service, se a aplicação fizer um pedido a um recurso externo que exija autenticação, a aplicação autentica-se através da gMSA que configurou para o contentor Windows.