Benutzerdefinierte Cluster-Zertifizierungsstellen verwenden

Cluster-Zertifizierungsstellen (CAs) stellen Zertifikate aus und signieren sie, um eine sichere Authentifizierung und Verschlüsselung zwischen Clusterkomponenten zu ermöglichen. Standardmäßig erstellt die Cluster API in Google Distributed Cloud die Cluster-Zertifizierungsstellen, wenn Sie einen neuen Cluster erstellen. In diesem Dokument wird beschrieben, wie Sie Ihre eigenen Zertifikatsstellen mit Google Distributed Cloud verwenden können. Benutzerdefinierte Cluster-Zertifizierungsstellen bieten Ihnen mehr Kontrolle über die Ausstellung und Verwaltung von Clusterzertifikaten. Sie können auch das Vertrauen, Verschlüsselungsalgorithmusparameter, die Tiefe der untergeordneten Zertifikate und deren Zweck steuern.

Um benutzerdefinierte Zertifizierungsstellen zu verwenden, geben Sie Stamm-CAs an, die aus einer CA-Zertifikatsdatei und der zugehörigen privaten Schlüsseldatei bestehen. Sie stellen ein Paar aus CA-Zertifikatsdatei und Schlüsseldatei für jede der folgenden erforderlichen Cluster-CAs bereit:

• etcd-CA: Das Zertifikat der etcd-CA sichert die Kommunikation vom Kubernetes API-Server zu den etcd-Replikaten und die Kommunikation zwischen etcd-Replikaten.

• Cluster-CA: Das Zertifikat der Cluster-Zertifizierungsstelle sichert die Kommunikation zwischen dem Kubernetes API-Server und allen internen Kubernetes API-Clients. Clients umfassen unter anderem das Kubelet, den Controller-Manager und den Planer.

• Front-Proxy-CA: Das Zertifikat für die Front-Proxy-Zertifizierungsstelle sichert die Kommunikation mit aggregierten APIs.

Sie können für jede Zertifizierungsstelle ein eindeutiges Zertifikat-Schlüsselpaar bereitstellen oder ein Zertifikatschlüsselpaar für mehr als eine Zertifizierungsstelle wiederverwenden.

Sie wenden die Zertifikat-Schlüsselpaare während der Clustererstellung (nur Methode bmctl) und der CA-Rotation an. Die benutzerdefinierte Cluster-Zertifizierungsstelle funktioniert mit allen Clustertypen: Administrator-, Nutzer-, Hybrid- und eigenständige Cluster.

Hinweis: Wenn Sie einen Nutzercluster mit bmctl erstellen, entfernen Sie in der Regel den Anmeldedatenabschnitt der Clusterkonfigurationsdatei. Um benutzerdefinierten Cluster-Zertifizierungsstellen anzugeben, wenn Sie einen Nutzercluster erstellen, geben Sie im Bereich „Anmeldedaten“ nur die Pfade zum benutzerdefiniertem Cluster-Zertifikat und privaten Schlüsseln an.

Vorbereitung

Sie sind dafür verantwortlich, Ihre eigenen Stamm-CAs gemäß den folgenden Regeln vorzubereiten:

• Benutzerdefinierte Zertifizierungsstellen sind Stamm-CAs, die jeweils aus einer selbst signierten Zertifikatsdatei und einer privaten Schlüsseldatei bestehen.

• Für Ihr Zertifikat empfehlen wir die Verwendung des DER-Formats (Distinguished Encoding Rules) (siehe Empfehlung X.690 für ASN.1-Codierungsregeln). Ihre Zertifikatsdatei sollte base64-codierte Daten enthalten, vorangestellt durch ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ und gefolgt von ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• Für den privaten Schlüssel empfehlen wir die Verwendung des Formats Public-Key Cryptography Standards (PKCS) Nr. 1. Ihre Schlüsseldatei muss base64-codierte Daten enthalten, vorangestellt durch ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ und gefolgt von ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

• Um potenzielle Clusterunterbrechungen zu minimieren, sollten benutzerdefinierte Zertifizierungsstellen frühestens nach 5 Jahren ablaufen. Wir empfehlen einen längeren Ablaufzeitraum, z. B. 10 bis 30 Jahre.

• Achten Sie darauf, dass sich das Zertifikat und die Schlüsseldateien auf der Administratorworkstation befinden, auf der Sie bmctl-Befehle ausführen.

• Der Nutzer, der bmctl-Befehle ausführt, muss Zugriff auf das Verzeichnis haben, in dem Sie die Dateien speichern. Wir empfehlen, die Dateien in einem vorhandenen Verzeichnis zu platzieren, das für Zertifikate und Schlüssel verwendet wird. Zum Beispiel können Sie die Dateien zusammen mit Ihrem Dienstkontoschlüssel in ~/baremetal/bmctl-workspace/.sa-keys speichern.

