Bereitstellen des Cert-Managers für Arc-fähige Kubernetes (Vorschau)

In diesem Artikel wird gezeigt, wie Sie die Cert-Manager-Erweiterung (Vorschau) für Arc-fähige Kubernetes in Ihren Arc-verbundenen Clustern bereitstellen. Schritte für eine neue Bereitstellung sind zusammen mit den Anforderungen für die Migration von einem Cluster enthalten, der über Open-Source-Zertifikatsmanager und Trustmanager verfügt.

Voraussetzungen

Stellen Sie vor der Installation von CME sicher, dass Sie die folgenden Voraussetzungen erfüllen:

• Ein Azure Konto. Falls Sie kein Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.

• Ein arcfähiger Kubernetes-Cluster, der in einer unterstützten Region bereitgestellt wird. Um optimale Ergebnisse zu erzielen, verwenden Sie eine Kubernetes-Verteilung, die für die Verwendung mit cert-manager für Arc-fähige Kubernetes überprüft wurde. Falls Sie Ihren Cluster noch nicht mit Azure Arc verbunden haben, folgen Sie unserem Schnellstart. Notieren Sie sich den Clusternamen und Azure Ressourcengruppe, da Sie diese zum Installieren der Erweiterung benötigen.

• Der Azure Ressourcenadministrator für verbundene Computer oder eine entsprechende Rolle in der Clusterressource, mit der Sie Erweiterungen bereitstellen können.

• Die neueste Version von Azure CLI.

• Die neueste Version der Erweiterungen connectedk8s und k8s-extension Azure CLI. Führen Sie die folgenden Befehle aus, um die Erweiterungen zu installieren oder zu aktualisieren:

  az extension add --upgrade -n connectedk8s
  az extension add --upgrade -n k8s-extension
  

• Eine installierte Version von kubectl für Ihren Cluster (Administratorrechte). Während die Installation der Erweiterung nicht unbedingt erforderlich ist, ist Kubectl hilfreich, um die Installation und Verwaltung von benutzerdefinierten Zertifikatressourcen in späteren Schritten zu überprüfen.

• Wenn Sie zuvor open source cert-manager oder trust-manager manuell installiert haben, deinstallieren Sie sie, bevor Sie die Arc-Erweiterung bereitstellen, um Konflikte zu vermeiden. Vorhandene benutzerdefinierte Ressourcen (CRs) werden von der Erweiterung beibehalten und erkannt, solange sie den Konventionen der Open-Source-Projekte entsprechen. Weitere Informationen finden Sie unter Migrieren von Open-Source-cert-manager und trust-manager.

Allgemeine Kenntnisse über Arc-fähige Kubernetes, Cert-Manager und Trust-Manager können hilfreich sein, sind jedoch nicht erforderlich, um die Erweiterung bereitzustellen.

Bereitstellen des Cert-Managers für Arc-fähige Kubernetes

Verwenden Sie den folgenden Befehl, um cert-manager für Arc-enabled Kubernetes (Vorschau) auf einem Cluster bereitzustellen, der noch nicht über cert-manager und trust-manager verfügt und die Voraussetzungen erfüllt:

az k8s-extension create \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management" \
  --extension-type "microsoft.certmanagement" \

Sie können --auto-upgrade-minor-version true hinzufügen, um automatisch Minor-Versionen-Updates zu erhalten, einschließlich neuer Funktionen und nicht-störender Änderungen. Andernfalls können Sie die Erweiterung bei Bedarf manuell aktualisieren , um die neuesten Features und Fixes zu erhalten.

Nachdem die Azure CLI bestätigt hat, dass die Installation erfolgreich war, verifizieren Sie, dass die Komponenten in Ihrem Cluster ausgeführt werden.

Eingeschränkte PSA-Umgebungen

Der Cert-Manager für Azure Arc fähige Kubernetes erfordert privilegierten Zugriff für die Protokollsammlung in Azure für Support- und Problembehandlungszwecke. Für Umgebungen mit eingeschränkten Pod Security Standards (PSA), in denen privilegierter Zugriff nicht zulässig ist, kann die Protokollsammlung in Azure deaktiviert werden, um Sicherheitsanforderungen einzuhalten.

Verwenden Sie --set global.telemetry.logs.enabled=falsezum Deaktivieren der Protokollsammlung . Dadurch wird verhindert, dass Protokollvolumes eingerichtet werden und die Notwendigkeit des privilegierten Zugriffs entfernt wird, während die Metriksammlung wie gewohnt fortgesetzt wird.

Verwenden Sie --set global.telemetry.metrics.enabled=falsezum Deaktivieren der Metriksammlung .

Migrieren von open source Cert-Manager und Trust-Manager

Der Zertifikat-Manager für Azure Arc-fähige Kubernetes-Erweiterung dient als Ersatz für open source cert-manager und trust-manager. Bevor Sie cert-manager für Arc-fähige Kubernetes installieren, müssen Sie die open source Ressourcen deinstallieren.

