Formattare i certificati per GKE Identity Service

Questo documento spiega come formattare i certificati durante la configurazione del servizio di identità GKE. Queste indicazioni possono aiutarti a evitare e risolvere i problemi con i certificati del provider di identità durante l'utilizzo del servizio.

Panoramica

GKE Identity Service è un servizio di autenticazione che ti consente di accedere a Cluster GKE tramite provider di identità come OIDC e LDAP. Durante la connessione TLS, il servizio di identità GKE convalida il certificato del server del provider e verifica se il issuer del certificato del provider è uno dei certificati dell'autorità di certificazione (CA) configurati.

Stringa certificateAuthorityData in ClientConfig

Il certificato CA utilizzato per verificare l'identità del provider è configurato nel campo certificateAuthorityData in ClientConfig, come mostrato negli esempi seguenti.

Esempio per LDAP

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

dove CERTIFICATE_AUTHORITY_DATA contiene una codifica Base64, Certificato CA in formato PEM per il server LDAP. Includi i risultati stringa in certificateAuthorityData come una singola riga. Deve essere fornito solo per Connessioni ldaps e startTLS.

Esempio per OIDC

...
oidc:
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
...

dove CERTIFICATE_AUTHORITY_DATA contiene una codifica Base64 e formattazione PEM stringa del certificato per il provider di identità. Includi i risultati stringa in certificateAuthorityData come una singola riga.

Valore del certificato con codifica Base64

Definita in RFC 4864, la codifica standard base64 utilizza i caratteri A per Z, a per z, 0 per 9, + e /. I dati vengono riempiti utilizzando =.

Codifica il certificato CA per il servizio di identità GKE

I certificati SSL hanno formati quali DER, PEM e PFX. I file PFX sono in genere criptati con una password.

Quando configuri GKE Identity Service con un provider di identità, i certificati non devono essere protetti da password. Questo perché non è disponibile alcun flusso di lavoro per specificare la password per la decriptazione. Per questo motivo, assicurati di convertire i certificati di altri formati in file con codifica PEM utilizzando uno strumento a riga di comando openssl su qualsiasi sistema Linux o Unix. Se esistono più certificati, concatenali e importali come un singolo file PEM.

Esempio di formato PEM

Ecco un esempio di certificato con codifica PEM:

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

Nell'esempio, tieni presente i seguenti dettagli:

  • I delimitatori dei certificati iniziano con BEGIN CERTIFICATE e terminano con END CERTIFICATE (FINE CERTIFICATO).
  • Il numero di trattini utilizzati nei delimitatori è fisso.
  • Il valore del certificato utilizza la codifica standard base64 (RFC 4864) con interruzioni di riga (dopo 64 caratteri).
  • Le interruzioni di riga (\n) non sono visibili. Non inserire la nuova riga in caratteri di escape.

Specifica il valore del certificato in ClientConfig

Per specificare il valore del certificato in ClientConfig, segui questi passaggi:

  1. Determina il formato con codifica PEM per il certificato CA.
  2. Base64 codifica il file PEM come da RFC 4864. Assicurati che l'output sia una singola stringa lunga senza interruzioni di riga, come nell'esempio seguente di un file PEM con codifica base64: 
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  3. Fornisci questo valore di certificato per il campo certificateAuthorityData in ClientConfig.

Certificati CA per certificati intermedi

Un certificato intermedio riproduce una "catena di attendibilità" ruolo tra un certificato dell'entità finale e un certificato radice. Il valore di questo certificato deve essere formattato come stringa con codifica base64 se utilizzato in ClientConfig. Per creare una singola stringa, concatena i certificati completi con codifica PEM in una singola stringa e quindi codificala in base64.

Ecco un esempio di catena di attendibilità contigua che inizia con il certificato radice.

ServerCert -> IntermediateCA -> DeptCA -> RootCA

In questo esempio, ServerCert viene emesso da IntermediateCA, che a sua volta viene emesso da DeptCA, che a sua volta viene emesso da RootCA.

Le catene di attendibilità parziali sono supportate da GKE Identity Service. Ciò significa che puoi fornire catene con solo alcuni certificati, ad esempio:

IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA

ServerCert

Quando GKE Identity Service è configurato solo con una catena parziale, verifica l'identità del server cercando di abbinare i certificati della catena parziale con l'identità presentata dal server.

Le versioni precedenti di GKE Identity Service, ad esempio prima di Google Distributed Cloud 1.28.200, richiedono una catena di attendibilità contigua che inizi dal certificato radice per verificare il server. Esempi di catene parziali supportate da versioni precedenti di GKE Identity Service:

ServerCert -> IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA -> RootCA

DeptCA -> RootCA

Se riscontri problemi di verifica dei certificati e non sai quale versione di GKE Identity Service stai utilizzando, prova ad aggiungere un certificato radice alla catena di attendibilità, se non ne hai uno, per verificare se questa è la causa del problema.

Specifica la catena di attendibilità dei certificati in ClientConfig

Per specificare la catena di attendibilità dei certificati in ClientConfig, segui questi passaggi:

  1. Determina il formato con codifica PEM per i certificati CA che vuoi includere nella catena di certificati.

  2. Concatena i file PEM in un unico file, in modo che il certificato radice si trovi alla fine del file. Ecco come si presenta l'output:

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

  3. Base64: codifica il file concatenato. Assicurati che il file contenga una singola riga di testo codificato in base64.

  4. Fornisci questo valore di certificato per il campo certificateAuthorityData in ClientConfig.