Questo documento spiega come formattare i certificati durante la configurazione di GKE Identity Service. Queste indicazioni possono aiutarti a evitare e risolvere i problemi relativi ai certificati del provider di identità durante l'utilizzo del servizio.
Panoramica
GKE Identity Service è un servizio di autenticazione che ti consente di accedere al tuo
cluster GKE tramite provider di identità come OIDC e LDAP. Durante la creazione di una connessione TLS, GKE Identity Service 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 fornitore è 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 un certificato CA con codifica Base64 e formato PEM per il server LDAP. Includi la stringa risultante in certificateAuthorityData come riga singola. Deve essere fornito solo per le
connessioni ldaps e startTLS.
Esempio per OIDC
... oidc: certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA ...
dove CERTIFICATE_AUTHORITY_DATA contiene una stringa di certificato con codifica Base64 e formato PEM per il provider di identità. Includi la stringa risultante in certificateAuthorityData come riga singola.
Valore del certificato con codifica Base64
Definita in RFC 4864, la codifica base64 standard utilizza i caratteri da A a Z, da a a z, da 0 a 9, + e /.
I dati vengono riempiti utilizzando =.
Codifica del certificato CA per GKE Identity Service
I certificati SSL hanno formati come 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 da altri formati in file con codifica PEM utilizzando uno strumento da riga di comando openssl su qualsiasi sistema Linux o Unix.
Se sono presenti più certificati, concatenali e importali come un unico file PEM.
Esempio di formato PEM
Ecco un esempio di certificato codificato 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 del certificato iniziano con BEGIN CERTIFICATE e terminano con END CERTIFICATE.
- Il numero di trattini utilizzati nei delimitatori è fisso.
- Il valore del certificato utilizza la codifica base64 standard (RFC 4864) con interruzioni di riga (dopo 64 caratteri).
- Gli interruzioni di riga (\n) non sono visibili. Non inserire caratteri di escape per il carattere di nuova riga.
Specifica il valore del certificato in ClientConfig
Per specificare il valore del certificato in ClientConfig:
- Determina il formato con codifica PEM per il certificato CA.
- Codifica Base64 del file PEM in base allo standard RFC 4864.
Assicurati che l'output sia una singola stringa lunga senza interruzioni di riga, come nel seguente esempio di un file PEM codificato con Base64:
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K - Fornisci questo valore del certificato per il campo
certificateAuthorityDatain ClientConfig.
Certificati CA per i certificati intermedi
Un certificato intermedio svolge un ruolo di "catena di attendibilità" tra un certificato dell'entità finale e un certificato radice. Quando viene utilizzato in ClientConfig, questo valore del certificato deve essere formattato come stringa con codifica base64. Per creare una singola stringa, concatena i certificati completi con codifica PEM in una singola stringa e poi 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 è emesso da IntermediateCA, che è emesso da DeptCA, che a sua volta è emesso da RootCA.
Le catene di attendibilità parziale sono supportate da GKE Identity Service. Ciò significa che puoi fornire catene con solo alcuni dei 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 nella catena parziale all'identità presentata dal server.
Le versioni precedenti di GKE Identity Service, ad esempio le versioni precedenti a Google Distributed Cloud 1.28.200, richiedono una catena di attendibilità contigua a partire dal certificato radice per verificare il server. Esempi di catene parziali supportate dalle 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 questo è la causa del problema.
Specifica la catena di attendibilità dei certificati in ClientConfig
Per specificare la catena di attendibilità dei certificati in ClientConfig:
- Determina il formato con codifica PEM per i certificati CA che vuoi includere nella catena di certificati.
Concatena i file PEM in un unico file in modo che il certificato radice si trovi alla fine del file. Ecco come appare l'output:
-----BEGIN CERTIFICATE----- IntermediateCA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- DeptCA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- RootCA certificate -----END CERTIFICATE-----
Codifica in Base64 il file concatenato. Assicurati che il file contenga una sola riga di testo codificato in base64.
Fornisci questo valore del certificato per il campo
certificateAuthorityDatain ClientConfig.