Zertifikate für GKE Identity Service formatieren

In diesem Dokument wird erläutert, wie Sie Zertifikate formatieren, wenn Sie GKE Identity Service konfigurieren. Diese Anleitung soll Ihnen dabei helfen, Probleme mit Identitätsanbieterzertifikaten bei der Verwendung des Dienstes zu vermeiden und zu beheben.

Übersicht

GKE Identity Service ist ein Authentifizierungsdienst, mit dem Sie sich über Identitätsanbieter wie OIDC und LDAP in Ihrem GKE-Cluster anmelden können. Beim Herstellen einer TLS-Verbindung validiert GKE Identity Service das Serverzertifikat des Anbieters und prüft, ob der issuer des Zertifikats des Anbieters eines der konfigurierten CA-Zertifikate ist.

certificateAuthorityData-String in ClientConfig

Das Zertifizierungsstellenzertifikat, mit dem die Identität des Anbieters überprüft wird, wird im Feld certificateAuthorityData in der ClientConfig konfiguriert, wie in den folgenden Beispielen gezeigt.

Beispiel für LDAP

...
ldap:
  host: HOST_NAME
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  connectionType: CONNECTION_TYPE
...

Dabei enthält CERTIFICATE_AUTHORITY_DATA ein base64-codiertes, PEM-formatiertes CA-Zertifikat für den LDAP-Server. Fügen Sie den resultierenden String in certificateAuthorityData als eine einzelne Zeile ein. Dies muss nur für ldaps- und startTLS-Verbindungen angegeben werden.

Beispiel für OIDC

...
oidc:
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
...

Dabei enthält CERTIFICATE_AUTHORITY_DATA einen base64-codierten, PEM-formatierten Zertifikatstring für den Identitätsanbieter. Fügen Sie den resultierenden String in certificateAuthorityData als eine einzelne Zeile ein.

Base64-codierter Zertifikatwert

In RFC 4864 definiert, verwendet die Standard-Base64-Codierung die Zeichen A bis Z, a zu z, 0 bis 9, + und /. Die Daten werden mit = aufgefüllt.

CA-Zertifikat für GKE Identity Service codieren

SSL-Zertifikate haben Formate wie DER, PEM und PFX. PFX-Dateien sind in der Regel mit einem Passwort verschlüsselt.

Wenn Sie GKE Identity Service mit einem Identitätsanbieter konfigurieren, dürfen Zertifikate nicht passwortgeschützt sein. Das liegt daran, dass kein Workflow zum Angeben des Passworts für die Entschlüsselung verfügbar ist. Konvertieren Sie Ihre Zertifikate daher mit einem openssl-Befehlszeilentool auf einem beliebigen Linux- oder Unix-System von anderen Formaten in PEM-codierte Dateien. Wenn mehrere Zertifikate vorhanden sind, verketten Sie sie und importieren Sie sie als einzelne PEM-Datei.

Beispiel für das PEM-Format

Hier ein Beispiel für ein PEM-codiertes Zertifikat:

-----BEGIN CERTIFICATE-----
MIICMzCCAZygAwIBAgIJALiPnVsvq8dsMA0GCSqGSIb3DQEBBQUAMFMxCzAJBgNV
BAYTAlVTMQwwCgYDVQQIEwNmb28xDDAKBgNVBAcTA2ZvbzEMMAoGA1UEChMDZm9v
MQwwCgYDVQQLEwNmb28xDDAKBgNVBAMTA2ZvbzAeFw0xMzAzMTkxNTQwMTlaFw0x
ODAzMTgxNTQwMTlaMFMxCzAJBgNVBAYTAlVTMQwwCgYDVQQIEwNmb28xDDAKBgNV
BAcTA2ZvbzEMMAoGA1UEChMDZm9vMQwwCgYDVQQLEwNmb28xDDAKBgNVBAMTA2Zv
bzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzdGfxi9CNbMf1UUcvDQh7MYB
OveIHyc0E0KIbhjK5FkCBU4CiZrbfHagaW7ZEcN0tt3EvpbOMxxc/ZQU2WN/s/wP
xph0pSfsfFsTKM4RhTWD2v4fgk+xZiKd1p0+L4hTtpwnEw0uXRVd0ki6muwV5y/P
+5FHUeldq+pgTcgzuK8CAwEAAaMPMA0wCwYDVR0PBAQDAgLkMA0GCSqGSIb3DQEB
BQUAA4GBAJiDAAtY0mQQeuxWdzLRzXmjvdSuL9GoyT3BF/jSnpxz5/58dba8pWen
v3pj4P3w5DoOso0rzkZy2jEsEitlVM2mLSbQpMM+MUVQCQoiG6W9xuCFuxSrwPIS
pAqEAuV4DNoxQKKWmhVv+J0ptMWD25Pnpxeq5sXzghfJnslJlQND
-----END CERTIFICATE-----

