Skip to content

Commit 0fb422c

Browse files
DonatoHornDonatoHorn
authored
[pt-br] Add docs/tasks/configure-pod-container/configure-gmsa.md (#35109)
* [pt-br] add content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] add content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] add content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] Add content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md Signed-off-by: [email protected] <[email protected]> * [pt-br] Add content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] add docs/tasks/configure-pod-container/configure-gmsa.md * [pt-br] Add docs/tasks/configure-pod-container/configure-gmsa.md --------- Signed-off-by: [email protected] <[email protected]>
1 parent 6b5c569 commit 0fb422c

File tree

1 file changed

+352
-0
lines changed

1 file changed

+352
-0
lines changed

‎content/pt-br/docs/tasks/configure-pod-container/configure-gmsa.md

Lines changed: 352 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,352 @@
1+
---
2+
title: Configurando GMSA Para Pods e Contêineres Windows
3+
content_type: task
4+
weight: 20
5+
---
6+
7+
<!-- overview -->
8+
9+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
10+
11+
Esta página mostra como configurar [Contas de serviço gerenciadas em grupo](https://docs.microsoft.com/pt-br/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA)
12+
para Pods e contêineres que vão executar em nós Windows. Contas de serviço gerenciadas em grupo
13+
são um tipo específico de conta do Active Directory que provê gerenciamento automático
14+
de senhas, gerenciamento simplificado de *service principal name* (SPN), e a habilidade
15+
de delegar o gerenciamento a outros administradores através de múltiplos servidores.
16+
17+
No Kubernetes, especificações de credenciais GMSA são configuradas dentro do escopo
18+
do cluster Kubernetes como recursos personalizados. Os Pods Windows, assim como contêineres
19+
individuais dentro de um Pod, podem ser configurados para usar as funções GMSA
20+
baseadas em domínio (exemplo: autenticação Kerberos) quando interagirem com outros
21+
serviços Windows.
22+
23+
## {{% heading "prerequisites" %}}
24+
25+
Você precisa ter um cluster Kubernetes, e a ferramenta de linha de comando `kubectl`
26+
precisa estar configurada para comunicar-se com seu cluster.
27+
O cluster deve possuir nós de carga de trabalho Windows.
28+
Esta seção cobre o conjunto inicial de passos requeridos para cada cluster:
29+
30+
### Instale o CRD GMSACredentialSpec
31+
32+
Uma [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) (CRD) para a especificação de recursos de credencial GMSA precisa ser configurada no cluster, para definir o tipo de recurso do cliente `GMSACredentialSpec`. Faça o download do [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) do CRD de GMSA
33+
e salve como gmsa-crd.yaml.
34+
A seguir, instale o CRD com `kubectl apply -f gmsa-crd.yaml`.
35+
36+
### Instale webhooks para validar usuários GMSA
37+
38+
Dois webhooks precisam ser configurados no cluster Kubernetes para popular e validar
39+
as referências de especificação de credenciais GMSA no nível do Pod ou contêiner:
40+
41+
1. Um webhook de mutação que expanda as referências para as GMSAs,
42+
(por nome a partir de uma especificação de Pod) em uma especificação de credencial completa
43+
em formato JSON dentro da especificação do Pod.
44+
45+
1. Um webhook de validação garante que todas as referências para GMSAs estão
46+
autorizadas a serem usadas pela conta de serviço do Pod.
47+
48+
A instalação dos webhooks acima e dos objetos associados requer as etapas abaixo:
49+
50+
1. Crie um par de chaves de certificado (que será usado para permitir que o
51+
contêiner do webhook se comunique com o cluster)
52+
53+
1. Instale um Secret com o certificado acima.
54+
55+
1. Crie um Deployment para a lógica principal do webhook.
56+
57+
1. Crie as configurações de webhook de validação e de mutação, referentes ao Deployment.
58+
59+
Um [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)
60+
pode ser usado para implantar e configurar os webhooks GMSA e objetos associados
61+
mencionados acima. O script pode ser executado com a opção ```--dry-run=server```
62+
para possibilitar que você possa revisar as alterações antes que sejam aplicadas
63+
no seu cluster.
64+
65+
O [template YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)
66+
usado pelo script também pode ser usado para implantar os webhooks e objetos
67+
associados manualmente (com as substituições apropriadas para os parâmetros).
68+
69+
<!-- steps -->
70+
71+
## Configurar GMSAs e nós Windows em Active Directory
72+
73+
Antes que os Pods no Kubernetes possam ser configurados para usar GMSAs, as GMSAs apropriadas precisam ser provisionadas no Active Directory como descrito na
74+
[documentação de GMSA do Windows](https://docs.microsoft.com/pt-br/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1).
75+
Nós de carga de trabalho Windows (que são parte do cluster Kubernetes) precisam ser configurados no
76+
Active Directory para acessar as credenciais secretas associadas com a GMSA apropriada,
77+
como descrito na [documentação de GMSA do Windows](https://docs.microsoft.com/pt-br/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet).
78+
79+
## Crie recursos de especificação de GMSA
80+
81+
Com o CRD GMSACredentialSpec instalado (como descrito anteriormente),
82+
recursos customizados contendo recursos de especificação de credenciais GMSA podem
83+
ser configurados. A especificação de credencial GMSA não contém dados secretos nem
84+
sensíveis. É informação que o agente de execução de contêiner pode usar para descrever a apropriada
85+
GMSA de um contêiner para o Windows. Especificações de credenciais GMSA podem
86+
ser geradas em formato YAML com o utilitário [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).
87+
88+
A seguir são os passos para gerar a especificação de credencial GMSA YAML
89+
manualmente, em formato JSON e então convertê-la para YAML:
90+
91+
1. Importar o [módulo `CredentialSpec`](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1):
92+
`ipmo CredentialSpec.psm1`
93+
94+
1. Crie a especificação da credencial em formato JSON usando `New-CredentialSpec`.
95+
Para criar a especificação da credencial GMSA nomeada WebApp1,
96+
execute `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`
97+
98+
1. Use `Get-CredentialSpec` para mostrar o caminho do arquivo JSON.
99+
100+
1. Converta o arquivo `credspec` de JSON para o formato YAML e aplique os campos
101+
de cabeçalho necessários `apiVersion`, `kind`, `metadata` e `credspec` para transformá-lo em
102+
uma instância do recurso customizado GMSACredentialSpec que pode ser configurado no Kubernetes.
103+
104+
A configuração YAML a seguir descreve as especificações de credencial GMSA nomeada
105+
`gmsa-WebApp1`:
106+
107+
```yaml
108+
apiVersion: windows.k8s.io/v1
109+
kind: GMSACredentialSpec
110+
metadata:
111+
name: gmsa-WebApp1 #Este é um nome arbitrário, mas será usado como referência
112+
credspec:
113+
ActiveDirectoryConfig:
114+
GroupManagedServiceAccounts:
115+
- Name: WebApp1 #Nome de usuário da conta GMSA
116+
Scope: CONTOSO #Nome de Domínio NETBIOS
117+
- Name: WebApp1 #Nome de usuário da conta GMSA
118+
Scope: contoso.com #Nome de domínio DNS
119+
CmsPlugins:
120+
- ActiveDirectory
121+
DomainJoinConfig:
122+
DnsName: contoso.com #Nome de domínio DNS
123+
DnsTreeName: contoso.com #Nome de domínio DNS raiz
124+
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID
125+
MachineAccountName: WebApp1 #Nome de usuário da conta GMSA
126+
NetBiosName: CONTOSO #Nome de domínio NETBIOS
127+
Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID da GMSA
128+
```
129+
130+
O recurso de especificação de credencial acima deve ser salvo como
131+
`gmsa-Webapp1-credspec.yaml` e aplicado no cluster usando:
132+
`kubectl apply -f gmsa-Webapp1-credspec.yml`
133+
134+
## Configure um ClusterRole para habilitar RBAC nas especificações de credenciais GMSA específicas
135+
136+
Uma ClusterRole precisa ser definida para cada recurso de especificação
137+
de credencial GMSA. Isto autoriza o verbo `use` em um recurso GMSA específico
138+
por um sujeito, geralmente uma conta de serviço. O exemplo a seguir mostra
139+
um ClusterRole que autoriza o uso de credencial `gmsa-WebApp1`
140+
acima. Salve o arquivo como gmsa-webapp1-role.yaml e aplique
141+
usando `kubectl apply -f gmsa-webapp1-role.yaml`
142+
143+
```yaml
144+
#Criando um Role para ler o credspec
145+
apiVersion: rbac.authorization.k8s.io/v1
146+
kind: ClusterRole
147+
metadata:
148+
name: webapp1-role
149+
rules:
150+
- apiGroups: ["windows.k8s.io"]
151+
resources: ["gmsacredentialspecs"]
152+
verbs: ["use"]
153+
resourceNames: ["gmsa-WebApp1"]
154+
```
155+
156+
## Atribua o Role às contas de serviço para usar especificações de credencial GMSA específicas
157+
158+
Uma conta de serviço (com a qual os Pods virão configurados), precisa ser vinculada
159+
ao ClusterRole criado acima. Isto autoriza a conta de serviço a usar a especificação apropriada
160+
de recurso de credencial GMSA. O trecho a seguir mostra a conta de serviço padrão vinculada ao ClusterRole `webapp1-role`, para usar a especificação
161+
de recurso de credencial `gmsa-WebApp1` criada acima.
162+
163+
```yaml
164+
apiVersion: rbac.authorization.k8s.io/v1
165+
kind: RoleBinding
166+
metadata:
167+
name: allow-default-svc-account-read-on-gmsa-WebApp1
168+
namespace: default
169+
subjects:
170+
- kind: ServiceAccount
171+
name: default
172+
namespace: default
173+
roleRef:
174+
kind: ClusterRole
175+
name: webapp1-role
176+
apiGroup: rbac.authorization.k8s.io
177+
```
178+
179+
## Configure a especificação de recurso de credencial GMSA em uma especificação de Pod
180+
181+
O campo `securityContext.windowsOptions.gmsaCredentialSpecName` do Pod, é usado de referência para recursos customizados, em especificações
182+
de certificado GMSA apropriadas em especificações do Pod.
183+
Isto configura todos contêineres do Pod para usar GMSA.
184+
Uma amostra da anotação populada para referir-se a `gmsa-WebApp1`:
185+
186+
```yaml
187+
apiVersion: apps/v1
188+
kind: Deployment
189+
metadata:
190+
labels:
191+
run: with-creds
192+
name: with-creds
193+
namespace: default
194+
spec:
195+
replicas: 1
196+
selector:
197+
matchLabels:
198+
run: with-creds
199+
template:
200+
metadata:
201+
labels:
202+
run: with-creds
203+
spec:
204+
securityContext:
205+
windowsOptions:
206+
gmsaCredentialSpecName: gmsa-webapp1
207+
containers:
208+
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
209+
imagePullPolicy: Always
210+
name: iis
211+
nodeSelector:
212+
kubernetes.io/os: windows
213+
```
214+
215+
Contêineres individuais em uma especificação de Pod podem também indicar
216+
a credencial GMSA apropriada, usando o campo `securityContext.windowsOptions.gmsaCredentialSpecName` por contêiner. Por exemplo:
217+
218+
```yaml
219+
apiVersion: apps/v1
220+
kind: Deployment
221+
metadata:
222+
labels:
223+
run: with-creds
224+
name: with-creds
225+
namespace: default
226+
spec:
227+
replicas: 1
228+
selector:
229+
matchLabels:
230+
run: with-creds
231+
template:
232+
metadata:
233+
labels:
234+
run: with-creds
235+
spec:
236+
containers:
237+
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
238+
imagePullPolicy: Always
239+
name: iis
240+
securityContext:
241+
windowsOptions:
242+
gmsaCredentialSpecName: gmsa-Webapp1
243+
nodeSelector:
244+
kubernetes.io/os: windows
245+
```
246+
247+
Assim que as especificações do Pod com os campos GMSA preenchidos
248+
(como descrito acima) são aplicadas em um cluster, ocorre a seguinte sequência de eventos:
249+
250+
1. O webhook de mutação resolve e expande todas as referências aos recursos de
251+
especificações de credenciais GMSA para o conteúdo das especificações de credenciais GMSA.
252+
253+
1. O webhook de validação garante que a conta de serviço associada ao Pod, seja autorizada
254+
para o verbo `use` na especificação GMSA especificada.
255+
256+
1. O agente de execução de contêiner configura cada contêiner do Windows com a especificação
257+
de credencial GMSA especificada, para que o contêiner possa assumir a identidade
258+
do GMSA no Active Directory, e tenha acesso aos serviços no domínio usando essa identidade.
259+
260+
## Autenticando para compartilhamentos de rede usando `hostname` ou FQDN
261+
262+
Se você estiver enfrentando problemas ao se conectar aos compartilhamentos SMB
263+
de Pods usando o hostname ou o FQDN, mas conseguindo acessar os compartilhamentos
264+
por meio de seu endereço IPv4, verifique se a chave do registro a seguir
265+
está definida nos nós Windows.
266+
267+
```cmd
268+
reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
269+
```
270+
271+
Os Pods em execução precisarão ser recriados para pegar as mudanças de comportamento.
272+
Mais informações sobre como essa chave de registro é usada podem ser encontradas [aqui](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)
273+
274+
## Solução de problemas
275+
276+
Se você estiver tendo dificuldades para fazer com que o GMSA funcione em seu ambiente,
277+
existem algumas etapas de solução de problemas que você pode tentar.
278+
279+
Primeiro, verifique se a especificação de credencial foi passada para o Pod. Para fazer isso,
280+
você precisará rodar `kubectl exec` em um de seus Pods e verificar
281+
a saída do comando `nltest.exe /parentdomain`.
282+
283+
No exemplo abaixo, o Pod não recebeu a especificação de credencial corretamente:
284+
285+
```PowerShell
286+
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
287+
```
288+
289+
`nltest.exe /parentdomain` resulta no seguinte erro:
290+
291+
```output
292+
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
293+
```
294+
295+
Se o seu Pod obteve a especificação de credencial corretamente, o próximo passo é
296+
verificar a comunicação com o domínio. Primeiro, de dentro do seu Pod,
297+
execute rapidamente um `nslookup` para encontrar a raiz do seu domínio.
298+
299+
Isso vai nos dizer 3 coisas:
300+
301+
1. O Pod pode chegar ao DC
302+
1. O DC pode chegar ao Pod
303+
1. O DNS está funcionando corretamente.
304+
305+
Se o DNS e o teste de comunicação passarem, em seguida,
306+
você precisará verificar se o Pod estabeleceu um canal de comunicação segura
307+
com o domínio. Para fazer isso, novamente, em seu Pod
308+
execute o comando `nltest.exe /query`.
309+
310+
```PowerShell
311+
nltest.exe /query
312+
```
313+
314+
Resulta na seguinte saída:
315+
316+
```output
317+
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
318+
```
319+
320+
Isso nos diz que, por algum motivo, o Pod não conseguiu se logar no domínio
321+
usando a conta definida na especificação de credencial. Você pode tentar reparar
322+
o canal seguro executando o seguinte:
323+
324+
```PowerShell
325+
nltest /sc_reset:domain.example
326+
```
327+
328+
Se o comando for bem sucedido, você verá uma saída semelhante a esta:
329+
330+
```output
331+
Flags: 30 HAS_IP HAS_TIMESERV
332+
Trusted DC Name \\dc10.domain.example
333+
Trusted DC Connection Status Status = 0 0x0 NERR_Success
334+
The command completed successfully
335+
```
336+
337+
Se o excerto acima corrigir o erro, você poderá automatizar a etapa adicionando
338+
o seguinte `lifecycle hook` à sua especificação de Pod. Se não corrigiu o erro, você
339+
precisará examinar sua especificação de credencial novamente e confirmar que ela está correta e completa.
340+
341+
```yaml
342+
image: registry.domain.example/iis-auth:1809v1
343+
lifecycle:
344+
postStart:
345+
exec:
346+
command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
347+
imagePullPolicy: IfNotPresent
348+
```
349+
350+
Se você adicionar a seção `lifecycle`, mostrada acima à sua especificação de Pod,
351+
o Pod irá executar os comandos listados para reiniciar o serviço `netlogon`
352+
até que o comando `nltest.exe /query` execute sem erro.

0 commit comments

Comments
 (0)