Verwalten von Clustergeheimnissen

In diesem Thema wird erläutert, wie Sie geheime Schlüssel konfigurieren und verwalten, die von Arbeitslastclustern in Tanzu Kubernetes Grid verwendet werden, einschließlich:

• Anmeldedaten, die Cluster für den Zugriff auf Cloud-Infrastruktur-APIs und -Ressourcen verwenden Informationen finden Sie unter Aktualisieren von Cluster-Anmeldedaten.
• Clientzertifikate, die von internen Clusterkomponenten zum Authentifizieren von Anforderungen verwendet werden (nur von einem eigenständigen Verwaltungscluster bereitgestellte Arbeitslastcluster). Informationen finden Sie unter Verlängern von Clusterzertifikaten.
• Zertifizierungsstellenzertifikate, die Cluster für den Zugriff auf private Containerregistrierungen verwenden Weitere Informationen finden Sie unter Konfigurieren von Clustern mit mehreren vertrauenswürdigen Registrierungen und Hinzufügen von benutzerdefiniertem CA-Zertifikatvertrauen zu bestehenden Clustern.
• Anmeldedaten, die Cluster für den Zugriff auf authentifizierte private Containerregistrierungen verwenden Konfigurieren der Authentifizierung für eine private Container-Registrierung.

Aktualisieren von Anmeldedaten für Cluster

Wenn sich die Anmeldedaten, die Sie für den Zugriff auf vSphere oder Azure verwenden, ändern, können Sie Ihre Cluster aktualisieren, um die neuen Anmeldedaten zu verwenden. AWS verarbeitet Anmeldedaten unterschiedlich, sodass dieser Abschnitt nur für vSphere und Azure gilt.

vSphere

Aktualisieren von Anmeldedaten für eigenständige Verwaltung und Arbeitslastcluster

Verwenden Sie den Befehl tanzu mc credentials update --cascading, um die Anmeldedaten von vSphere zu aktualisieren, die vom aktuellen eigenständigen Verwaltungscluster und all seinen Arbeitslastclustern verwendet werden:

1. Führen Sie tanzu context use MGMT-CLUSTER aus, um sich beim Verwaltungscluster, den Sie gerade aktualisieren, anzumelden.

2. Führen Sie tanzu mc credentials update aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:

   • --vsphere-user: Name für das vSphere-Konto.
   • --vsphere-password: Kennwort für das vSphere-Konto.
   • --vsphere-thumbprint: TLS-Fingerabdruck der vCenter Server-Instanz.

Exklusives Aktualisieren von Anmeldedaten für eigenständigen Verwaltungscluster

Um die vSphere-Anmeldedaten eines eigenständigen Verwaltungsclusters zu aktualisieren, ohne sie auch für seine Arbeitslastcluster zu aktualisieren, verwenden Sie wie oben beschrieben den Befehl tanzu mc credentials update, jedoch ohne die Option --cascading.

Aktualisieren von Anmeldedaten für Arbeitslastcluster

Verwenden Sie den Befehl tanzu cluster credentials update, um die Anmeldedaten zu aktualisieren, die ein einzelner Arbeitslastcluster für den Zugriff auf vSphere verwendet:

1. Führen Sie tanzu context use MGMT-CLUSTER aus, um sich bei dem Verwaltungscluster anzumelden, der den Arbeitslastcluster erstellt hat, den Sie gerade aktualisieren. Der Verwaltungscluster kann der Supervisor-Cluster oder der eigenständige Verwaltungscluster sein.

2. Führen Sie tanzu cluster credentials update CLUSTER-NAME aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:

   • --namespace: Der Namespace des Clusters, für den Sie die Anmeldedaten aktualisieren, z B. default.
   • --vsphere-user: Name für das vSphere-Konto.
   • --vsphere-password: Kennwort für das vSphere-Konto.
   • --vsphere-thumbprint: TLS-Fingerabdruck der vCenter Server-Instanz.

Sie können auch tanzu mc credentials update --cascading verwenden, um vSphere-Anmeldedaten für einen Verwaltungscluster und alle von ihm verwalteten Arbeitslastcluster zu aktualisieren.

AWS

Dieser Abschnitt gilt nicht für AWS-Bereitstellungen.

Azure

Aktualisieren von Anmeldedaten für eigenständige Verwaltung und Arbeitslastcluster

Wichtig

Bevor Sie beginnen, rufen Sie die neuen Azure-Anmeldedaten vom Azure-Portal oder von Ihrem Azure-Administrator ab.

