Benutzerdefinierte Cluster-Zertifizierungsstellen verwenden

Cluster-Zertifizierungsstellen 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 GKE on Bare Metal die Cluster-Zertifizierungsstellen, wenn Sie einen neuen Cluster erstellen. In diesem Dokument wird beschrieben, wie Sie Ihre eigenen Zertifizierungsstellen mit GKE on Bare Metal verwenden können. Mit benutzerdefinierten Cluster-Zertifizierungsstellen haben Sie mehr Kontrolle über die Ausstellung und Verwaltung Ihrer Clusterzertifikate. Sie können auch die Vertrauensstellung, die Parameter des Verschlüsselungsalgorithmus, die Tiefe von untergeordneten Zertifikaten und ihren Zweck steuern.

Wenn Sie benutzerdefinierte Zertifizierungsstellen verwenden möchten, stellen Sie Root-Zertifizierungsstellen zur Verfügung, die aus einer CA-Zertifikatsdatei und der entsprechenden privaten Schlüsseldatei bestehen. Für jede der folgenden erforderlichen Cluster-CAs wird ein Zertifikat/Schlüsseldatei-Paar der Zertifizierungsstelle bereitgestellt:

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

  • Cluster-Zertifizierungsstelle: Das Zertifikat für die Cluster-Zertifizierungsstelle sichert die Kommunikation zwischen dem Kubernetes API-Server und allen internen Kubernetes API-Clients. Zu den Clients gehören das Kubelet, der Controller-Manager und der Planer.

  • Front-Proxy-Zertifizierungsstelle: 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 angeben oder ein Zertifikat/Schlüsselpaar für mehrere Zertifizierungsstellen wiederverwenden.

Sie wenden die Zertifikat/Schlüsselpaare bei der Clustererstellung (nur bmctl-Methode) und der CA-Rotation an. Das Feature für benutzerdefinierte Cluster-Zertifizierungsstellen funktioniert mit allen Clustertypen: Administrator, Nutzer, Hybrid und eigenständig.

Vorbereitung

Sie sind selbst dafür verantwortlich, Ihre eigenen Root-Zertifizierungsstellen gemäß den folgenden Regeln vorzubereiten:

  • Benutzerdefinierte Zertifizierungsstellen sind Root-Zertifizierungsstellen, die jeweils aus einer selbst signierten Zertifikatsdatei und einer Datei mit einem privaten Schlüssel bestehen.

  • Zwischen- und untergeordnete Zertifizierungsstellen werden nicht unterstützt.

  • Wir empfehlen, für Ihr Zertifikat das Format Distinguished Encoding Rules (DER) zu verwenden (siehe Empfehlung zu X.690 für ASN.1-Codierungsregeln). Die Zertifikatsdatei sollte base64-codierte Daten enthalten, denen ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ und dann ‑‑‑‑END CERTIFICATE‑‑‑‑‑ vorangestellt ist.

  • Für den privaten Schlüssel empfehlen wir, das Format Public-Key Cryptography Standards (PKCS) #1 zu verwenden. Die Schlüsseldatei muss base64-codierte Daten enthalten, denen ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ und dann ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑ folgen.

  • Um potenzielle Clusterunterbrechungen zu minimieren, sollten benutzerdefinierte Zertifizierungsstellen nicht vor Ablauf von fünf Jahren ablaufen. Wir empfehlen eine längere Ablaufzeit, z. B. 10 bis 30 Jahre.

  • Die Zertifikat- und Schlüsseldateien müssen sich auf der Administratorworkstation befinden, auf der Sie die bmctl-Befehlszeile 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 des Clusters verwenden

Wenn Sie mit bmctl einen Cluster erstellen, aktualisieren Sie zuerst die Clusterkonfigurationsdatei, um die Clusterfunktionen und -einstellungen zu beschreiben. Wenn Sie die Funktion für benutzerdefinierte Cluster-Zertifizierungsstellen während der Clustererstellung 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 die Pfade nur für die Dateien mit den privaten Schlüsseln 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 des privaten Schlüssels beispielsweise /custom-ca/cluster_ca.key ist, erwartet bmctl als Zertifikatspfad /custom-ca/cluster_ca.crt.

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 die Pfade zu den Zertifikat- und Schlüsseldateien für jede Cluster-Zertifizierungsstelle angegeben werden. In diesem Beispiel befinden sich die Zertifikat- und Schlüsseldateien der Zertifizierungsstelle im selben Verzeichnis wie die JSON-Schlüsseldateien des Dienstkontos.

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üssel der Zertifizierungsstelle im selben Verzeichnis wie die JSON-Schlüsseldateien des Dienstkontos. Auch die entsprechenden CA-Zertifikatsdateien müssen sich im Verzeichnis /.sa-keys befinden. Zertifikatsdateien haben den gleichen Dateinamen wie die Schlüsseldateien, haben jedoch die Erweiterung .crt. Der Name der etcd-CA-Zertifikatsdatei lautet also etcd_ca.crt.

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-Zertifizierungsstellen 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.

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 das benutzerdefinierte CA-Zertifikat des Clusters und die Dateien mit den privaten Schlüsseln angeben. Die verfügbaren 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 Möglichkeiten:

  • Geben Sie die Pfade für die benutzerdefinierten CA-Zertifikatsdateien und die Dateien mit dem privaten Schlüssel an.
  • Geben Sie die Pfade nur für die privaten Schlüssel der benutzerdefinierten Zertifizierungsstelle an. Die entsprechende CA-Zertifikatsdatei muss sich im selben Verzeichnis befinden, denselben Namen wie die Schlüsseldatei und die Dateiendung .crt haben.
  • Sie können ein CA-Zertifikat/Schlüsselpaar wiederverwenden. Geben Sie dazu dasselbe Zertifikat und dieselben Schlüsselpfade für mehr als eine Cluster-Zertifizierungsstelle an.
  • Lassen Sie die Argumente für die benutzerdefinierten Zertifizierungsstellenpfade weg. Wenn Sie beim Rotieren von Zertifizierungsstellen keine benutzerdefinierten Zertifizierungsstellenpfade angeben, erstellt und verwendet GKE on Bare Metal die Standard-Cluster-Zertifizierungsstelle.

Beispiel 1: Pfade für CA-Zertifikat und privaten 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: der Pfad der Cluster-CA-Zertifikatsdatei.
  • CLUSTER_CA_KEY_PATH: der Pfad zur privaten Schlüsseldatei der Cluster-Zertifizierungsstelle.
  • ETCD_CA_CERT_PATH: der Pfad der etcd-CA-Zertifikatsdatei.
  • ETCD_CA_KEY_PATH: der Pfad der privaten Schlüsseldatei der etcd-Zertifizierungsstelle.
  • FRONT_PROXY_CA_CERT_PATH: der Pfad der Front-Proxy-Zertifikatsdatei.
  • FRONT_PROXY_CA_KEY_PATH: der Pfad zur 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: der Pfad zur privaten Schlüsseldatei der Cluster-Zertifizierungsstelle.
  • ETCD_CA_KEY_PATH: der Pfad der privaten Schlüsseldatei der etcd-Zertifizierungsstelle.
  • FRONT_PROXY_CA_KEY_PATH: der Pfad zur privaten Schlüsseldatei des Front-Proxys.