Benutzerdefinierte Cluster-Zertifizierungsstellen verwenden

Cluster-Zertifizierungsstellen stellen und signieren Zertifikate aus, um eine sichere Authentifizierung und Verschlüsselung zwischen Clusterkomponenten zu ermöglichen. In Google Distributed Cloud erstellt die Cluster API standardmäßig die Cluster-Zertifizierungsstellen, wenn Sie einen neuen Cluster erstellen. In diesem Dokument wird beschrieben, wie Sie Ihre eigenen Zertifizierungsstellen mit Google Distributed Cloud verwenden können. Mit benutzerdefinierten Cluster-CAs haben Sie mehr Kontrolle über die Ausstellung und Verwaltung Ihrer Clusterzertifikate. Sie können auch die Vertrauensstellung, Parameter des Verschlüsselungsalgorithmus, die Tiefe untergeordneter Zertifikate und deren Zweck festlegen.

Wenn Sie benutzerdefinierte Zertifizierungsstellen verwenden möchten, geben Sie Stamm-CAs an, die aus einer CA-Zertifikatsdatei und der entsprechenden Datei mit dem privaten Schlüssel bestehen. Sie stellen ein CA-Zertifikat und ein Schlüsselpaar für jede der folgenden erforderlichen Cluster-CAs bereit:

• etcd CA: Das Zertifikat für das etcd-CA-Zertifikat sichert die Kommunikation vom Kubernetes API-Server zu den etcd-Replikaten sowie die Kommunikation zwischen etcd-Replikaten.

• Cluster-CA: Das Zertifikat für die Cluster-Zertifizierungsstelle sichert die Kommunikation zwischen dem Kubernetes API-Server und allen internen Kubernetes API-Clients. Clients sind unter anderem das Kubelet, der Controller-Manager und der 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 mehrere Zertifizierungsstellen wiederverwenden.

Sie wenden die Zertifikat-Schlüsselpaare während der Clustererstellung (nur bmctl-Methode) und der CA-Rotation an. Das CA-Feature für benutzerdefinierte Cluster 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 Abschnitt „Anmeldedaten“ aus der Clusterkonfigurationsdatei. Wenn Sie beim Erstellen eines Nutzerclusters benutzerdefinierte Cluster-CAs angeben möchten, geben Sie im Bereich „Anmeldedaten“ nur das benutzerdefinierte Cluster-CA-Zertifikat und die Pfade für den privaten Schlüssel an.

Vorbereitung

Es liegt in Ihrer Verantwortung, Ihre eigenen Root-Zertifizierungsstellen 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). Die Zertifikatsdatei sollte base64-codierte Daten enthalten, denen ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ vorangestellt ist und ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• Für den privaten Schlüssel empfehlen wir die Verwendung des Formats Public-Key Cryptography Standards (PKCS) #1. Die Schlüsseldatei sollte base64-codierte Daten enthalten, denen ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ vorangestellt ist und ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑ vorangestellt ist.

• Um mögliche Clusterstörungen zu minimieren, sollten benutzerdefinierte Zertifizierungsstellen nicht vor fünf 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 speichern, das für Zertifikate und Schlüssel verwendet wird. Beispielsweise können Sie die Dateien zusammen mit Ihren Dienstkontoschlüsseln 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 mit bmctl einen Cluster erstellen, aktualisieren Sie zuerst die Clusterkonfigurationsdatei, um die Clusterfeatures und -einstellungen zu beschreiben. Wenn Sie beim Erstellen des Clusters das Feature für benutzerdefinierte Cluster-Zertifizierungsstellen verwenden möchten, haben Sie zwei Möglichkeiten, die benutzerdefinierten Cluster-Zertifizierungsstellen in der Clusterkonfigurationsdatei anzugeben:

• 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 im selben Verzeichnis nach den entsprechenden CA-Zertifikatsdateien. Zertifikatsdateien müssen denselben 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, erwartet bmctl, dass der Zertifikatspfad /custom-ca/cluster_ca.crt ist.

In beiden Fällen werden die Pfade im Bereich „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 nur die Pfade zu Schlüsseldateien angegeben werden. In diesem Beispiel befinden sich die privaten Schlüsseldateien der Zertifizierungsstelle im selben Verzeichnis wie die JSON-Schlüsseldateien des Dienstkontos. Die entsprechenden Zertifikatsdateien der Zertifizierungsstelle müssen sich ebenfalls im Verzeichnis /.sa-keys befinden. Zertifikatsdateien haben denselben Dateinamen wie die Schlüsseldatei, aber die Erweiterung .crt. Daher hat die etcd-CA-Zertifikatsdatei 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 nur die Pfade zu Schlüsseldateien angegeben werden. In diesem Beispiel wird für alle Cluster-CAs ein einzelnes Zertifikat-Schlüsselpaar verwendet. Das CA-Zertifikat und die Dateien mit dem privaten Schlüssel befinden sich beide im Verzeichnis /custom-ca. Gemäß der Namenskonvention lautet 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

