En este documento se explica cómo dar formato a los certificados al configurar Identity Service para GKE. Estas directrices pueden ayudarte a evitar y solucionar problemas con los certificados de proveedores de identidades al usar el servicio.
Información general
GKE Identity Service es un servicio de autenticación que te permite iniciar sesión en tu clúster de GKE a través de proveedores de identidades como OIDC y LDAP. Al establecer una conexión TLS, GKE Identity Service valida el certificado de servidor del proveedor y verifica si el issuer del certificado del proveedor es uno de los certificados de autoridad de certificación (CA) configurados.
Cadena certificateAuthorityData en ClientConfig
El certificado de AC que se usa para verificar la identidad del proveedor se configura en el campo certificateAuthorityData de ClientConfig, tal como se muestra en los siguientes ejemplos.
Ejemplo de LDAP
... ldap: host: HOST_NAME certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA connectionType: CONNECTION_TYPE ...
donde CERTIFICATE_AUTHORITY_DATA contiene un certificado de CA codificado en base64 y con formato PEM para el servidor LDAP. Incluye la cadena resultante en certificateAuthorityData como una sola línea. Solo se debe proporcionar para las conexiones ldaps y startTLS.
Ejemplo de OIDC
... oidc: certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA ...
donde CERTIFICATE_AUTHORITY_DATA contiene una cadena de certificado con formato PEM codificada en base64 para el proveedor de identidades. Incluye la cadena resultante en certificateAuthorityData como una sola línea.
Valor del certificado codificado en Base64
La codificación base64 estándar, definida en RFC 4864, usa los caracteres A a Z, a a z, 0 a 9, + y /.
Los datos se rellenan con =.
Codificar el certificado de CA para el servicio de identidad de GKE
Los certificados SSL tienen formatos como DER, PEM y PFX. Los archivos PFX suelen cifrarse con una contraseña.
Cuando configures GKE Identity Service con un proveedor de identidades, los certificados no deben estar protegidos con contraseña. Esto se debe a que no hay ningún flujo de trabajo disponible para especificar la contraseña de descifrado. Por este motivo, asegúrate de convertir tus certificados de otros formatos a archivos codificados en PEM mediante una openssl herramienta de línea de comandos en cualquier sistema Linux o Unix.
Si hay varios certificados, concaténalos e impórtalos como un solo archivo PEM.
Ejemplo de formato PEM
Este es un ejemplo de un certificado codificado en 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-----
En el ejemplo, ten en cuenta los siguientes detalles:
- Los delimitadores del certificado empiezan por BEGIN CERTIFICATE (Inicio del certificado) y terminan en END CERTIFICATE (Final del certificado).
- El número de guiones que se usan en los delimitadores es fijo.
- El valor del certificado usa la codificación base64 estándar (RFC 4864) con saltos de línea (después de 64 caracteres).
- Los saltos de línea (\n) no se ven. No apliques caracteres de escape al carácter de nueva línea.
Especifica el valor del certificado en ClientConfig
Para especificar el valor del certificado en ClientConfig, siga estos pasos:
- Determina el formato codificado en PEM del certificado de la CA.
- Codifica el archivo PEM en Base64 según RFC 4864.
Asegúrate de que la salida sea una cadena larga sin saltos de línea, como en el siguiente ejemplo de un archivo PEM codificado en base64:
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K - Proporcione este valor de certificado en el campo
certificateAuthorityDatade ClientConfig.
Certificados de AC para certificados intermedios
Un certificado intermedio desempeña el papel de "cadena de confianza" entre un certificado de entidad final y un certificado raíz. Este valor de certificado debe tener el formato de una cadena codificada en Base64 cuando se utilice en ClientConfig. Para crear una sola cadena, concatena los certificados completos codificados en PEM en una sola cadena y, a continuación, codifícala en base64.
Aquí tienes un ejemplo de una cadena de confianza contigua que empieza con el certificado raíz.
ServerCert -> IntermediateCA -> DeptCA -> RootCA
En este ejemplo, ServerCert se emite por IntermediateCA, que se emite por DeptCA, que a su vez se emite por RootCA.
Identity Service for GKE admite cadenas de confianza parciales. Esto significa que puede proporcionar cadenas con solo algunos de los certificados, como los siguientes:
IntermediateCA -> DeptCA -> RootCA
IntermediateCA -> DeptCA
ServerCert
Si GKE Identity Service solo se configura con una cadena parcial, verificará la identidad del servidor intentando hacer coincidir los certificados de la cadena parcial con la identidad presentada por el servidor.
Las versiones anteriores de GKE Identity Service, como las anteriores a Google Distributed Cloud 1.28.200, requieren una cadena de confianza contigua que empiece por el certificado raíz para verificar el servidor. Ejemplos de cadenas parciales admitidas por versiones anteriores de Identity Service para GKE:
ServerCert -> IntermediateCA -> DeptCA -> RootCA
IntermediateCA -> DeptCA -> RootCA
DeptCA -> RootCA
Si tienes problemas con la verificación de certificados y no sabes qué versión de GKE Identity Service estás usando, prueba a añadir un certificado raíz a tu cadena de confianza si no tienes ninguno para ver si es la causa del problema.
Especificar la cadena de confianza del certificado en ClientConfig
Para especificar la cadena de confianza del certificado en ClientConfig, haz lo siguiente:
- Determina el formato codificado en PEM de los certificados de la AC que quieras incluir en la cadena de certificados.
Concatena los archivos PEM en un único archivo de forma que el certificado raíz esté al final del archivo. Este es el aspecto del resultado:
-----BEGIN CERTIFICATE----- IntermediateCA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- DeptCA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- RootCA certificate -----END CERTIFICATE-----
Codifica en Base64 el archivo concatenado. Asegúrate de que el archivo contenga una sola línea de texto codificado en Base64.
Proporcione este valor de certificado en el campo
certificateAuthorityDatade ClientConfig.