Skip to content

Commit 3f15b44

Browse files
levi106levi106
authored
[ja] Translate content/ja/docs/tasks/configure-pod-container/configure-gmsa.md (#46535)
* [ja] Translate content/ja/docs/tasks/configure-pod-container/configure-gmsa.md * Reflecting Feedback
1 parent ceab49d commit 3f15b44

File tree

1 file changed

+303
-0
lines changed

1 file changed

+303
-0
lines changed

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

Lines changed: 303 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,303 @@
1+
---
2+
title: Windows Podとコンテナに対するGMSAの設定
3+
content_type: task
4+
weight: 30
5+
---
6+
7+
<!-- overview -->
8+
9+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
10+
11+
このページでは、Windowsノード上で動作するPodとコンテナに対する[グループ管理サービスアカウント](https://learn.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)(GMSA)の設定方法を示します。
12+
グループ管理サービスアカウントは特別な種類のActive Directoryアカウントで、パスワードの自動管理、簡略化されたサービスプリンシパル名(SPN)の管理、および管理を他の管理者に委任する機能を複数のサーバーに提供します。
13+
14+
Kubernetesでは、GMSA資格情報仕様は、Kubernetesクラスター全体をスコープとするカスタムリソースとして設定されます。
15+
WindowsのPodおよびPod内の個々のコンテナは、他のWindowsサービスとやり取りする際に、ドメインベースの機能(例えばKerberos認証)に対してGMSAを使用するように設定できます。
16+
17+
## {{% heading "prerequisites" %}}
18+
19+
Kubernetesクラスターが必要で、`kubectl`コマンドラインツールがクラスターと通信できるように設定されている必要があります。
20+
クラスターにはWindowsワーカーノードを持つことが求められます。
21+
このセクションでは、各クラスターに対して一度だけ実施する必要がある一連の初期ステップについて説明します:
22+
23+
### GMSACredentialSpec CRDのインストール
24+
25+
カスタムリソースタイプ`GMSACredentialSpec`を定義するために、GMSA資格情報仕様リソースに対する[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)をクラスター上で設定する必要があります。
26+
GMSA CRDの[YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)をダウンロードし、gmsa-crd.yamlとして保存します。
27+
次に、`kubectl apply -f gmsa-crd.yaml`を実行してCRDをインストールします。
28+
29+
### GMSAユーザーを検証するためのWebhookのインストール
30+
31+
Podまたはコンテナレベルで参照するGMSA資格情報仕様を追加および検証するために、Kubernetesクラスター上で2つのWebhookを設定する必要があります:
32+
33+
1. Mutating Webhookは、(Podの仕様から名前で指定された)GMSAへの参照を、JSON形式の完全な資格情報仕様としてPodのspecの中へ展開します。
34+
35+
1. Validating Webhookは、すべてのGMSAへの参照に対して、Podサービスアカウントによる利用が認可されているか確認します。
36+
37+
上記Webhookと関連するオブジェクトをインストールするためには、次の手順が必要です:
38+
39+
1. 証明書と鍵のペアを作成します(Webhookコンテナがクラスターと通信できるようにするために使用されます)
40+
41+
1. 上記の証明書を含むSecretをインストールします。
42+
43+
1. コアとなるWebhookロジックのためのDeploymentを作成します。
44+
45+
1. Deploymentを参照するValidating WebhookとMutating Webhookの設定を作成します。
46+
47+
上で述べたGMSA Webhookと関連するオブジェクトを展開、構成するための[スクリプト](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)があります。
48+
スクリプトは、`--dry-run=server`オプションをつけることで、クラスターに対して行われる変更内容をレビューすることができます。
49+
50+
Webhookと関連するオプジェクトを(適切なパラメーターを渡すことで)手動で展開するための[YAMLテンプレート](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)もあります。
51+
52+
<!-- steps -->
53+
54+
## Active DirectoryにGMSAとWindowsノードを構成する
55+
56+
[Windows GMSAのドキュメント](https://learn.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)に記載されている通り、Kubernetes内のPodがGMSAを使用するために設定できるようにする前に、Active Directory内に目的のGMSAを展開する必要があります。
57+
[Windows GMSAのドキュメント](https://learn.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)に記載されている通り、(Kubernetesクラスターの一部である)Windowsワーカーノードは、目的のGMSAに関連づけられたシークレット資格情報にアクセスできるように、Active Directory内で設定されている必要があります。
58+
59+
## GMSA資格情報仕様リソースの作成
60+
61+
(前述の通り)GMSACredentialSpec CRDをインストールすると、GMSA資格情報仕様を含むカスタムリソースを設定できます。
62+
GMSA資格情報仕様には、シークレットや機密データは含まれません。
63+
それは、コンテナランタイムが目的のコンテナのGMSAをWindowsに対して記述するために使用できる情報です。
64+
GMSA資格情報仕様は、[PowerShellスクリプト](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1)のユーティリティを使用して、YAMLフォーマットで生成することができます。
65+
66+
以下は、GMSA資格情報仕様をJSON形式で手動で生成し、その後それをYAMLに変換する手順です:
67+
68+
1. CredentialSpec[モジュール](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1)をインポートします: `ipmo CredentialSpec.psm1`
69+
70+
1. `New-CredentialSpec`を使用してJSONフォーマットの資格情報仕様を作成します。
71+
WebApp1という名前のGMSA資格情報仕様を作成するには、`New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`を実行します
72+
73+
1. `Get-CredentialSpec`を使用して、JSONファイルのパスを表示します。
74+
75+
1. credspecファイルをJSON形式からYAML形式に変換し、Kubernetesで設定可能なGMSACredentialSpecカスタムリソースにするために、必要なヘッダーフィールドである`apiVersion`、`kind`、`metadata`、`credspec`を記述します。
76+
77+
次のYAML設定は、`gmsa-WebApp1`という名前のGMSA資格情報仕様を記述しています:
78+
79+
```yaml
80+
apiVersion: windows.k8s.io/v1
81+
kind: GMSACredentialSpec
82+
metadata:
83+
name: gmsa-WebApp1 # これは任意の名前で構いませんが、参照時に使用されます
84+
credspec:
85+
ActiveDirectoryConfig:
86+
GroupManagedServiceAccounts:
87+
- Name: WebApp1 # GMSAアカウントのユーザー名
88+
Scope: CONTOSO # NETBIOSドメイン名
89+
- Name: WebApp1 # GMSAアカウントのユーザー名
90+
Scope: contoso.com # DNSドメイン名
91+
CmsPlugins:
92+
- ActiveDirectory
93+
DomainJoinConfig:
94+
DnsName: contoso.com # DNSドメイン名
95+
DnsTreeName: contoso.com # DNSルートドメイン名
96+
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID
97+
MachineAccountName: WebApp1 # GMSAアカウントのユーザー名
98+
NetBiosName: CONTOSO # NETBIOSドメイン名
99+
Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSAのSID
100+
```
101+
102+
上記の資格情報仕様リソースは`gmsa-Webapp1-credspec.yaml`として保存され、次のコマンドを使用してクラスターに適用されます: `kubectl apply -f gmsa-Webapp1-credspec.yml`
103+
104+
## 指定されたGMSA資格情報仕様上にRBACを有効にするためのクラスターロールの設定
105+
106+
各GMSA資格情報仕様リソースに対して、クラスターロールを定義する必要があります。
107+
これは特定のGMSAリソース上の`use` verbを、通常はサービスアカウントであるsubjectに対して認可します。
108+
次の例は、前述の`gmsa-WebApp1`資格情報仕様の利用を認可するクラスターロールを示しています。
109+
ファイルをgmsa-webapp1-role.yamlとして保存し、`kubectl apply -f gmsa-webapp1-role.yaml`を使用して適用します。
110+
111+
```yaml
112+
# credspecを読むためのロールを作成
113+
apiVersion: rbac.authorization.k8s.io/v1
114+
kind: ClusterRole
115+
metadata:
116+
name: webapp1-role
117+
rules:
118+
- apiGroups: ["windows.k8s.io"]
119+
resources: ["gmsacredentialspecs"]
120+
verbs: ["use"]
121+
resourceNames: ["gmsa-WebApp1"]
122+
```
123+
124+
## 指定されたGMSA credspecを使用するためのサービスアカウントへのロールの割り当て
125+
126+
(Podに対して設定される)サービスアカウントを、上で作成したクラスターロールに結びつける必要があります。
127+
これによって、要求されたGMSA資格情報仕様のリソースの利用をサービスアカウントに対して認可できます。
128+
以下は、上で作成した資格情報仕様リソース`gmsa-WebApp1`を使うために、既定のサービスアカウントに対してクラスターロール`webapp1-role`を割り当てる方法を示しています。
129+
130+
```yaml
131+
apiVersion: rbac.authorization.k8s.io/v1
132+
kind: RoleBinding
133+
metadata:
134+
name: allow-default-svc-account-read-on-gmsa-WebApp1
135+
namespace: default
136+
subjects:
137+
- kind: ServiceAccount
138+
name: default
139+
namespace: default
140+
roleRef:
141+
kind: ClusterRole
142+
name: webapp1-role
143+
apiGroup: rbac.authorization.k8s.io
144+
```
145+
146+
## Podのspec内で参照するGMSA資格情報仕様の設定
147+
148+
Podのspecのフィールド`securityContext.windowsOptions.gmsaCredentialSpecName`は、要求されたGMSA資格情報仕様のカスタムリソースに対する参照を、Podのspec内で指定するために使用されます。
149+
これは、Podのspec内の全てのコンテナに対して、指定されたGMSAを使用するように設定します。
150+
`gmsa-WebApp1`を参照するために追加された注釈を持つPodのspecのサンプルです:
151+
152+
```yaml
153+
apiVersion: apps/v1
154+
kind: Deployment
155+
metadata:
156+
labels:
157+
run: with-creds
158+
name: with-creds
159+
namespace: default
160+
spec:
161+
replicas: 1
162+
selector:
163+
matchLabels:
164+
run: with-creds
165+
template:
166+
metadata:
167+
labels:
168+
run: with-creds
169+
spec:
170+
securityContext:
171+
windowsOptions:
172+
gmsaCredentialSpecName: gmsa-webapp1
173+
containers:
174+
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
175+
imagePullPolicy: Always
176+
name: iis
177+
nodeSelector:
178+
kubernetes.io/os: windows
179+
```
180+
181+
Podのspec内の個々のコンテナも、コンテナ毎の`securityContext.windowsOptions.gmsaCredentialSpecName`フィールドを使用することで、要求されたGMSA credspecを指定することができます。
182+
183+
設定例:
184+
185+
```yaml
186+
apiVersion: apps/v1
187+
kind: Deployment
188+
metadata:
189+
labels:
190+
run: with-creds
191+
name: with-creds
192+
namespace: default
193+
spec:
194+
replicas: 1
195+
selector:
196+
matchLabels:
197+
run: with-creds
198+
template:
199+
metadata:
200+
labels:
201+
run: with-creds
202+
spec:
203+
containers:
204+
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
205+
imagePullPolicy: Always
206+
name: iis
207+
securityContext:
208+
windowsOptions:
209+
gmsaCredentialSpecName: gmsa-Webapp1
210+
nodeSelector:
211+
kubernetes.io/os: windows
212+
```
213+
214+
(上記のような)GMSAフィールドが入力されたPod specがクラスターに適用されると、次の一連のイベントが発生します:
215+
216+
1. Mutating WebhookがGMSA資格情報仕様リソースへの全ての参照を解決し、GMSA資格情報仕様の内容を展開します。
217+
218+
1. Validating Webhookは、Podに関連付けられたサービスアカウントが、指定されたGMSA資格情報仕様上の`use` verbに対して認可されていることを保証します。
219+
220+
1. コンテナランタイムは、指定されたGMSA資格情報仕様で各Windowsコンテナを設定します。
221+
それによってコンテナはGMSAのIDがActive Directory内にあることを仮定でき、そのIDを使用してドメイン内のサービスにアクセスできます。
222+
223+
## ホスト名またはFQDNを使用してネットワーク共有に対して認証する
224+
225+
PodからSMB共有へのホスト名やFQDNを使用した接続で問題が発生した際に、IPv4アドレスではSMB共有にアクセスすることはできる場合には、次のレジストリキーがWindowsノード上で設定されているか確認してください。
226+
227+
```cmd
228+
reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
229+
```
230+
231+
その後、動作の変更を反映させるために、実行中のPodを再作成する必要があります。
232+
このレジストリキーがどのように使用されるかについてのより詳細な情報は、[こちら](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)を参照してください。
233+
234+
## トラブルシューティング
235+
236+
自分の環境でGMSAがうまく動作しない時に実行できるトラブルシューティングステップがあります。
237+
238+
まず、credspecがPodに渡されたことを確認します。
239+
そのためには、Podのひとつに`exec`で入り、`nltest.exe /parentdomain`コマンドの出力をチェックする必要があります。
240+
241+
以下の例では、Podはcredspecを正しく取得できませんでした:
242+
243+
```PowerShell
244+
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
245+
```
246+
247+
`nltest.exe /parentdomain`の結果は次のようなエラーになります:
248+
249+
```output
250+
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
251+
```
252+
253+
Podが正しくcredspecを取得したら、次にドメインと正しく通信できることを確認します。
254+
まずはPodの中から、ドメインのルートを見つけるために、手短にnslookupを実行します。
255+
256+
これから3つのことがわかります:
257+
258+
1. PodがDCまで到達できる
259+
1. DCがPodに到達できる
260+
1. DNSが正しく動作している
261+
262+
DNSと通信のテストをパスしたら、次にPodがドメインとセキュアチャネル通信を構築することができるか確認する必要があります。
263+
そのためには、再び`exec`を使用してPodの中に入り、`nltest.exe /query`コマンドを実行します。
264+
265+
```PowerShell
266+
nltest.exe /query
267+
```
268+
269+
結果は次のように出力されます:
270+
271+
```output
272+
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
273+
```
274+
275+
これは、Podがなんらかの理由で、credspec内で指定されたアカウントを使用してドメインにログオンできなかったことを示しています。
276+
次のコマンドを実行してセキュアチャネルを修復してみてください:
277+
278+
```PowerShell
279+
nltest /sc_reset:domain.example
280+
```
281+
282+
コマンドが成功したら、このような出力を確認することができます:
283+
284+
```output
285+
Flags: 30 HAS_IP HAS_TIMESERV
286+
Trusted DC Name \\dc10.domain.example
287+
Trusted DC Connection Status Status = 0 0x0 NERR_Success
288+
The command completed successfully
289+
```
290+
291+
もし上記によってエラーが解消された場合は、次のライフサイクルフックをPodのspecに追加することで、手順を自動化できます。
292+
エラーが解消されなかった場合は、credspecをもう一度調べ、正しく完全であることを確認する必要があります。
293+
294+
```yaml
295+
image: registry.domain.example/iis-auth:1809v1
296+
lifecycle:
297+
postStart:
298+
exec:
299+
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)"]
300+
imagePullPolicy: IfNotPresent
301+
```
302+
303+
Podのspecに上記の`lifecycle`セクションを追加すると、`nltest.exe /query`コマンドがエラーとならずに終了するまで`netlogon`サービスを再起動するために、Podは一連のコマンドを実行します。

0 commit comments

Comments
 (0)