Wenn Sie CAs rotieren, können Sie die Pfade für Ihr benutzerdefiniertes Cluster-CA-Zertifikat und die Dateien mit privatem Schlüssel angeben. Die verfügbaren Optionen ähneln denen, mit denen benutzerdefinierte Cluster-Zertifizierungsstellen während der Clustererstellung angegeben werden können. Wenn Sie den Befehl bmctl update credentials certificate-authorities rotate ausführen, haben Sie folgende Optionen:

• Geben Sie die Pfade für die benutzerdefinierten CA-Zertifikatsdateien und die privaten Schlüsseldateien an.
• Geben Sie nur die Pfade für die benutzerdefinierten privaten Schlüssel der Zertifizierungsstelle an. Die entsprechende CA-Zertifikatsdatei muss sich im selben Verzeichnis befinden, denselben Namen wie die Schlüsseldatei haben und die Dateiendung .crt haben.
• Sie können ein Zertifikat-Schlüsselpaar einer Zertifizierungsstelle wiederverwenden, indem Sie dasselbe Zertifikat und dieselben Schlüsselpfade für mehr als eine Cluster-Zertifizierungsstelle angeben.
• Lassen Sie die Argumente für die benutzerdefinierten Zertifizierungsstellenpfade weg. Wenn Sie beim Rotieren von Zertifizierungsstellen keine benutzerdefinierten CA-Pfade angeben, erstellt und verwendet Google Distributed Cloud die Standardcluster-Zertifizierungsstelle.

Beispiel 1: CA-Zertifikat und Pfade für private Schlüssel 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 CA-Zertifikatsdatei des Clusters.
• CLUSTER_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der Cluster-CA.
• ETCD_CA_CERT_PATH: Pfad der etcd-CA-Zertifikatsdatei.
• ETCD_CA_KEY_PATH: Pfad der privaten Schlüsseldatei der etcd-Zertifizierungsstelle.
• FRONT_PROXY_CA_CERT_PATH: Pfad der Front-Proxy-Zertifikatsdatei
• 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-Zertifizierungsstelle.
• 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 Zwischen-CAs als Vorabversion. Diese Funktion befindet sich nicht bei allen unterstützten Produktversionen in derselben Markteinführungsphase:

• 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 für die Verwendung von Zwischen-CAs drei Gruppen von Zertifizierungsstellen vorbereiten. Jede Zertifizierungsstelle besteht aus einer CA-Zertifikatsdatei und ihrer entsprechenden privaten Schlüsseldatei. Sie stellen ein CA-Zertifikat und ein Schlüsselpaar für jede der folgenden erforderlichen Cluster-CAs bereit:

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

Wie bei Stammzertifizierungsstellen können Sie für jede Zertifizierungsstelle ein eindeutiges Zertifikat-Schlüsselpaar bereitstellen oder ein Zertifikatschlüsselpaar für mehrere Zertifizierungsstellen wiederverwenden, indem Sie in der CA-Konfiguration denselben Dateipfad angeben.

Wenn Sie Zwischen-CAs verwenden, sollte die CA-Zertifikatsdatei die gesamte Zertifikatskette enthalten, einschließlich Zertifikaten von den Zwischen-CAs bis zur Stamm-CA. Die Zertifikate sind in umgekehrter Reihenfolge ihrer Signatur aufgelistet. Das letzte Zwischen-CA-Zertifikat befindet sich ganz oben und das Stamm-CA-Zertifikat unten.

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

• Die Stammzertifizierungsstelle hat das Zertifikat der Zwischenzertifizierungsstelle signiert
• Die Zertifizierungsstelle „Zwischenstufe A“ hat das Zertifikat der Zertifizierungsstelle „Zwischenstufe B“ signiert
• Die Kette fährt bis zum endgültigen Zertifikat der Zertifizierungsstelle „Zwischen Y“ fort, das von der Zertifizierungsstelle „Zwischen 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 dieses Beispiel fortzusetzen, sollte der mit dem Zertifikat der Zwischen-Y-Zertifizierungsstelle verknüpfte private Schlüssel zusammen mit den CA-Zertifikatsketten auf dieselbe Weise wie bei einer benutzerdefinierten Zertifizierungsstelle übergeben werden.

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

Wenn Sie prüfen möchten, ob der Cluster die Zwischenzertifizierungsstelle verwendet, 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