Bestimmte Schritte für die Deinstallation hängen von Ihrer Installationsmethode ab. Anweisungen finden Sie in der Dokumentation zum Deinstallieren von Zertifikat-Manager und zum Deinstallieren von Trust-Manager. Wenn Sie Helm für die Installation verwendet haben, verwenden Sie diesen Befehl, um zu bestätigen, in welchem Namespaces cert-manager und trust-manager installiert sind:

helm list -A | grep -E 'trust-manager|cert-manager'

Verwenden Sie danach die folgenden Befehle zum Deinstallieren:

helm uninstall cert-manager -n "your namespace" --ignore-not-found
helm uninstall trust-manager -n "your namespace" --ignore-not-found

Konfigurieren des Cert-Managers für Arc-fähige Kubernetes

Nachdem der Zertifikat-Manager für die Arc-fähige Kubernetes-Erweiterung bereitgestellt wurde, konfigurieren Sie, wie Zertifikate ausgestellt werden sollen, und fordern Sie dann ein Zertifikat für eine Workload an. Allgemein sind dies die folgenden Schritte:

1. Erstellen Sie eine Aussteller- oder ClusterIssuer-Ressource, um eine Zertifizierungsstelle anzugeben, die signierte Zertifikate generiert. Dies kann eine selbstsignierte Zertifizierungsstelle (CA), ein Konto sein, das mit einem ACME-Zertifizierungsstellenserver (Automatisierte Zertifikatverwaltungsumgebung) registriert ist, z. B. Let's Encrypt (oder andere), oder eine Zertifizierungsstelle, deren Zertifikat und privater Schlüssel im Cluster als Kubernetes-Schlüssel gespeichert werden.
2. Erstellen Sie eine Zertifikatressource, die eine TLS-Zertifikatanforderung anfordert, und enthält die Felder, die zum Generieren von Zertifikatsignaturanforderungen (Certificate Signing Requests, CSRs) verwendet werden, die dann vom Ausstellertyp erfüllt werden, der für die Ressource für eine bestimmte Domäne oder Verwendung referenziert wird.
3. Lassen Sie den Cert-Manager die Anforderung erfüllen, was dazu führt, dass ein signiertes Zertifikat und ein privater Schlüssel in einem Kubernetes-Geheimnis gespeichert werden, das Ihre Anwendung verwenden kann.
4. Optional, wenn Ihr Szenario benutzerdefinierte Vertrauenswurzeln über Namespaces hinweg erfordert, verwenden Sie den Trust-Manager, um die benutzerdefinierten CA-Zertifikate clusterweit zu verteilen.

In den folgenden Abschnitten wird ein Beispielszenario zum Ausgeben eines selbstsignierten Zertifikats für einen In-Cluster-Dienst erläutert.

Erstellen eines selbstsignierten Cluster-Issuers

Erstellen eines ClusterIssuers (selbstsignierte Zertifizierungsstelle)

Richten Sie zunächst ein ClusterIssuer ein, das ein selbstsigniertes Zertifikat als Zertifizierungsstelle verwendet. Dieser ClusterIssuer fungiert als interne Zertifizierungsstelle für den Cluster und signiert Zertifikate für Ihre Workloads. Die Zertifizierungsstelle sollte von RSA-generierten privaten Schlüsseln mit einer Mindestlänge von 4096 unterstützt werden.

In diesem Beispiel wird ein selbstsigniertes Zertifikat verwendet, um den Prozess zu veranschaulichen, der für die Kommunikation zwischen Clustern oder Tests geeignet ist, aber nicht für Produktionsworkloads empfohlen wird.

Wenden Sie das folgende YAML-Manifest an, um ein selbstsigniertes ClusterIssuer zu erstellen:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: selfsigned-cluster-ca
  spec:
    selfSigned: {}
EOF

Dadurch wird ein ClusterIssuer namens selfsigned-cluster-ca definiert, der selbstsignierte Zertifikate ausstellt (d. h. er generiert effektiv ein Stammzertifikat zur Signierung). Nachdem Sie den ClusterIssuer definiert haben, generiert der Zertifikat-Manager automatisch einen Stammschlüssel und ein Zertifikat für diesen Aussteller im Hintergrund. Es speichert das generierte Zertifizierungsstellenzertifikat und den Schlüssel in einem Secret (standardmäßig genannt selfsigned-cluster-ca-cert im selben Namespace wie cert-manager, in der Regel cert-manager)

Erstellen eines vom ClusterIssuer signierten Zertifikats

Fordern Sie nun ein Zertifikat für einen bestimmten Zweck an (z. B. Workload-Authentifizierung). Erstellen Sie eine Zertifikatressource, die ein Zertifikat für einen internen Namen wie domain my-service.mydomainlocal anfordert, das von der neuen selbstsignierten Cluster-CA signiert wird.

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: my-service-cert
    namespace: default  # or the namespace where your application resides
  spec:
    secretName: my-service-tls 
    duration: 2160h            # 90 days (default) 
    renewBefore: 360h          # renew 15 days before expiration
    commonName: my-service.mydomain.local
    dnsNames:
    - my-service.mydomain.local
    issuerRef:
      name: selfsigned-cluster-ca     
      kind: ClusterIssuer
    privateKey:
      rotationPolicy: Always       