Beachten Sie im Beispiel Folgendes:

  • Die Zertifikatstrennzeichen beginnen mit BEGIN CERTIFICATE und enden mit END CERTIFICATE.
  • Die Anzahl der Bindestriche in den Trennzeichen ist festgelegt.
  • Der Zertifikatswert verwendet die Standard-Base64-Codierung (RFC 4864) mit Zeilenumbrüchen (nach 64 Zeichen).
  • Die Zeilenumbrüche (\n) sind nicht sichtbar. Verwenden Sie kein Maskierungszeichen für den Zeilenumbruch.

Zertifikatwert in ClientConfig angeben

So geben Sie den Zertifikatwert in Ihrer ClientConfig an:

  1. Ermitteln Sie das PEM-codierte Format für das CA-Zertifikat.
  2. Codieren Sie die PEM-Datei gemäß RFC 4864 mit base64. Achten Sie darauf, dass die Ausgabe ein langer einzelner String ohne Zeilenumbrüche ist, wie im folgenden Beispiel einer base64-codierten PEM-Datei: 
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  3. Geben Sie diesen Zertifikatwert für das Feld certificateAuthorityData in der ClientConfig an.

CA-Zertifikate für Zwischenzertifikate

Ein Zwischenzertifikat spielt eine Rolle in der "Vertrauenskette" zwischen einem Endentitätszertifikat und einem Root-Zertifikat. Dieser Zertifikatwert sollte als Base64-codierter String formatiert werden, wenn er in der ClientConfig verwendet wird. Um einen einzelnen String zu erstellen, verketten Sie die vollständigen PEM-codierten Zertifikate zu einem einzelnen String und codieren Sie ihn dann in Base64.

Hier ist ein Beispiel für eine zusammenhängende Vertrauenskette, die mit dem Root-Zertifikat beginnt.

ServerCert -> IntermediateCA -> DeptCA -> RootCA

In diesem Beispiel wird ServerCert von IntermediateCA ausgestellt, das von DeptCA ausgestellt wird, welches wiederum von RootCA ausgestellt wird.

Teilweise Vertrauensketten werden von GKE Identity Service unterstützt. Das bedeutet, dass Sie Ketten mit nur einigen der Zertifikate angeben können, z. B.:

IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA

ServerCert

Wenn GKE Identity Service nur mit einer teilweisen Kette konfiguriert ist, wird es die Identität des Servers überprüfen, indem es versucht, die Zertifikate in der teilweisen Kette mit der vom Server bereitgestellten Identität abzugleichen.

Frühere Versionen von GKE Identity Service, z. B. Versionen vor Google Distributed Cloud 1.28.200, erfordern eine zusammenhängende Vertrauenskette, die ab dem Root-Zertifikat beginnt, um den Server zu verifizieren. Beispiele für teilweise Ketten, die von früheren Versionen von GKE Identity Service unterstützt werden:

ServerCert -> IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA -> RootCA

DeptCA -> RootCA

Wenn Sie Probleme bei der Zertifikatsüberprüfung haben und nicht wissen, welche Version von GKE Identity Service Sie verwenden, versuchen Sie, ein Root-Zertifikat in Ihre Vertrauenskette aufzunehmen, falls Sie noch keines haben, um zu sehen, ob dies die Ursache des Problems ist.

Zertifikats-Vertrauenskette in ClientConfig angeben

So geben Sie die Zertifikats-Vertrauenskette in Ihrer ClientConfig an:

  1. Bestimmen Sie das PEM-codierte Format für die CA-Zertifikate, die Sie in die Zertifikatskette aufnehmen möchten.

  2. Verketten Sie die PEM-Dateien zu einer einzelnen Datei, sodass sich das Root-Zertifikat am Ende der Datei befindet. Die Ausgabe sieht so aus:

    -----BEGIN CERTIFICATE-----
IntermediateCA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
DeptCA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
RootCA certificate
-----END CERTIFICATE-----

  3. Codieren Sie die verkettete Datei mit base64. Die Datei muss eine einzelne Zeile mit base64-codiertem Text enthalten.

  4. Geben Sie diesen Zertifikatwert für das Feld certificateAuthorityData in der ClientConfig an.