• Der Nutzer, der bmctl-Befehle ausführt, muss Lesezugriff auf die Dateien haben.

Benutzerdefinierte Zertifizierungsstelle beim Erstellen von Clustern verwenden

Wenn Sie einen Cluster mit bmctl erstellen, aktualisieren Sie zuerst die Clusterkonfigurationsdatei, um Ihre Clusterfunktionen und -einstellungen zu beschreiben. Um das Feature für benutzerdefinierte Cluster-Zertifizierungsstellen während der Clustererstellung zu verwenden, haben Sie zwei Möglichkeiten zum Angeben der benutzerdefinierten Cluster-Zertifizierungsstellen in der Clusterkonfigurationsdatei:

• Geben Sie die Pfade für die CA-Zertifikatsdateien und die privaten Schlüsseldateien an.
• Geben Sie nur die Pfade für die Dateien mit dem privaten Schlüssel an.

Wenn Sie nur die privaten Schlüssel angeben, sucht bmctl nach den entsprechenden CA-Zertifikatsdateien im selben Verzeichnis. Zertifikatsdateien müssen den gleichen Namen wie die entsprechenden privaten Schlüsseldateien und die Dateiendung .crt haben. Wenn der Pfad zum privaten Schlüssel beispielsweise /custom-ca/cluster_ca.key lautet, dann erwartet bmctl, dass der Pfad zum Zertifikat /custom-ca/cluster_ca.crt ist.

In beiden Fällen werden die Pfade im Abschnitt „Anmeldedaten“ der Konfigurationsdatei angegeben, wie in den folgenden Beispielen gezeigt.

Beispiel 1: Zertifikats- und Schlüsselpfade angeben

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie Sie die Pfade zu den Zertifikat- und Schlüsseldateien für jede Cluster-Zertifizierungsstelle angeben. In diesem Beispiel befinden sich das CA-Zertifikat und die Schlüsseldateien im selben Verzeichnis wie die JSON-Schlüsseldateien des Dienstkontos.

Hinweis: Für einen Nutzercluster entfernen Sie das Dienstkonto und die SSH-Schlüsselpfade aus dem Bereich „Anmeldedaten“.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Beispiel 2: Nur Pfade für private Schlüssel angeben

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie Sie nur die Pfade zu Schlüsseldateien angeben. In diesem Beispiel befinden sich privaten Schlüsseldateien der Zertifizierungsstelle im selben Verzeichnis wie die JSON-Schlüsseldateien des Dienstkontos. Die entsprechenden CA-Zertifikatsdateien müssen sich auch im Verzeichnis /.sa-keys befinden. Zertifikatsdateien haben denselben Dateinamen wie die Schlüsseldateien, aber die Dateiendung .crt. Die etcd-CA-Zertifikatsdatei hat den Namen etcd_ca.crt.

Hinweis: Für einen Nutzercluster entfernen Sie das Dienstkonto und die SSH-Schlüsselpfade aus dem Bereich „Anmeldedaten“.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Beispiel 3: Ein einzelnes Paar aus CA-Zertifikat und Schlüsseldateien wiederverwenden

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie Sie nur die Pfade zu Schlüsseldateien angeben. In diesem Beispiel wird ein einzelnes Zertifikat-Schlüssel-Paar für alle Cluster-Zertifizierungsstellen verwendet. Die Dateien mit dem CA-Zertifikat und dem privaten Schlüssel befinden sich beide im /custom-ca-Verzeichnis. Gemäß der Namenskonvention ist der Dateiname des CA-Zertifikats custom_ca.crt.

Hinweis: Für einen Nutzercluster entfernen Sie das Dienstkonto und die SSH-Schlüsselpfade aus dem Bereich „Anmeldedaten“.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Benutzerdefinierte Zertifizierungsstelle während der CA-Rotation verwenden

Beim Rotieren von Zertifizierungsstellen können Sie die Pfade für das benutzerdefinierte Cluster-CA-Zertifikat und die Dateien mit dem privaten Schlüssel festlegen. Ihre Optionen ähneln den Optionen zum Angeben benutzerdefinierter Cluster-Zertifizierungsstellen während der Clustererstellung. Wenn Sie den Befehl bmctl update credentials certificate-authorities rotate ausführen, haben Sie folgende Optionen:

• Geben Sie die Pfade für die Zertifikatsdateien und die privaten Schlüsseldateien der benutzerdefinierten Zertifizierungsstelle an.
• Geben Sie nur die Pfade für die privaten Schlüsseldateien der benutzerdefinierten Zertifizierungsstelle an. Die entsprechende Zertifikatsdatei muss sich im selben Verzeichnis befinden, denselben Namen als Schlüsseldatei und die Dateiendung .crt haben.
• Sie können das Zertifikat/Schlüssel-Paar einer Zertifizierungsstelle wiederverwenden, indem Sie dieselben Pfade für Zertifikat und Schlüssel für mehr als eine Cluster-Zertifizierungsstelle angeben.
• Lassen Sie die Argumente für die Pfade zur benutzerdefinierten Zertifizierungsstelle weg. Wenn Sie keine benutzerdefinierte Zertifizierungsstelle angeben, wenn Sie Zertifizierungsstellen rotieren, erstellt und verwendet Google Distributed Cloud die Standardcluster-Zertifizierungsstelle.

