Formate certificados para o Serviço de identidade do GKE

Este documento explica como formatar certificados ao configurar o serviço de identidade do GKE. Estas orientações podem ajudar a evitar e resolver problemas com certificados de fornecedores de identidade quando usar o serviço.

Vista geral

O GKE Identity Service é um serviço de autenticação que lhe permite iniciar sessão no seu cluster do GKE através de fornecedores de identidade, como o OIDC e o LDAP. Ao estabelecer uma ligação TLS, o GKE Identity Service valida o certificado do servidor do fornecedor e verifica se o issuer do certificado do fornecedor é um dos certificados da autoridade de certificação (AC) configurados.

certificateAuthorityData string em ClientConfig

O certificado de AC usado para validar a identidade do fornecedor está configurado no campo certificateAuthorityData no ClientConfig, conforme mostrado nos exemplos seguintes.

Exemplo para LDAP

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

onde CERTIFICATE_AUTHORITY_DATA contém um certificado da CA codificado em base64 no formato PEM para o servidor LDAP. Inclua a string resultante em certificateAuthorityData como uma única linha. Tem de ser fornecido apenas para ligações ldaps e startTLS.

Exemplo para OIDC

...
oidc:
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
...

onde CERTIFICATE_AUTHORITY_DATA contém uma string de certificado codificada em base64 e formatada em PEM para o fornecedor de identidade. Inclua a string resultante em certificateAuthorityData como uma única linha.

Valor do certificado codificado em Base64

Definida na RFC 4864, a codificação base64 padrão usa os carateres A a Z, a a z, 0 a 9, + e /. Os dados são preenchidos com =.

Codifique o certificado da AC para o serviço de identidade do GKE

Os certificados SSL têm formatos como DER, PEM e PFX. Normalmente, os ficheiros PFX são encriptados com uma palavra-passe.

Quando configura o GKE Identity Service com um fornecedor de identidade, os certificados não devem estar protegidos por palavra-passe. Isto deve-se ao facto de não existir um fluxo de trabalho disponível para especificar a palavra-passe para desencriptação. Por este motivo, certifique-se de que converte os seus certificados de outros formatos em ficheiros codificados PEM através de uma opensslferramenta de linha de comandos em qualquer sistema Linux ou Unix. Se existirem vários certificados, concatene-os e importe-os como um único ficheiro PEM.

Exemplo de formato PEM

Segue-se um exemplo de um certificado codificado 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-----

Tenha em atenção os seguintes detalhes no exemplo:

  • Os delimitadores do certificado começam com BEGIN CERTIFICATE e terminam com END CERTIFICATE.
  • O número de hífens usados nos delimitadores é fixo.
  • O valor do certificado usa a codificação base64 padrão (RFC 4864) com quebras de linha (após 64 carateres).
  • As quebras de linha (\n) não são visíveis. Não escape ao carácter de nova linha.

Especifique o valor do certificado em ClientConfig

Para especificar o valor do certificado no ClientConfig, faça o seguinte:

  1. Determine o formato com codificação PEM para o certificado da CA.
  2. Codifique o ficheiro PEM em Base64 de acordo com a norma RFC 4864. Certifique-se de que a saída é uma string única longa sem quebras de linha, como no exemplo seguinte de um ficheiro PEM codificado em base64: 
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  3. Indique este valor do certificado para o campo certificateAuthorityData no ClientConfig.

Certificados da AC para certificados intermédios

Um certificado intermédio desempenha um papel de "cadeia de confiança" entre um certificado de entidade final e um certificado de raiz. Este valor do certificado deve ser formatado como uma string codificada em Base64 quando usado no ClientConfig. Para criar uma única string, concatene os certificados codificados em PEM completos numa única string e, em seguida, codifique-a em Base64.

Segue-se um exemplo de uma cadeia de confiança contígua que começa com o certificado de raiz.

ServerCert -> IntermediateCA -> DeptCA -> RootCA

Neste exemplo, ServerCert é emitido por IntermediateCA, que é emitido por DeptCA, que, por sua vez, é emitido por RootCA.

As cadeias de confiança parciais são suportadas pelo GKE Identity Service. Isto significa que pode fornecer cadeias com apenas alguns dos certificados, como:

IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA

ServerCert

Quando o GKE Identity Service só está configurado com uma cadeia parcial, valida a identidade do servidor tentando fazer corresponder os certificados na cadeia parcial à identidade apresentada pelo servidor.

As versões anteriores do GKE Identity Service, como as versões anteriores ao Google Distributed Cloud 1.28.200, requerem uma cadeia de confiança contígua a partir do certificado de raiz para validar o servidor. Exemplos de cadeias parciais suportadas por versões anteriores do GKE Identity Service:

ServerCert -> IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA -> RootCA

DeptCA -> RootCA

Se estiver a ter problemas de validação de certificados e não souber que versão do GKE Identity Service está a usar, experimente adicionar um certificado de raiz à sua cadeia de confiança, se não tiver um, para ver se é a causa do problema.

Especifique a cadeia de confiança de certificados em ClientConfig

Para especificar a cadeia de confiança do certificado no ClientConfig, faça o seguinte:

  1. Determine o formato codificado em PEM para os certificados da AC que quer incluir na cadeia de certificados.

  2. Concatene os ficheiros PEM num único ficheiro de modo que o certificado de raiz esteja no fim do ficheiro. Veja o aspeto do resultado:

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

  3. Codifique em Base64 o ficheiro concatenado. Certifique-se de que o ficheiro contém uma única linha de texto codificado em base64.

  4. Indique este valor do certificado para o campo certificateAuthorityData no ClientConfig.