Skip to content

Commit 8a71791

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #51924 from iamNoah1/localize-best-practice-certificates-2
[DE] Localizing best-practices/certificates - rebased
2 parents 49dcb28 + dd97a5b commit 8a71791

File tree

2 files changed

+261
-0
lines changed

2 files changed

+261
-0
lines changed

‎content/de/docs/setup/best-practices/_index.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
---
2+
title: Best practices
3+
weight: 40
4+
---

‎content/de/docs/setup/best-practices/zertifikate.md‎

Lines changed: 257 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,257 @@
1+
---
2+
title: PKI Zertifikate and Anforderungen
3+
reviewers:
4+
- antonengelhardt
5+
content_type: concept
6+
weight: 50
7+
---
8+
9+
<!-- Übersicht -->
10+
11+
Kubernetes benötigt PKI Zertifikate für die Authentifzierung über TLS.
12+
Falls Sie Kubernetes über [kubeadm](/docs/reference/setup-tools/kubeadm/) installieren,
13+
wurden die benötigten Zertifikate bereits automatisch generiert.
14+
In jedem Fall können Sie diese auch selbst generieren -- beispielsweise um private Schlüssel
15+
nicht auf dem API Server zu speichern und somit deren Sicherheit zu erhöhen.
16+
Diese Seite erklärt, welche Zertifikate ein Cluster benötigt.
17+
18+
<!-- Hauptteil -->
19+
20+
## Wie Zertifikate in Ihrem Cluster verwendet werden
21+
22+
Kubernetes benötigt PKI-Zertifikate für die folgenden Vorgänge:
23+
24+
### Server Zertifikate
25+
26+
* Server Zertifikate für den API Server Endpunkt
27+
* Server Zertifikate für den etcd Server
28+
* [Server Zertifikate](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)
29+
für jeden kubelet (every {{< glossary_tooltip text="node" term_id="node" >}} runs a kubelet)
30+
* Optionale Server Zertifikate für den [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
31+
32+
### Client Zertifikate
33+
34+
* Client-Zertifikate für jedes `Kubelet` zur Authentifizierung gegenüber dem API-Server als Client der Kubernetes API
35+
* Client-Zertifikat für jeden `API-Server` zur Authentifizierung gegenüber etcd
36+
* Client-Zertifikat für den `Controller Manager` zur sicheren Kommunikation mit dem API-Server
37+
* Client-Zertifikat für den `Scheduler` zur sicheren Kommunikation mit dem `API-Server`
38+
* Client-Zertifikate, eines pro Node, für `kube-proxy` zur Authentifizierung gegenüber dem `API-Server`
39+
* Optionale Client-Zertifikate für Administratoren des Clusters zur Authentifizierung gegenüber dem API-Server
40+
* Optionales Client-Zertifikat für den [Front-Proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
41+
42+
### Server- und Client-Zertifikate des Kubelets
43+
44+
Um eine sichere Verbindung herzustellen und sich gegenüber dem Kubelet zu authentifizieren, benötigt der API-Server ein Client-Zertifikat und ein Schlüsselpaar.
45+
46+
In diesem Szenario gibt es zwei Ansätze für die Verwendung von Zertifikaten:
47+
48+
* Gemeinsame Zertifikate: Der kube-apiserver kann dasselbe Zertifikat und Schlüsselpaar verwenden, das er zur Authentifizierung seiner Clients nutzt.
49+
Das bedeutet, dass bestehende Zertifikate wie `apiserver.crt` und `apiserver.key` für die Kommunikation mit den Kubelet-Servern verwendet werden können.
50+
51+
* Separate Zertifikate: Alternativ kann der kube-apiserver ein neues Client-Zertifikat und Schlüsselpaar zur Authentifizierung seiner Kommunikation mit den Kubelet-Servern generieren.
52+
In diesem Fall werden ein separates Zertifikat `kubelet-client.crt` und der dazugehörige private Schlüssel `kubelet-client.key` erstellt.
53+
54+
{{< note >}}
55+
`front-proxy`-Zertifikate werden nur benötigt, wenn kube-proxy zur Unterstützung eines [Erweiterungs-API-Servers](/docs/tasks/extend-kubernetes/setup-extension-api-server/) eingesetzt wird.
56+
{{< /note >}}
57+
58+
Auch etcd verwendet gegenseitiges TLS zur Authentifizierung von Clients und deren Gegenstelle.
59+
60+
## Wo Zertifikate gespeichert werden
61+
62+
Wenn Sie Kubernetes mit kubeadm installieren, werden die meisten Zertifikate im Verzeichnis `/etc/kubernetes/pki` gespeichert.
63+
Alle Pfade in dieser Dokumentation beziehen sich auf dieses Verzeichnis,
64+
mit Ausnahme der Benutzerzertifikate, die von kubeadm unter `/etc/kubernetes` ablegt werden.
65+
66+
## Zertifikate manuell konfigurieren
67+
68+
Wenn Sie nicht möchten, dass kubeadm die benötigten Zertifikate generiert,
69+
können Sie diese entweder mithilfe einer einzelnen Root-CA selbst erstellen
70+
oder alle Zertifikate vollständig manuell bereitstellen. Details zur Erstellung einer eigenen Zertifizierungsstelle finden Sie unter [Zertifikate](/docs/tasks/administer-cluster/certificates/).
71+
Weitere Informationen zur Verwaltung von Zertifikaten mit kubeadm bietet [Zertifikatsverwaltung mit kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
72+
73+
### Einzelne Root-CA
74+
75+
Sie können eine einzelne Root-CA erstellen, welche dann mehrere Zwischen-CAs generieren
76+
und die Erstellung weiterer Zertifikate Kubernetes selbst überlassen kann.
77+
78+
Erforderliche CAs:
79+
80+
| Pfad | Standard-CN | Beschreibung |
81+
|------------------------|---------------------------|---------------------------------------------|
82+
| ca.crt,key | kubernetes-ca | Allgemeine CA für Kubernetes |
83+
| etcd/ca.crt,key | etcd-ca | Für alle etcd-bezogenen Funktionen |
84+
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | Für den [Front-Proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
85+
86+
Zusätzlich zu den oben genannten CAs wird auch ein öffentliches/privates Schlüsselpaar für das Service-Account-Management benötigt: `sa.key` und `sa.pub`.
87+
88+
Das folgende Beispiel zeigt die CA-Schlüssel- und Zertifikatsdateien aus der vorherigen Tabelle:
89+
90+
```
91+
/etc/kubernetes/pki/ca.crt
92+
/etc/kubernetes/pki/ca.key
93+
/etc/kubernetes/pki/etcd/ca.crt
94+
/etc/kubernetes/pki/etcd/ca.key
95+
/etc/kubernetes/pki/front-proxy-ca.crt
96+
/etc/kubernetes/pki/front-proxy-ca.key
97+
```
98+
99+
100+
### Alle Zertifikate
101+
102+
Wenn Sie die privaten CA-Schlüssel nicht in Ihren Cluster kopieren möchten, können Sie alle Zertifikate selbst generieren.
103+
104+
Erforderliche Zertifikate:
105+
106+
| Standard-CN | Ausstellende CA | O (im Subject) | Typ | Hosts (SAN) |
107+
| ----------------------------- | ------------------------- | --------------- | -------------- | --------------------------------------------------- |
108+
| kube-etcd | etcd-ca | | Server, Client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
109+
| kube-etcd-peer | etcd-ca | | Server, Client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
110+
| kube-etcd-healthcheck-client | etcd-ca | | Client | |
111+
| kube-apiserver-etcd-client | etcd-ca | | Client | |
112+
| kube-apiserver | kubernetes-ca | | Server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`[^1] |
113+
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | Client | |
114+
| front-proxy-client | kubernetes-front-proxy-ca | | Client | |
115+
116+
{{< note >}}
117+
Anstelle der Superuser-Gruppe `system:masters` für `kube-apiserver-kubelet-client` kann auch eine weniger privilegierte Gruppe verwendet werden. kubeadm nutzt hierfür die Gruppe `kubeadm:cluster-admins`.
118+
{{< /note >}}
119+
120+
[^1]: Jede andere IP oder jeder andere DNS-Name, unter dem Sie Ihren Cluster erreichen (wie bei [kubeadm](/docs/reference/setup-tools/kubeadm/) verwendet) – die stabile IP und/oder der DNS-Name des Load-Balancers, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`.
121+
122+
Der Wert in der Spalte `Typ` entspricht einer oder mehreren x509-Schlüsselverwendungen, die auch in `.spec.usages` eines [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest)-Typs dokumentiert sind:
123+
124+
| Typ | Schlüsselverwendung |
125+
|---------|----------------------------------------------------------|
126+
| Server | Digitale Signatur, Schlüsselverschlüsselung, Serverauth. |
127+
| Client | Digitale Signatur, Schlüsselverschlüsselung, Clientauth. |
128+
129+
{{< note >}}
130+
Die oben aufgelisteten Hosts/SANs sind die empfohlenen Werte, um einen funktionsfähigen Cluster zu erhalten.
131+
Falls Ihr Setup es erfordert, können Sie auf allen Server-Zertifikaten zusätzliche SANs ergänzen.
132+
{{< /note >}}
133+
134+
{{< note >}}
135+
Nur für kubeadm-Benutzer:
136+
137+
* Das Szenario, bei dem Sie CA-Zertifikate ohne private Schlüssel in Ihren Cluster kopieren, wird in der kubeadm-Dokumentation als **externe CA** bezeichnet.
138+
* Wenn Sie die obige Liste mit einer von kubeadm generierten PKI vergleichen, beachten Sie bitte, dass `kube-etcd`, `kube-etcd-peer` und `kube-etcd-healthcheck-client` nicht erzeugt werden, wenn ein externer etcd-Cluster verwendet wird.
139+
140+
{{< /note >}}
141+
142+
### Zertifikatspfade
143+
144+
Zertifikate sollten in einem empfohlenen Pfad abgelegt werden (wie von [kubeadm](/docs/reference/setup-tools/kubeadm/) verwendet).
145+
Die Pfade sollten mit dem angegebenen Argument festgelegt werden, unabhängig vom Speicherort.
146+
147+
| Standard-CN | Empfohlener Schlüsselpfad | Empfohlener Zertifikatspfad | Befehl | Schlüssel-Argument | Zertifikat-Argument |
148+
| ----------- | ------------------------- | --------------------------- | ------ | ------------------ | ------------------- |
149+
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
150+
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
151+
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
152+
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file |
153+
| kube-apiserver | apiserver.key | apiserver.crt| kube-apiserver | --tls-private-key-file | --tls-cert-file |
154+
| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
155+
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
156+
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
157+
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
158+
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file,--peer-trusted-ca-file |
159+
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
160+
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
161+
| etcd-ca| | etcd/ca.crt | etcdctl | | --cacert |
162+
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
163+
164+
Gleiche Überlegungen gelten für das Service-Account-Schlüsselpaar:
165+
166+
| Pfad privater Schlüssel | Pfad öffentlicher Schlüssel | Befehl | Argument |
167+
|-------------------------|-----------------------------|-------------------------|--------------------------------------|
168+
| sa.key | | kube-controller-manager | --service-account-private-key-file |
169+
| | sa.pub | kube-apiserver | --service-account-key-file |
170+
171+
Das folgende Beispiel zeigt die Dateipfade [aus den vorherigen Tabellen](#zertifikatspfade), die Sie bereitstellen müssen, wenn Sie alle Schlüssel und Zertifikate selbst generieren:
172+
173+
```
174+
/etc/kubernetes/pki/etcd/ca.key
175+
/etc/kubernetes/pki/etcd/ca.crt
176+
/etc/kubernetes/pki/apiserver-etcd-client.key
177+
/etc/kubernetes/pki/apiserver-etcd-client.crt
178+
/etc/kubernetes/pki/ca.key
179+
/etc/kubernetes/pki/ca.crt
180+
/etc/kubernetes/pki/apiserver.key
181+
/etc/kubernetes/pki/apiserver.crt
182+
/etc/kubernetes/pki/apiserver-kubelet-client.key
183+
/etc/kubernetes/pki/apiserver-kubelet-client.crt
184+
/etc/kubernetes/pki/front-proxy-ca.key
185+
/etc/kubernetes/pki/front-proxy-ca.crt
186+
/etc/kubernetes/pki/front-proxy-client.key
187+
/etc/kubernetes/pki/front-proxy-client.crt
188+
/etc/kubernetes/pki/etcd/server.key
189+
/etc/kubernetes/pki/etcd/server.crt
190+
/etc/kubernetes/pki/etcd/peer.key
191+
/etc/kubernetes/pki/etcd/peer.crt
192+
/etc/kubernetes/pki/etcd/healthcheck-client.key
193+
/etc/kubernetes/pki/etcd/healthcheck-client.crt
194+
/etc/kubernetes/pki/sa.key
195+
/etc/kubernetes/pki/sa.pub
196+
```
197+
198+
199+
## Zertifikate für Benutzerkonten konfigurieren
200+
201+
Sie müssen diese Administrator- und Servicekonten manuell konfigurieren:
202+
203+
| Dateiname | Anmeldeinformationen-Name | Standard-CN | O (im Subject) |
204+
|-------------------------|---------------------------|--------------------------------------|------------------------|
205+
| admin.conf | default-admin | kubernetes-admin | `<admin-group>` |
206+
| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters |
207+
| kubelet.conf | default-auth | system:node:`<nodeName>` (siehe Hinweis) | system:nodes |
208+
| controller-manager.conf | default-controller-manager| system:kube-controller-manager | |
209+
| scheduler.conf | default-scheduler | system:kube-scheduler | |
210+
211+
{{< note >}}
212+
Der Wert von `<nodeName>` in `kubelet.conf` **muss** exakt mit dem Node-Namen übereinstimmen, den der kubelet beim Registrieren am apiserver angibt.
213+
Weitere Details finden Sie unter [Node Authorization](/docs/reference/access-authn-authz/node/).
214+
{{< /note >}}
215+
216+
{{< note >}}
217+
Im obigen Beispiel ist `<admin-group>` implementierungsspezifisch. Manche Tools signieren das Zertifikat in der Standard-`admin.conf`, sodass es Teil der Gruppe `system:masters` ist.
218+
`system:masters` ist eine Notfall-Superuser-Gruppe, die die Autorisierungsschicht, wie zum Beispiel RBAC, von Kubernetes umgehen kann. Manche Tools erzeugen auch keine separate `super-admin.conf` mit einem Zertifikat, das an diese Superuser-Gruppe gebunden ist.
219+
220+
kubeadm erstellt zwei separate Administratorzertifikate in kubeconfig-Dateien. Eines ist in `admin.conf` und hat `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`.
221+
`kubeadm:cluster-admins` ist eine benutzerdefinierte Gruppe, die an die ClusterRole `cluster-admin` gebunden ist. Diese Datei wird auf allen von kubeadm verwalteten Control-Plane-Maschinen erstellt.
222+
223+
Das andere ist in `super-admin.conf` und hat `Subject: O = system:masters, CN = kubernetes-super-admin`.
224+
Diese Datei wird nur auf dem Node erzeugt, auf dem `kubeadm init` ausgeführt wurde.
225+
{{< /note >}}
226+
227+
1. Generieren Sie für jede Konfiguration ein x509-Zertifikat/Schlüsselpaar mit dem angegebenen Common Name (CN) und der Organisation (O).
228+
229+
2. Führen Sie für jede Konfiguration `kubectl` wie folgt aus:
230+
231+
```
232+
KUBECONFIG=<Dateiname> kubectl config set-cluster default-cluster --server=https://<Host-IP>:6443 --certificate-authority <Pfad-zur-kubernetes-ca> --embed-certs
233+
KUBECONFIG=<Dateiname> kubectl config set-credentials <Anmeldeinfo-Name> --client-key <Pfad-zum-Schlüssel>.pem --client-certificate <Pfad-zum-Zertifikat>.pem --embed-certs
234+
KUBECONFIG=<Dateiname> kubectl config set-context default-system --cluster default-cluster --user <Anmeldeinfo-Name>
235+
KUBECONFIG=<Dateiname> kubectl config use-context default-system
236+
```
237+
238+
Diese Dateien werden wie folgt verwendet:
239+
240+
| Dateiname | Befehl | Kommentar |
241+
|-------------------------|-------------------------|-------------------------------------------------------------------------|
242+
| admin.conf | kubectl | Konfiguriert den Administrator-Benutzer für den Cluster |
243+
| super-admin.conf | kubectl | Konfiguriert den Super-Administrator-Benutzer für den Cluster |
244+
| kubelet.conf | kubelet | Wird für jeden Node im Cluster benötigt |
245+
| controller-manager.conf | kube-controller-manager | Muss im Manifest `manifests/kube-controller-manager.yaml` eingetragen werden |
246+
| scheduler.conf | kube-scheduler | Muss im Manifest `manifests/kube-scheduler.yaml` eingetragen werden |
247+
248+
Beispielhafte vollständige Pfade zu den Dateien aus der obigen Tabelle:
249+
250+
```
251+
/etc/kubernetes/admin.conf
252+
/etc/kubernetes/super-admin.conf
253+
/etc/kubernetes/kubelet.conf
254+
/etc/kubernetes/controller-manager.conf
255+
/etc/kubernetes/scheduler.conf
256+
```
257+

0 commit comments

Comments
 (0)