Beispiel 1: Pfade für Zertifikat und privaten Schlüssel einer Zertifizierungsstelle angeben

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Ersetzen Sie Folgendes:

• CLUSTER_NAME: der Name des Clusters, für den Sie Zertifizierungsstellen rotieren möchten.
• ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters. Bei selbstverwalteten Clustern ist diese Datei die kubeconfig-Datei des Clusters.
• CLUSTER_CA_CERT_PATH: Pfad der Zertifikatsdatei der Cluster-CA.
• CLUSTER_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der Cluster-CA.
• ETCD_CA_CERT_PATH: Pfad der Zertifikatsdatei der etcd-CA.
• ETCD_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der etcd-CA.
• FRONT_PROXY_CA_CERT_PATH: Pfad der Zertifikatsdatei des Front-Proxys.
• FRONT_PROXY_CA_KEY_PATH: Pfad der privaten Schlüsseldatei des Front-Proxys.

Beispiel 2: Nur Pfade für private Schlüssel angeben

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Ersetzen Sie Folgendes:

• CLUSTER_NAME: der Name des Clusters, für den Sie Zertifizierungsstellen rotieren möchten.
• ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters. Bei selbstverwalteten Clustern ist diese Datei die kubeconfig-Datei des Clusters.
• CLUSTER_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der Cluster-CA.
• ETCD_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der etcd-CA.
• FRONT_PROXY_CA_KEY_PATH: Pfad der privaten Schlüsseldatei des Front-Proxys.

Zwischenzertifizierungsstellen

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Cluster der Version 1.29 unterstützen die Verwendung von Zwischenzertifizierungsstellen als Vorschau-Funktion: Diese Funktion ist nicht in derselben Markteinführungsphase für alle unterstützten Produktversionen:

• 1.29: Vorschau
• 1.28: Nicht verfügbar
• 1.16: Nicht verfügbar

Ähnlich wie bei der Anforderung der Stamm-CA für benutzerdefinierte Zertifizierungsstellen müssen Sie drei Zertifizierungsstellen vorbereiten. Jede Zertifizierungsstelle besteht aus einer CA-Zertifikatsdatei und der zugehörigen privaten Schlüsseldatei. Sie stellen ein Paar aus CA-Zertifikatsdatei und Schlüsseldatei für jede der folgenden erforderlichen Cluster-CAs bereit:

• etcd-CA
• Cluster-CA
• Front-Proxy-CA

Wie bei Stamm-CAs können Sie für jede Zertifizierungsstelle ein eindeutiges Zertifikat-Schlüssel-Paar bereitstellen oder ein Zertifikat-Schlüssel-Paar für mehrere Zertifizierungsstellen wiederverwenden, indem Sie dieselben Dateipfade in der Konfiguration der Zertifizierungsstelle angeben.

Wenn Sie Zwischen-CAs verwenden, sollte die CA-Zertifikatsdatei die gesamte Zertifikatskette enthalten, die Zertifikate von den Zwischen-CAs bis zur Stammzertifizierungsstelle enthalten. Die Zertifikate sind in umgekehrter Reihenfolge ihrer Signierung aufgeführt. Dabei befindet sich das Zertifikat der letzten Zwischenzertifizierungsstelle ganz oben und das Zertifikat der Stammzertifizierungsstelle ganz unten.

Im folgenden Beispiel (beginnend mit der Stammzertifizierungsstelle am Ende) bedeutet die Reihenfolge Folgendes:

• Die Stammzertifizierungsstelle hat das Zertifikat der Intermediate-A-Zertifizierungsstelle signiert.
• Die Intermediate-A-Zertifizierungsstelle hat das Zertifikat der Intermediate-B-Zertifizierungsstelle signiert.
• Die Kette fährt bis zum endgültigen Zertifikat der Intermediate-Y-Zertifizierungsstelle fort, das von der Zertifizierungsstelle „Intermediate-X“ signiert wurde.

-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE----- 

Um mit diesem Beispiel fortzufahren, muss der private Schlüssel, der mit dem Zertifikat der Intermediate-Y-Zertifizierungsstelle verknüpft ist, zusammen mit den CA-Zertifikats-Ketten auf dieselbe Weise wie bei einer benutzerdefinierten Zertifizierungsstelle übergeben werden.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Um zu prüfen, ob der Cluster die Zwischen-Zertifizierungsstelle verwenden, prüfen Sie die Anzahl der Zertifikate im CA-Secret des Clusters:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l