Um die Azure-Anmeldedaten zu aktualisieren, die vom aktuellen eigenständigen Verwaltungscluster und allen seinen Arbeitslastclustern verwendet werden, verwenden Sie den Befehl tanzu mc credentials update --cascading:

1. Führen Sie tanzu context use MGMT-CLUSTER aus, um sich beim Verwaltungscluster, den Sie gerade aktualisieren, anzumelden.

2. Führen Sie tanzu mc credentials update aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:

   • --azure-client-id: Die Client-ID der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben
   • --azure-client-secret: Der geheime Clientschlüssel der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben
   • --azure-tenant-id: Die Mandanten-ID für Azure Active Directory, in dem sich die App für Tanzu Kubernetes Grid befindet.

Exklusives Aktualisieren von Anmeldedaten für eigenständigen Verwaltungscluster

Um die Azure-Anmeldedaten eines eigenständigen Verwaltungsclusters zu aktualisieren, ohne sie auch für seine Arbeitslastcluster zu aktualisieren, verwenden Sie wie oben beschrieben den Befehl tanzu mc credentials update, jedoch ohne die Option --cascading.

Aktualisieren von Anmeldedaten für Arbeitslastcluster

Verwenden Sie den Befehl tanzu cluster credentials update, um die Anmeldedaten zu aktualisieren, die ein einzelner Arbeitslastcluster für den Zugriff auf Azure verwendet:

1. Führen Sie tanzu context use MGMT-CLUSTER aus, um sich bei dem Verwaltungscluster anzumelden, der den Arbeitslastcluster erstellt hat, den Sie gerade aktualisieren.

2. Führen Sie tanzu cluster credentials update CLUSTER-NAME aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:

   • --namespace: Der Namespace des Clusters, für den Sie die Anmeldedaten aktualisieren, z B. default.
   • --azure-client-id: Die Client-ID der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben
   • --azure-client-secret: Der geheime Clientschlüssel der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben
   • --azure-tenant-id: Die Mandanten-ID für Azure Active Directory, in dem sich die App für Tanzu Kubernetes Grid befindet.

Sie können auch tanzu mc credentials update --cascading verwenden, um Azure-Anmeldedaten für einen Verwaltungscluster und alle von ihm verwalteten Arbeitslastcluster zu aktualisieren.

Automatische Verlängerung des Zertifikats von Steuerungsebenen-Knoten

Konfigurieren Sie TKG-Cluster so, dass ihre VM-Zertifikate des Steuerungsebenen-Knotens je nach Konfigurationsmethode und Clustertyp wie folgt automatisch erneuert werden:

• Objektspezifikation im Kubernetes-Stil (klassenbasierte Cluster):

  • Schließen Sie in Ihre Cluster-Objektspezifikation den folgenden Block unter spec.topology.variables ein:

    - name: controlPlaneCertificateRotation.activate
    value: true
    - name: controlPlaneCertificateRotation.daysBefore
    value: EXPIRY-DAYS
    

• Flache Clusterkonfigurationsdatei (klassenbasierte oder Legacy-Cluster):

  • Nehmen Sie die folgenden Einstellungen in Ihre Clusterkonfigurationsdatei auf:

    CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
    CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
    

Dabei ist EXPIRY-DAYS eine optionale Einstellung für die Anzahl der Tage vor dem Ablaufdatum des Zertifikats, um Clusterknotenzertifikate automatisch zu verlängern. Standard: 90; minimum: 7.

Verlängern von Clusterzertifikaten (eigenständiger MC)

Die eigenständige Verwaltung und ihre Arbeitslastcluster verwenden Clientzertifikate zur Authentifizierung von Anforderungen. Diese Zertifikate sind ein Jahr lang gültig. Um sie zu verlängern, können Sie entweder ein Upgrade Ihrer Cluster oder das folgende Verfahren durchführen. Dieses Verfahren ist für Clusterzertifikate vorgesehen, die noch nicht abgelaufen und noch gültig sind.

1. Identifizieren Sie den Cluster, für den Sie seine Zertifikate verlängern möchten. Beispiel:

   tanzu cluster list
   NAME                 NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
   workload-slot35rp10  default    running  3/3           3/3      v1.27.5+vmware.1  <none>  prod  v1.27.5---vmware.2-tkg.1
   

   Führen Sie folgenden Befehl aus, um die Clusterknoten aufzulisten:

   kubectl get nodes -o wide
   