EOF

Diese Spezifikation enthält die folgenden Felder:

• secretName: my-service-tls ist der Ort, an dem das resultierende TLS-Zertifikat und der resultierende Schlüssel gespeichert werden (als geheimer Schlüssel im selben Namespace). Anwendungen verwenden diesen geheimen Schlüssel.
• commonName und dnsNames geben die Betreffnamen für das Zertifikat an. In diesem Beispiel wird ein fiktiver Dienst-DNS-Name verwendet.
• issuerRef verweist auf den Aussteller, den Sie erstellt haben. Legen Sie kind: ClusterIssuer und name so fest, dass sie auf Ihr selbstsigniertes CA ClusterIssuer verweisen.

Innerhalb weniger Sekunden generiert der Zertifikat-Manager einen privaten Schlüssel und erstellt einen CertificateSigningRequest für den referenzierten Aussteller. Da dieser Aussteller selbstsigniert ist, fungiert der Zertifikatsmanager selbst als Signierer, indem der zuvor generierte CA-Schlüssel verwendet wird.

Verteilen des Vertrauensbundles (optional)

Wenn Sie nur selbstsignierte Zertifikate in Ihrem Cluster verwenden, möchten Sie möglicherweise, dass alle Workloads der selbstsignierten Stammzertifizierungsstelle des Clusters über Namespaces hinweg vertrauen. Trust Manager kann die Zertifizierungsstelle bei Bedarf als ConfigMap verteilen.

Erstellen Sie eine Certificate Ressource zum Speichern der selbstsignierten Zertifizierungsstelle im geheimen selfsigned-cluster-ca-cert:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: selfsigned-cluster-ca-cert
    namespace: cert-manager
  spec:
    isCA: true
    commonName: selfsigned-cluster-ca-cert
    secretName: selfsigned-cluster-ca-cert
    privateKey:
      algorithm: ECDSA
      size: 256
      rotationPolicy: Always      
    issuerRef:
      name: selfsigned-cluster-ca
      kind: ClusterIssuer
      group: cert-manager.io
EOF

Erstellen Sie eine Bundle Ressource, um den Trust-Manager zu konfigurieren und das Zertifikat der Zertifizierungsstelle zu verteilen.

cat <<EOF | kubectl apply -f -
  apiVersion: trust.cert-manager.io/v1alpha1
  kind: Bundle
  metadata:
    name: cluster-ca-bundle
    namespace: cert-manager
  spec:
    sources:
    - secret:
        name: selfsigned-cluster-ca-cert
        key: tls.crt
    target:
      configMap:
        key: ca.crt
EOF

Diese Konfiguration weist trust-manager an, die Zertifikatdaten aus dem angegebenen Secret (selfsigned-cluster-ca-cert) zu übernehmen und sie in einer ConfigMap namens cluster-ca-bundle in allen Namespaces zu veröffentlichen. Die ConfigMap enthält einen Dateneintrag ca.crt, der das CA-Zertifikat umfasst. Durch Anwenden dieses Bundles erstellt und aktualisiert der Trust-Manager die ConfigMaps entsprechend.

Alle Pods können dann die cluster-ca-bundle ConfigMap bereitstellen, um der benutzerdefinierten Zertifizierungsstelle zu vertrauen, oder auf die ConfigMap kann von anderen Erweiterungen verwiesen werden. Die Verwendung eines Vertrauensbundles ist besonders nützlich, wenn eine Unternehmenszertifizierungsstelle verwendet wird; entsprechend würden Sie diese Zertifizierungsstelle an alle Pods verteilen, die ihr vertrauen müssen.

Entfernen des Cert-Managers für Arc-fähige Kubernetes (Vorschau)

Verwenden Sie den folgenden Befehl, um den Cert-Manager für die Arc-fähige Kubernetes-Erweiterung (Vorschau) zu deinstallieren:

az k8s-extension delete \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management"

Mit diesem Befehl werden die Bereitstellungen des Zertifikat-Managers und des Vertrauens-Managers entfernt. Es werden keine geheimen Schlüssel und Configmaps für Vertrauenswürdige Bündel entfernt, aber die Controller, die sie aktualisiert halten, werden entfernt. Alle von Ihnen erstellten Zertifikate oder Aussteller bleiben erhalten, und alle Benutzer dieser Zertifikate können sie weiterhin verwenden, bis sie ablaufen. Um den Zertifikat-Manager vollständig aus dem Cluster zu entfernen, entfernen Sie die von Ihnen erstellten Zertifikat- und Ausstellerressourcen sowie alle geheimen Schlüssel, die generiert wurden.