Skip to content

Commit e3dd9fe

Browse files
ptuxptux
committed
done
1 parent 4793ac1 commit e3dd9fe

File tree

2 files changed

+273
-0
lines changed

2 files changed

+273
-0
lines changed

‎content/ja/docs/tasks/administer-cluster/kubeadm/_index.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
title: "kubeadmによる管理"
3+
weight: 10
4+
---
5+

‎content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

Lines changed: 268 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,268 @@
1+
---
2+
title: kubeadmによる証明書管理
3+
content_type: task
4+
weight: 10
5+
---
6+
7+
<!-- overview -->
8+
9+
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
10+
11+
[kubeadm](/docs/reference/setup-tools/kubeadm/)で生成されたクライアント証明書は1年で失効します。
12+
このページでは、kubeadmで証明書の更新を管理する方法について説明します。
13+
14+
## {{% heading "prerequisites" %}}
15+
16+
[KubernetesにおけるPKI証明書と要件](/docs/setup/best-practices/certificates/)を熟知している必要があります。
17+
18+
<!-- steps -->
19+
20+
## カスタム証明書の使用 {#custom-certificates}
21+
22+
デフォルトでは、kubeadmはクラスターの実行に必要なすべての証明書を生成します。
23+
独自の証明書を提供することで、この動作をオーバーライドできます。
24+
25+
そのためには、`--cert-dir`フラグまたはkubeadmの`ClusterConfiguration`の`certificatesDir`フィールドで指定された任意のディレクトリに配置する必要があります。
26+
デフォルトは`/etc/kubernetes/pki`です。
27+
28+
`kubeadm init` を実行する前に与えられた証明書と秘密鍵のペアが存在する場合、kubeadmはそれらを上書きしません。
29+
つまり、例えば既存のCAを`/etc/kubernetes/pki/ca.crt`と`/etc/kubernetes/pki/ca.key`にコピーすれば、kubeadmは残りの証明書に署名する際、このCAを使用できます。
30+
31+
## 外部CAモード {#external-ca-mode}
32+
33+
また、`ca.crt`ファイルのみを提供し、`ca.key`ファイルを提供しないことも可能です(これはルートCAファイルのみに有効で、他の証明書ペアには有効ではありません)。
34+
他の証明書とkubeconfigファイルがすべて揃っている場合、kubeadmはこの状態を認識し、外部CAモードを有効にします。
35+
kubeadmはディスク上のCAキーがなくても処理を進めます。
36+
37+
代わりに、Controller-managerをスタンドアロンで、`--controllers=csrsigner`と実行し、CA証明書と鍵を指し示します。
38+
39+
[PKI certificates and requirements](/docs/setup/best-practices/certificates/)には、外部CAを使用するためのクラスタのセットアップに関するガイダンスが含まれています。
40+
41+
## 証明書の有効期限の確認
42+
43+
`check-expiration`サブコマンドを使うと、証明書の有効期限を確認することができます。
44+
45+
```
46+
kubeadm certs check-expiration
47+
```
48+
49+
このような出力になります:
50+
51+
```
52+
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
53+
admin.conf Dec 30, 2020 23:36 UTC 364d no
54+
apiserver Dec 30, 2020 23:36 UTC 364d ca no
55+
apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
56+
apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no
57+
controller-manager.conf Dec 30, 2020 23:36 UTC 364d no
58+
etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
59+
etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no
60+
etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no
61+
front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no
62+
scheduler.conf Dec 30, 2020 23:36 UTC 364d no
63+
64+
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
65+
ca Dec 28, 2029 23:36 UTC 9y no
66+
etcd-ca Dec 28, 2029 23:36 UTC 9y no
67+
front-proxy-ca Dec 28, 2029 23:36 UTC 9y no
68+
```
69+
70+
このコマンドは、`/etc/kubernetes/pki`フォルダ内のクライアント証明書と、kubeadmが使用するKUBECONFIGファイル(`admin.conf`,`controller-manager.conf`,`scheduler.conf`に埋め込まれたクライアント証明書の有効期限/残余時間を表示します)。
71+
72+
また、証明書が外部管理されている場合、kubeadmはユーザーに通知します。この場合、ユーザーは証明書の更新を手動または他のツールを使用して管理する必要があります。
73+
74+
{{< warning >}}
75+
`kubeadm`は外部CAによって署名された証明書を管理することができません。
76+
{{< /warning >}}
77+
78+
{{< note >}}
79+
kubeadmは`/var/lib/kubelet/pki`以下にあるローテート可能な証明書で[証明書の自動更新](/docs/task/tls/certificate-rotation/)のためkubeletを構成するので`kubelet.conf`は上記のリストに含まれません。
80+
81+
期限切れのkubeletクライアント証明書を修復するには、[Kubelet クライアント証明書のローテーションに失敗しました](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)を参照ください。
82+
{{< /note >}}
83+
84+
{{< warning >}}
85+
kubeadm version 1.17より前の`kubeadm init`で作成したノードでは、`kubelet.conf`の内容を手動で変更しなければならないという[bug](http://github.com/kubernetes/kubeadm/issues/1753)が存在します。
86+
87+
`kubeadm init`が終了したら、`client-certificate-data`と`client-key-data`を置き換えて、ローテーションされたkubeletクライアント証明書を指すように`kubelet.conf`を更新してください。
88+
89+
```yaml
90+
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
91+
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
92+
```
93+
{{< /warning >}}
94+
95+
## 証明書の自動更新
96+
97+
kubeadmはコントロールプレーンの[アップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)時にすべての証明書を更新します。
98+
99+
この機能は、最もシンプルなユースケースに対応するために設計されています。
100+
証明書の更新に特別な要件がなく、Kubernetesのバージョンアップを定期的に行う場合(各アップグレードの間隔が1年未満)、kubeadmがクラスタを最新かつ適度に安全に保つための処理を行います。
101+
102+
{{< note >}}
103+
安全性を維持するために、クラスタを頻繁にアップグレードすることがベストプラクティスです。
104+
{{< /note >}}
105+
106+
証明書の更新に関してより複雑な要求がある場合は、`--certificate-renewal=false`を`kubeadm upgrade apply`や`kubeadm upgrade node`に渡して、デフォルトの動作から外れるようにすることができます。
107+
108+
{{< warning >}}
109+
kubeadmバージョン1.17より前のバージョンでは、`kubeadm upgrade node`コマンドの`--certificate-renewal`のデフォルト値が`false`になっているという[bug(http://github.com/kubernetes/kubeadm/issues/1818)]問題があります。
110+
この場合、明示的に`--certificate-renewal=true`を設定する必要があります。
111+
{{< /warning >}}
112+
113+
## 手動による証明書更新
114+
115+
`kubeadm certs renew` コマンドを使えば、いつでも証明書を手動で更新することができます。
116+
このコマンドは`/etc/kubernetes/pki`に格納されているCA(またはfront-proxy-CA)の証明書と鍵を使って更新を行います。
117+
118+
コマンド実行後、コントロールプレーンのPodを再起動する必要があります。
119+
これは、現在すべてのコンポーネントと証明書について動的な証明書のリロードがサポートされていないため、必要な作業です。
120+
[スタティックPod](/docs/tasks/configure-pod-container/static-pod/)はローカルkubeletによって管理され、API Serverによって管理されないため、kubectlで削除および再起動することはできません。
121+
122+
スタティックPodを再起動するには、一時的に`/etc/kubernetes/manifests/`からマニフェストファイルを削除して20秒間待ちます([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)の`fileCheckFrequency`値を参照してください)。
123+
マニフェストディレクトリにPodが無くなると、kubeletはPodを終了します。
124+
その後ファイルを戻して、さらに`fileCheckFrequency`期間後に、kubeletはPodを再作成し、コンポーネントの証明書更新を完了することができます。
125+
126+
{{< warning >}}
127+
HAクラスタを実行している場合、このコマンドはすべての制御プレーンノードで実行する必要があります。
128+
{{< /warning >}}
129+
130+
{{< note >}}
131+
`certs renew`は、属性(Common Name、Organization、SANなど)の信頼できるソースとして、kubeadm-config ConfigMapではなく、既存の証明書を使用します。両者を同期させておくことが強く推奨されます。
132+
{{< /note >}}
133+
134+
`kubeadm certs renew` は以下のオプションを提供します:
135+
136+
Kubernetesの証明書は通常1年後に有効期限を迎えます。
137+
138+
- `--csr-only`を使用すると、証明書署名要求を生成して外部CAとの証明書を更新することができます(実際にはその場で証明書を更新しません)。詳しくは次の段落を参照してください。
139+
140+
- また、すべての証明書を更新するのではなく、1つの証明書を更新することも可能です。
141+
142+
## Kubernetes certificates APIによる証明書の更新
143+
144+
ここでは、Kubernetes certificates APIを使用して手動で証明書更新を実行する方法について詳しく説明します。
145+
146+
{{< caution >}}
147+
これらは、組織の証明書インフラをkubeadmで構築されたクラスタに統合する必要があるユーザー向けの上級者向けのトピックです。
148+
kubeadmのデフォルトの設定で満足できる場合は、代わりにkubeadmに証明書を管理させる必要があります。
149+
{{< /caution >}}
150+
151+
### 署名者の設定
152+
153+
Kubernetesの認証局は、そのままでは機能しません。
154+
[cert-manager](http://cert-manager.io/docs/configuration/ca/)などの外部署名者を設定するか、組み込みの署名者を使用することができます。
155+
156+
ビルトインサイナーは[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)に含まれるものです。
157+
ビルトインサイナーを有効にするには、`--cluster-signing-cert-file`と`--cluster-signing-key-file`フラグを渡す必要があります。
158+
159+
新しいクラスタを作成する場合は、kubeadm[設定ファイル](http://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。
160+
161+
```yaml
162+
apiVersion: kubeadm.k8s.io/v1beta3
163+
kind: ClusterConfiguration
164+
controllerManager:
165+
extraArgs:
166+
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
167+
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
168+
```
169+
170+
### 証明書署名要求の作成 (CSR)
171+
172+
Kubernetes APIでのCSR作成については、[Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)を参照ください。
173+
174+
## 外部CAによる証明書の更新
175+
176+
ここでは、外部認証局を利用して手動で証明書更新を行う方法について詳しく説明します。
177+
178+
外部CAとの連携を強化するために、kubeadmは証明書署名要求(CSR)を生成することもできます。
179+
CSRとは、クライアント用の署名付き証明書をCAに要求することを表します。
180+
kubeadmの用語では、通常ディスク上のCAによって署名される証明書をCSRとして生成することができます。しかし、CAはCSRとして生成することはできません。
181+
182+
### 証明書署名要求の作成 (CSR)
183+
184+
`kubeadm certs renew --csr-only`で証明書署名要求を作成することができます。
185+
186+
CSRとそれに付随する秘密鍵の両方が出力されます。
187+
ディレクトリを`--csr-dir`で渡すと、指定した場所にCSRを出力することができます。
188+
csr-dir`を指定しない場合は、デフォルトの証明書ディレクトリ(`/etc/kubernetes/pki`)が使用されます。
189+
190+
証明書は`kubeadm certs renew --csr-only`で更新することができます。
191+
`kubeadm init`と同様に、`--csr-dir`フラグで出力先ディレクトリを指定することができます。
192+
193+
CSRには、証明書の名前、ドメイン、IPが含まれますが、用途は指定されません。
194+
証明書を発行する際に、[正しい証明書の使用法](/docs/setup/best-practices/certificates/#all-certificates)を指定するのはCAの責任です。
195+
196+
* `opensl`では、[`openssl ca`コマンド](http://superuser.com/questions/738612/openssl-ca-keyusage-extension)を使って行います。
197+
198+
* `cfssl`では、[configファイルのusages](http://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)で指定します。
199+
200+
お好みの方法で証明書に署名した後、証明書と秘密鍵をPKIディレクトリ(デフォルトでは`/etc/kubernetes/pki`)にコピーする必要があります。
201+
202+
## 認証局(CA)のローテーション {#certificate-authority-rotation}
203+
204+
Kubeadmは、CA証明書のローテーションや交換を最初からサポートしているわけではありません。
205+
206+
CAの手動ローテーションや交換についての詳細は、[manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/)を参照してください。
207+
208+
## 署名付きkubeletサービング証明書の有効化 {#kubelet-serving-certs}
209+
210+
デフォルトでは、kubeadmによって展開されるkubeletサービング証明書は自己署名されています。
211+
これは、[metrics-server](http://github.com/kubernetes-sigs/metrics-server)のような外部サービスからキューブレットへの接続がTLSで保護されないことを意味します。
212+
新しいkubeadmクラスタ内のkubeletが適切に署名されたサービング証明書を取得するように設定するには、`kubeadm init`に以下の最小限の設定を渡す必要があります。
213+
214+
```yaml
215+
apiVersion: kubeadm.k8s.io/v1beta3
216+
kind: ClusterConfiguration
217+
---
218+
apiVersion: kubelet.config.k8s.io/v1beta1
219+
kind: KubeletConfiguration
220+
serverTLSBootstrap: true
221+
```
222+
223+
すでにクラスタを作成している場合は、以下の手順で適応させる必要があります。
224+
225+
- kube-system` ネームスペースにある `kubelet-config-{{< skew latestVersion >}}` ConfigMap を見つけて編集します。
226+
227+
そのConfigMapの`kubelet`キーの値として[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ドキュメントを指定します。KubeletConfigurationドキュメントを編集し、`serverTLSBootstrap: true`を設定します。
228+
229+
- 各ノードで、`/var/lib/kubelet/config.yaml`に`serverTLSBootstrap: true`フィールドを追加し、`systemctl restart kubelet`でkubeletを再起動します。
230+
231+
`serverTLSBootstrap: true`フィールドは、kubeleサービングのブートストラップを有効にします。
232+
証明書を`certificates.k8s.io`APIにリクエストすることで、証明書を発行することができます。
233+
234+
既知の制限事項として、これらの証明書のCSR(Certificate Signing Requests)はkube-controller-managerのデフォルトサイナーによって自動的に承認されないことがあります。
235+
[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers) を参照してください。
236+
237+
これには、ユーザーまたはサードパーティのコントローラからのアクションが必要です。
238+
239+
これらのCSRは、以下を使用して表示できます:
240+
241+
```shell
242+
kubectl get csr
243+
NAME AGE SIGNERNAME REQUESTOR CONDITION
244+
csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending
245+
csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending
246+
```
247+
248+
承認するためには、次のようにします:
249+
```shell
250+
kubectl certificate approve <CSR-name>
251+
```
252+
253+
デフォルトでは、これらのサービング証明書は1年後に失効します。
254+
255+
Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に設定します。これは有効期限が切れる間際に、サービング証明書のための新しいCSRセットを作成し、ローテーションを完了するために承認する必要があることを意味します。
256+
257+
詳しくは[Certificate Rotation] (/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)をご覧ください。
258+
259+
これらのCSRを自動的に承認するためのソリューションをお探しの場合は、以下をお勧めします。
260+
クラウドプロバイダーに連絡し、CSRの署名者がいるかどうか尋ねてください。
261+
ノードの識別をアウトオブバンドのメカニズムで行います。
262+
263+
{{% thirdparty-content %}}
264+
265+
サードパーティのカスタムコントローラを使用することができます。
266+
- [kubelet-csr-approver](http://github.com/postfinance/kubelet-csr-approver)
267+
268+
このようなコントローラは、CSRのCommonNameを検証するだけでなく、要求されたIPやドメイン名も検証しなければ、安全なメカニズムとは言えません。これにより、kubeletクライアント証明書にアクセスできる悪意のあるアクターが、任意のIPやドメイン名に対してサービング証明書を要求するCSRを作成することを防ぐことができます。

0 commit comments

Comments
 (0)