2. Überprüfen Sie das Ablaufdatum für die Zertifikate:

   vSphere

   Führen Sie den folgenden Befehl aus.

   kubectl get nodes \
   -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   -l node-role.kubernetes.io/master= > nodes
   
   for i in `cat nodes`; do
      printf "\n######\n"
      ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
      ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
   done;
   

   AWS

   Führen Sie den folgenden Befehl aus.

   kubectl get nodes \
   -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
   -l node-role.kubernetes.io/master= > nodes
   
   for i in `cat nodes`; do
       printf "\n######\n"
       ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i hostname
       ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i sudo kubeadm certs check-expiration
   done;
   

   Azure

   Führen Sie den folgenden Befehl aus.

   kubectl get nodes \
   -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
   -l node-role.kubernetes.io/master= > nodes
   
   for i in `cat nodes`; do
       printf "\n######\n"
       ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i hostname
       ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i sudo kubeadm certs check-expiration
   done;
   

   Beispielausgabe:

   ######
   workload-slot35rp10-control-plane-ggsmj
   [check-expiration] Reading configuration from the cluster...
   [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
   W0923 17:51:03.686273 4172778 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
   
   CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
   admin.conf                 Sep 21, 2023 23:13 UTC   363d            ca                      no
   apiserver                  Sep 21, 2023 23:13 UTC   363d            ca                      no
   apiserver-etcd-client      Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   apiserver-kubelet-client   Sep 21, 2023 23:13 UTC   363d            ca                      no
   controller-manager.conf    Sep 21, 2023 23:13 UTC   363d            ca                      no
   etcd-healthcheck-client    Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   etcd-peer                  Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   etcd-server                Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   front-proxy-client         Sep 21, 2023 23:13 UTC   363d            front-proxy-ca          no
   scheduler.conf             Sep 21, 2023 23:13 UTC   363d            ca                      no
   
   CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
   ca                      Sep 18, 2032 23:09 UTC   9y              no
   etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
   front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
   

3. Setzen Sie den kubectl-Kontext auf den Verwaltungscluster. Beispiel:

   kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
   

4. Rufen Sie den Namen des KCP-Objekts für Ihren Zielcluster ab. Beispiel:

   kubectl get kcp
   
   NAME                                CLUSTER               INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
   workload-slot35rp10-control-plane   workload-slot35rp10   true          true                   3          3       3         0             42h   v1.27.5+vmware.1
   

5. Verlängern Sie die Zertifikate, indem Sie ein Rollout der Steuerungsebene auslösen:

   kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
   

   Nachdem Sie diesen Befehl ausgeführt haben, beginnt Tanzu Kubernetes Grid mit der erneuten Bereitstellung Ihrer Clustermaschinen:

   kubectl get machines
   
   workload-slot35rp10-control-plane-7z95k     workload-slot35rp10                                                                                                Provisioning   20s   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-ggsmj     workload-slot35rp10   workload-slot35rp10-control-plane-ggsmj     vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-hxbxb     workload-slot35rp10   workload-slot35rp10-control-plane-hxbxb     vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-sm4nw     workload-slot35rp10   workload-slot35rp10-control-plane-sm4nw     vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-md-0-667bcd6b57-79br9   workload-slot35rp10   workload-slot35rp10-md-0-667bcd6b57-79br9   vsphere://420142a2-d141-7d6b-b322-9c2afcc47da5   Running        42h   v1.27.5+vmware.1
   ...
   

6. Wenn alle Maschinen den Zustand Running aufweisen, stellen Sie sicher, dass die Zertifikatsverlängerung erfolgreich abgeschlossen wurde:

   1. Setzen Sie den kubectl-Kontext auf den Arbeitslastcluster:

      kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
      

   2. Überprüfen Sie das Ablaufdatum für die Zertifikate erneut:

      kubectl get nodes \
      -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
      -l node-role.kubernetes.io/master= > nodes
      
      for i in `cat nodes`; do
        printf "\n######\n"
        ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
        ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
      done;
      

      Beispielausgabe:

      ######
      workload-slot35rp10-control-plane-4xgw8
      [check-expiration] Reading configuration from the cluster...
      [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
      
      W0923 18:10:02.660438   13427 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
      CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
      admin.conf                 Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver                  Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver-etcd-client      Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      apiserver-kubelet-client   Sep 23, 2023 18:05 UTC   364d            ca                      no
      controller-manager.conf    Sep 23, 2023 18:05 UTC   364d            ca                      no
      etcd-healthcheck-client    Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-peer                  Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-server                Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      front-proxy-client         Sep 23, 2023 18:05 UTC   364d            front-proxy-ca          no
      scheduler.conf             Sep 23, 2023 18:05 UTC   364d            ca                      no
      
      CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
      ca                      Sep 18, 2032 23:09 UTC   9y              no
      etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
      front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
      

      Wenn die Zertifikatsverlängerung erfolgreich abgeschlossen wurde, wird in der Spalte Residual Time 364d angezeigt. Zertifikate auf Worker-Knoten werden automatisch erneuert.

Konfigurieren von Clustern mit vertrauenswürdigen Registrierungen (Supervisor)

Informationen zum Konfigurieren eines von Supervisor bereitgestellten TKG-Clusters für die Verwendung einer privaten Containerregistrierung außerhalb von TKG (d. h., einer Registrierung mit einem selbstsignierten Zertifikat, das nicht in einem TKG-Cluster ausgeführt wird) finden Sie in den folgenden Themen in der vSphere-Dokumentation:

• vSphere 8: Integrieren eines TKG 2-Clusters in eine private Container-Registrierung
• vSphere 7: Verwenden einer externen Container-Registrierung mit Tanzu Kubernetes-Clustern

Konfigurieren von Clustern mit mehreren vertrauenswürdigen Registrierungen (eigenständiger MC)

In einer Umgebungen mit Internetbeschränkungen und einem eigenständigen Verwaltungscluster können Sie TKG_CUSTOM_IMAGE_REPOSITORY_*-Variablen konfigurieren, um TKG-Clustern Zugriff auf eine private Registrierung zu gewähren, die TKG-System-Images enthält, über die gestartet werden kann, wie z. B. eine Harbor-VM (siehe Beschreibung unter Bereitstellen einer Offline-Harbor-Registrierung auf vSphere).

Mithilfe der ADDITIONAL_IMAGE_REGISTRY_*-Variablen wird ein neuer Cluster für eine vertrauenswürdige Kommunikation mit zusätzlichen Registrierungen konfiguriert, die selbstsignierte Zertifikate der Zertifizierungsstelle (CA) verwenden, wie z. B.:

• Eine private Registrierung, die als Paket-Repository für die Installation von CLI-verwalteten Paketen dient.
• Eine skalierbare, selbstsignierte Harbor-Registrierung für von TKG gehostete App-Images, die mit dem Harbor-Paket bereitgestellt wird (siehe Beschreibung unter Installieren von Harbor für die Dienstregistrierung).
• Eine selbstsignierte Image-Registrierung für containerd (siehe Beschreibung unter Konfigurieren der Image-Registrierung im containerd-Repository).

Die Konfiguration von Clustern zum Herstellen einer Vertrauensstellung für diese privaten Registrierungen richtet sich danach, ob der Cluster plan- oder klassenbasiert ist (siehe folgende Beschreibung).

Vertrauenswürdige Registrierungen für einen klassenbasierten Cluster

Zum Konfigurieren eines klassenbasierten Arbeitslastclusters oder eines eigenständigen Verwaltungsclusters mit Vertrauensstellung für zusätzliche benutzerdefinierte Image-Registrierungen legen Sie die Variablen für bis zu drei zusätzliche Image-Registrierungen wie folgt fest:

• Für die Konfiguration von mehr als drei Registrierungen konfigurieren Sie die ersten drei wie folgt in Schritt 1 eines zweistufigen Prozesses, der unter Erstellen eines klassenbasierten Clusters beschrieben wird. Führen Sie dann die Anweisungen unter Herstellen einer Vertrauensstellung zwischen einem klassenbasierten Cluster und einer benutzerdefinierten Registrierung durch, um dem erzeugten Manifest weitere Registrierungen hinzuzufügen, bevor Sie den Cluster in Schritt 2 erstellen.

  ADDITIONAL_IMAGE_REGISTRY_1: "OTHER-REGISTRY-1"
  ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: "CA-BASE64-1"
  
  ADDITIONAL_IMAGE_REGISTRY_2: "OTHER-REGISTRY-2"
  ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE: "CA-BASE64-2"
  
  ADDITIONAL_IMAGE_REGISTRY_3: "OTHER-REGISTRY-3"
  ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE: "CA-BASE64-3"
  

  Wobei OTHER-REGISTRY-<n> die IP-Adresse oder der FQDN einer zusätzlichen privaten Registrierung und CA-BASE64-<n> das zugehörige CA-Zertifikat im Base64-codierten Format ohne das Präfix http:// darstellt. Dies ist notwendig, da diese Datei auf die Festplatte geschrieben wird. Folglich muss es sich um einen normalen Unix-Dateinamen handeln.

Vertrauenswürdige Registrierungen für einen neuen planbasierten Cluster

Damit ein neuer TKC- oder planbasierter Cluster Images aus Container-Registrierungen abrufen kann, die selbstsignierte Zertifikate verwenden, fügen Sie den Arbeitslastclusterknoten die benutzerdefinierten Zertifikate mithilfe einer Overlay-Datei vom Typ ytt hinzu.

Der folgende Overlay-Code fügt benutzerdefinierte CA-Zertifikate zu allen Knoten in einem neuen Cluster hinzu. Der Code funktioniert auf allen Zielplattformen für Cluster, die auf Photon- oder Ubuntu-VM-Image-Vorlagen basieren.

Informationen zu Overlays, die Cluster anpassen und einen neuen Cluster-Plan erstellen, finden Sie unter ytt-Overlays. Informationen zum Herunterladen und Installieren von ytt finden Sie unter Installieren der Carvel-Tools.

1. Wählen Sie aus, auf welche Cluster die benutzerdefinierte Zertifizierungsstelle angewendet werden soll: auf alle Cluster, nur auf die in einer Cloud-Infrastruktur erstellten Cluster oder auf Cluster, die mit einer bestimmten Version des Cluster-API-Anbieters erstellt wurden, wie z. B. Cluster-API-Anbieter vSphere v1.5.1.

2. Suchen Sie im lokalen ~/.config/tanzu/tkg/providers/-Verzeichnis das ytt-Verzeichnis, das den von Ihnen gewählten Geltungsbereich abdeckt. Beispiel: /ytt/03_customizations/ gilt für alle Cluster, und /infrastructure-vsphere/ytt/ gilt für alle vSphere-Cluster.

3. Erstellen Sie im ausgewählten ytt-Verzeichnis eine neue .yaml-Datei oder erweitern Sie eine vorhandene Overlay-Datei um den folgenden Code:

   #@ load("@ytt:overlay", "overlay")
   #@ load("@ytt:data", "data")
   
   #! This ytt overlay adds additional custom CA certificates on TKG cluster nodes, so containerd and other tools trust these CA certificates.
   #! It works when using Photon or Ubuntu as the TKG node template on all TKG target platforms.
   
   #! Trust your custom CA certificates on all Control Plane nodes.
   #@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
   ---
   spec:
     kubeadmConfigSpec:
       #@overlay/match missing_ok=True
       files:
         #@overlay/append
         - content: #@ data.read("tkg-custom-ca.pem")
           owner: root:root
           permissions: "0644"
           path: /etc/ssl/certs/tkg-custom-ca.pem
       #@overlay/match missing_ok=True
       preKubeadmCommands:
         #! For Photon OS
         #@overlay/append
         - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
         #! For Ubuntu
         #@overlay/append
         - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
   
   #! Trust your custom CA certificates on all worker nodes.
   #@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
   ---
   spec:
     template:
       spec:
         #@overlay/match missing_ok=True
         files:
           #@overlay/append
           - content: #@ data.read("tkg-custom-ca.pem")
             owner: root:root
             permissions: "0644"
             path: /etc/ssl/certs/tkg-custom-ca.pem
         #@overlay/match missing_ok=True
         preKubeadmCommands:
           #! For Photon OS
           #@overlay/append
           - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
           #! For Ubuntu
           #@overlay/append
           - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
   

4. Fügen Sie im selben ytt-Verzeichnis die Zertifizierungsstelle zu einer neuen oder vorhandenen tkg-custom-ca.pem-Datei hinzu.

5. Legen Sie vor dem Erstellen des Clusters die Funktion allow-legacy-cluster auf true fest, wie unter (Legacy) Erstellen eines planbasierten oder TKC-Clusters beschrieben.

Hinzufügen von benutzerdefiniertem CA-Zertifikatvertrauen zu bestehenden Clustern (eigenständiger MC)

Sie können vertrauenswürdige Kommunikation zwischen einem vorhandenen Cluster und zusätzlichen benutzerdefinierten Harbor-Registrierungen mit selbstsignierten Zertifizierungsstellen, die über die von den TKG_CUSTOM_IMAGE_REPOSITORY_*-Konfigurationsvariablen festgelegten hinausgehen, für containerd-TLS und zu anderen Zwecken aktivieren. Die entsprechende Vorgehensweise richtet sich danach, ob der Cluster plan- oder klassenbasiert ist (siehe folgende Beschreibung).

Herstellen einer Vertrauensstellung zwischen einem klassenbasierten Cluster und einer benutzerdefinierten Registrierung

Zum Hinzufügen einer vertrauenswürdigen benutzerdefinierten Registrierung zu einem vorhandenen klassenbasierten Cluster bearbeiten Sie das Cluster-Objekt und fügen additionalImageRegistries-Einstellungen unter topology.variables in der Objektspezifikation hinzu:

topology:
  variables:
  - name: additionalImageRegistries
    value:
    - caCert: "CA-BASE64"
      host: OTHER-REGISTRY
      skipTlsVerify: false

Dabei gilt:

• OTHER-REGISTRY ist der zusätzliche Speicherort für die private Registrierung im Format : . Beispiel: 10.92.127.192:8443.
• CA-BASE64 ist das zugehörige CA-Zertifikat im Base64-codierten Format, wie z. B. LS0tLS1CRU[...].

Zum Hinzufügen einer Vertrauensstellung für mehrere Registrierungen schließen Sie mehrere additionalImageRegistries-Wertblöcke ein.

Beachten Sie, dass die topology.variables-Blöcke für imageRepository und trust Werte aus den Konfigurationsvariablen TKG_CUSTOM_IMAGE_REPOSITORY_* und TKG_PROXY_CA_CERT festlegen.

Herstellen einer Vertrauensstellung zwischen einem planbasierten Cluster und einer benutzerdefinierten Registrierung

So aktivieren Sie die Vertrauensstellung zwischen einem planbasierten Cluster und einer Harbor-Registrierung mit einer selbstsignierten Zertifizierungsstelle:

1. Rufen Sie das Harbor-CA-Zertifikat ab:

   1. Wechseln Sie den Kontext zu dem Cluster, auf dem Harbor ausgeführt wird, z. B. zu einem Cluster mit gemeinsam genutzten Diensten:

      kubectl config use-context SERVICES-CLUSTER-CONTEXT
      

      Dabei ist SERVICES-CLUSTER-CONTEXT der Kontext des Clusters. Beispiel: tkg-wld-admin@tkg-wld.

   2. Rufen Sie das Zertifikat ab:

      kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
      -----BEGIN CERTIFICATE-----
      MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
      [...]
      yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
      -----END CERTIFICATE-----
      

2. Fügen Sie die benutzerdefinierte Zertifizierungsstelle zur kubeadmconfigtemplate des eigenständigen Verwaltungsclusters hinzu:

   1. Wechseln Sie den Kontext zum Verwaltungscluster.

      kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
      

      Dabei ist MANAGEMENT-CLUSTER-CONTEXT der Kontext Ihres Verwaltungsclusters. Beispiel: tkg-mgmt-admin@tkg-mgmt.

   2. Öffnen Sie in einem Editor die Vorlagendatei kubeadmconfigtemplate des Clusters:

      kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
      

      Dabei ist CLUSTER-NAME der Name des Clusters, der geändert werden muss.

   3. Ändern Sie den Abschnitt spec.template.spec.files, um das Zertifikat einzuschließen, wie im folgenden Beispiel dargestellt:

      spec:
      template:
        spec:
          files:
          - content: |
                -----BEGIN CERTIFICATE-----
               MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
               [...]
               yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
               -----END CERTIFICATE-----
             owner: root:root
             path: /etc/ssl/certs/tkg-custom-ca.pem
             permissions: "0644"
      

   4. Fügen Sie unten in der Datei einen Block preKubeadmCommands wie im folgenden Beispiel dargestellt hinzu:

      preKubeadmCommands:
      - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
      - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem
         /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
      

3. Speichern Sie die Vorlagendatei kubeadmconfigtemplate mit Ihren Änderungen.

4. Patchen Sie den eigenständigen Verwaltungscluster mit den Änderungen:

   kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
   

   Wenn Sie diesen Befehl ausführen, wird ein paralleles Update der Clusterknoten ausgelöst und deren Zeitstempel aktualisiert.

Konfigurieren der Authentifizierung für eine private Container-Registrierung

Sie können geheime Authentifizierungsschlüssel hinzufügen, um einem Cluster den Zugriff auf eine private Containerregistrierung zu ermöglichen, für die eine Benutzerauthentifizierung zum Abrufen von Images erforderlich ist. Sie können auch die geheimen Authentifizierungsschlüssel anzeigen, aktualisieren oder löschen, die Sie für die privaten Registrierungen konfiguriert haben, auf die ein Cluster zugreift.

Hinzufügen eines geheimen Authentifizierungsschlüssels für eine private Container-Registrierung

Mithilfe der Tanzu CLI können Sie geheime Authentifizierungsschlüssel hinzufügen, um von einem Cluster aus auf eine private Containerregistrierung zuzugreifen. Nachdem der geheime Registrierungsschlüssel zu den Namespaces in Ihrem Cluster hinzugefügt wurde, können Sie alle Paketrepositorys, Pakete und Container-Images abrufen, die in der privaten Registrierung gehostet werden. Anschließend können Sie das Paketrepository und die Paketressourcen zu Ihrem Cluster hinzufügen.

Bevor Sie diesen Vorgang durchführen, müssen Sie den Benutzernamen und das Kennwort für die private Containerregistrierung abrufen.

Führen Sie den folgenden Befehl aus, um einen geheimen Authentifizierungsschlüssel zu einer privaten Registrierung hinzuzufügen:

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD

Dabei gilt:

• SECRET-NAME ist der Name des geheimen Authentifizierungsschlüssels für die Registrierung, den Sie hinzufügen möchten.
• NAMESPACE ist der Tanzu Kubernetes Grid-Namespace, zu dem die Registrierung gehört.
• USERNAME ist der Benutzername für den Zugriff auf die Registrierung. Setzen Sie den Benutzernamen in einfache Anführungszeichen, wenn er Sonderzeichen enthält.

• PASSWORD ist das Kennwort für den Zugriff auf die Registrierung. Setzen Sie das Kennwort in einfache Anführungszeichen, wenn es Sonderzeichen enthält. Sie können das Kennwort auch in den folgenden Formaten angeben:

  • Ersetzen Sie die Zeichenfolge --password PASSWORD im Befehl durch --password-env-var ENV-VAR, um das Kennwort über die Umgebungsvariable anzugeben, die Sie bereits konfiguriert haben. Das Format des Befehls lautet wie folgt:

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR

  • Ersetzen Sie die Zeichenfolge --password PASSWORD im Befehl durch die Zeichenfolge --password-stdin, um das Kennwort über die Standardeingabe anzugeben, und geben Sie das Kennwort ein, wenn Sie dazu aufgefordert werden. Das Format des Befehls lautet wie folgt:

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin

  • Ersetzen Sie die Zeichenfolge --password PASSWORD im Befehl durch die Zeichenfolge --password-file PASSWORD-FILE, um das Kennwort über eine Kennwortdatei anzugeben. Das Format des Befehls lautet wie folgt:

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE

Um optional den geheimen Registrierungsschlüssel für alle Namespaces in einem Cluster verfügbar zu machen, verwenden Sie die Option --export-to-all-namespaces in dem folgenden Format:

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces

Nachfolgend sehen Sie eine Beispielausgabe dieses Befehls:

tanzu secret registry add tanzu-net -n test-ns --server registry.pivotal.io --username test-user --password-file pass-file --export-to-all-namespaces
Warning: By choosing --export-to-all-namespaces, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
/ Adding registry secret 'test-secret'...
  Added registry secret 'test-secret' into namespace 'test-ns'

Anzeigen der geheimen Authentifizierungsschlüssel für die Registrierung in einem Cluster

Sie können die geheimen Authentifizierungsschlüssel für die Registrierung im Standard-Namespace oder in allen Namespaces in einem Cluster anzeigen. Sie können die geheimen Schlüssel in Form einer Tabelle, einer JSON- oder YAML-Datei anzeigen.

Um die geheimen Authentifizierungsschlüssel für die Registrierung in einem bestimmten Namespace in einem Cluster anzuzeigen, führen Sie den folgenden Befehl aus:

tanzu secret registry list -n NAMESPACE

Dabei ist NAMESPACE der Tanzu Kubernetes Grid-Namespace, zu dem die Registrierung gehört.

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  registry.pivotal.io      to all namespaces  15d

Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung in allen Namespaces in einem Cluster anzuzeigen, führen Sie den folgenden Befehl aus:

tanzu secret registry list -A

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry list -A
\ Retrieving registry secrets...
 NAME                          REGISTRY             EXPORTED           AGE  NAMESPACE
 pkg-dev-reg                   registry.pivotal.io  to all namespaces  15d  test-ns
 tanzu-standard-fetch-0        registry.pivotal.io  not exported       15d  tanzu-package-repo-global
 private-repo-fetch-0          registry.pivotal.io  not exported       15d  test-ns
 antrea-fetch-0                registry.pivotal.io  not exported       15d  tkg-system
 metrics-server-fetch-0        registry.pivotal.io  not exported       15d  tkg-system
 tanzu-addons-manager-fetch-0  registry.pivotal.io  not exported       15d  tkg-system
 tanzu-core-fetch-0            registry.pivotal.io  not exported       15d  tkg-system

Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im JSON-Dateiformat anzuzeigen, führen Sie den folgenden Befehl aus:

tanzu secret registry list -n kapp-controller-packaging-global -o json

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry list -n kapp-controller-packaging-global -o json
[
 {
   "age": "15d",
   "exported": "to all namespaces",
   "name": "pkg-dev-reg",
   "registry": "us-east4-docker.pkg.dev"
 }
]

Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im YAML-Dateiformat anzuzeigen, führen Sie den folgenden Befehl aus:

tanzu secret registry list -n kapp-controller-packaging-global -o yaml

Es folgt ein Beispiel für diesen Befehl:

 tanzu secret registry list -n kapp-controller-packaging-global -o yaml
 - age: 15d
   exported: to all namespaces
   name: pkg-dev-reg
   registry: us-east4-docker.pkg.dev

Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im Tabellenformat anzuzeigen, führen Sie den folgenden Befehl aus:

tanzu secret registry list -n kapp-controller-packaging-global -o table

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry list -n kapp-controller-packaging-global -o table
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  us-east4-docker.pkg.dev  to all namespaces  15d

Aktualisieren eines geheimen Authentifizierungsschlüssels für die Registrierung

Sie können die Anmeldedaten in einem geheimen Schlüssel aktualisieren, einen geheimen Schlüssel für alle Namespaces verfügbar machen oder ihn nur in einem Namespace im Cluster verfügbar machen.

Um den geheimen Schlüssel in dem Namespace zu aktualisieren, in dem er erstellt wurde, führen Sie den folgenden Befehl aus:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD

Dabei gilt:

• SECRET-NAME ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.
• NAMESPACE ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.
• USERNAME ist der neue Benutzername für den Zugriff auf die Registrierung (wenn Sie den Benutzernamen aktualisieren möchten).
• PASSWORD ist das neue Kennwort für die Registrierung (wenn Sie das Kennwort aktualisieren möchten).

Hinweis

Sie können entweder den Benutzernamen oder das Kennwort oder beides aktualisieren.

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV
\ Updating registry secret 'test-secret'...
 Updated registry secret 'test-secret' in namespace 'test-ns'

Um den geheimen Authentifizierungsschlüssel für die Registrierung zu aktualisieren und ihn in anderen Namespaces im Cluster verfügbar zu machen, führen Sie den folgenden Befehl aus:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true

Dabei gilt:

• SECRET-NAME ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.
• NAMESPACE ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.
• USERNAME ist der Benutzername für den Zugriff auf die Registrierung. Geben Sie zum Aktualisieren des Benutzernamens einen neuen Benutzernamen ein.
• PASSWORD ist das Kennwort für die Registrierung. Geben Sie zum Aktualisieren des Kennworts ein neues Kennwort ein.

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry update test-secret--username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=true
Warning: By specifying --export-to-all-namespaces as true, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Exported registry secret 'test-secret' to all namespaces

Um die Verfügbarkeit eines geheimen Authentifizierungsschlüssels für die Registrierung in anderen Namespaces im Cluster aufzuheben, führen Sie den folgenden Befehl aus:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false

Dabei gilt:

• SECRET-NAME ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.
• NAMESPACE ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.
• USERNAME ist der Benutzername für den Zugriff auf die Registrierung.
• PASSWORD ist das Kennwort für die Registrierung.

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=false
Warning: By specifying --export-to-all-namespaces as false, the secret contents will get unexported from ALL namespaces in which it was previously available to.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Unexported registry secret 'test-secret' from all namespaces

Löschen eines geheimen Authentifizierungsschlüssels für die Registrierung

Mithilfe der Tanzu CLI können Sie einen geheimen Authentifizierungsschlüssel für die Registrierung in einem Cluster löschen. Um einen geheimen Authentifizierungsschlüssel für die Registrierung in einem bestimmten Namespace zu löschen, führen Sie den folgenden Befehl aus:

tanzu secret registry delete SECRET-NAME -n NAMESPACE

Dabei gilt:

• SECRET-NAME ist der Name des geheimen Registrierungsschlüssels, den Sie löschen möchten.
• (Optional) NAMESPACE ist der Tanzu Kubernetes Grid-Namespace, aus dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung löschen möchten. Wenn Sie keinen Namespace angeben, wird der Authentifizierungsschlüssel aus dem Standard-Namespace gelöscht. Wenn der geheime Schlüssel in andere Namespaces im Cluster exportiert wurde, wird er ebenfalls gelöscht.

Es folgt ein Beispiel für diesen Befehl:

tanzu secret registry delete test-secret -n test-ns
Deleting registry secret 'test-secret' from namespace 'test-ns'. Are you sure? [y/N]: y
\ Deleting registry secret 'test-secret'...
 Deleted registry secret 'test-secret' from namespace 'test-ns'