Zertifikate für GKE Identity Service formatieren

In diesem Dokument wird erläutert, wie Sie Zertifikate bei der Konfiguration von GKE Identity Service formatieren. 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.

String certificateAuthorityData in ClientConfig

Das Zertifikat der Zertifizierungsstelle, 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, sollten Zertifikate nicht passwortgeschützt sein. Das liegt daran, dass es keinen Workflow zur Angabe des Passworts für die Entschlüsselung gibt. Daher sollten Sie Ihre Zertifikate auf einem beliebigen Linux- oder Unix-System mit einem openssl-Befehlszeilentool von anderen Formaten in PEM-codierte Dateien konvertieren. Wenn mehrere Zertifikate vorhanden sind, verketten Sie die Zertifikate 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 die folgenden Details:

  • 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. Legen Sie das PEM-codierte Format für das CA-Zertifikat fest.
  2. Codieren Sie die PEM-Datei gemäß RFC 4864 mit base64. Die Ausgabe muss ein langer einzelner String ohne Zeilenumbrüche sein, 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 in der ClientConfig als base64-codierter String formatiert sein. Verketten Sie zum Erstellen eines einzelnen Strings die vollständigen PEM-codierten Zertifikate zu einem einzelnen String und codieren Sie diesen mit base64.

Hier ein Beispiel für eine zusammenhängende Vertrauenskette, die mit dem Stammzertifikat 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 nur mit einigen der Zertifikate bereitstellen 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 wie 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. Legen Sie das PEM-codierte Format für die CA-Zertifikate fest, 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. Achten Sie darauf, dass die Datei eine einzelne Zeile mit base64-codiertem Text enthält.

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