Formatar certificados para o GKE Identity Service

Neste documento, explicamos como formatar certificados ao configurar o GKE Identity Service. Esta orientação ajuda a evitar e resolver problemas com certificados de provedor de identidade ao usar o serviço.

Informações gerais

O GKE Identity Service é um serviço de autenticação que permite fazer login nos clusters do Anthos usando provedores de identidade, como OIDC e LDAP. Ao estabelecer uma conexão TLS, o GKE Identity Service valida o certificado do servidor do provedor e verifica se o issuer do certificado do provedor é um dos certificados de autoridade de certificação (CA) configurados.

String certificateAuthorityData no ClientConfig

O certificado de CA usado para verificar a identidade do provedor está configurado no campo certificateAuthorityData no ClientConfig, conforme mostrado nos exemplos a seguir.

Exemplo para LDAP

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

em que CERTIFICATE_AUTHORITY_DATA contém um certificado de CA em formato PEM codificado em base64 para o servidor LDAP. Inclua a string resultante em certificateAuthorityData como uma única linha. Isso precisa ser fornecido apenas para conexões ldaps e startTLS.

Exemplo para OIDC

...
oidc:
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
...

em que CERTIFICATE_AUTHORITY_DATA contém uma string de certificado em formato PEM codificado em base64 para o provedor 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 caracteres A a Z, a a z, 0 a 9, + e /. Os dados são preenchidos usando =.

Codificar o certificado de CA para o GKE Identity Service

Os certificados SSL têm formatos como DER, PEM e PFX. Os arquivos PFX geralmente são criptografados com uma senha.

Ao configurar o GKE Identity Service com um provedor de identidade, os certificados não podem ser protegidos por senha. Isso ocorre porque não há fluxo de trabalho disponível para especificar a senha para descriptografia. Por esse motivo, converta os certificados de outros formatos para arquivos com codificação PEM usando uma ferramenta de linha de comando openssl em qualquer sistema Linux ou Unix. Se houver vários certificados, concatene os certificados e importe-os como um único arquivo PEM.

Exemplo de formato PEM

Veja um exemplo de um certificado codificado em 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-----

Observe os seguintes detalhes no exemplo:

  • Os delimitadores do certificado começam com BEGIN CERTIFICATE e terminam com END CERTIFICATE.
  • O número de hifens usados nos delimitadores é fixo.
  • O valor do certificado usa a codificação base64 padrão (RFC 4864) com quebras de linha (após 64 caracteres).
  • As quebras de linha (\n) não são visíveis. Não faça escape no caractere 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 codificado por PEM (link em inglês) do certificado de CA.
  2. Base64 codifica o arquivo PEM de acordo com o RFC 4864. A saída precisa ser uma string única longa sem quebras de linha, como no exemplo a seguir de um arquivo PEM codificado em base64: 
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNNekNDQVp5Z0F3SUJBZ0lKQUxpUG5Wc3ZxOGRzTUEwR0NTcUdTSWIzRFFFQkJRVUFNRk14Q3pBSkJnTlYKQkFZVEFsVlRNUXd3Q2dZRFZRUUlFd05tYjI4eEREQUtCZ05WQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dgpNUXd3Q2dZRFZRUUxFd05tYjI4eEREQUtCZ05WQkFNVEEyWnZiekFlRncweE16QXpNVGt4TlRRd01UbGFGdzB4Ck9EQXpNVGd4TlRRd01UbGFNRk14Q3pBSkJnTlZCQVlUQWxWVE1Rd3dDZ1lEVlFRSUV3Tm1iMjh4RERBS0JnTlYKQkFjVEEyWnZiekVNTUFvR0ExVUVDaE1EWm05dk1Rd3dDZ1lEVlFRTEV3Tm1iMjh4RERBS0JnTlZCQU1UQTJadgpiekNCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBemRHZnhpOUNOYk1mMVVVY3ZEUWg3TVlCCk92ZUlIeWMwRTBLSWJoaks1RmtDQlU0Q2lacmJmSGFnYVc3WkVjTjB0dDNFdnBiT014eGMvWlFVMldOL3Mvd1AKeHBoMHBTZnNmRnNUS000UmhUV0QydjRmZ2sreFppS2QxcDArTDRoVHRwd25FdzB1WFJWZDBraTZtdXdWNXkvUAorNUZIVWVsZHErcGdUY2d6dUs4Q0F3RUFBYU1QTUEwd0N3WURWUjBQQkFRREFnTGtNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNEdCQUppREFBdFkwbVFRZXV4V2R6TFJ6WG1qdmRTdUw5R295VDNCRi9qU25weHo1LzU4ZGJhOHBXZW4KdjNwajRQM3c1RG9Pc28wcnprWnkyakVzRWl0bFZNMm1MU2JRcE1NK01VVlFDUW9pRzZXOXh1Q0Z1eFNyd1BJUwpwQXFFQXVWNEROb3hRS0tXbWhWditKMHB0TVdEMjVQbnB4ZXE1c1h6Z2hmSm5zbEpsUU5ECi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  3. Forneça o valor desse certificado no campo certificateAuthorityData em ClientConfig.

Certificados de CA para certificados intermediários

Um certificado intermediário desempenha um papel de "cadeia de confiança" entre um certificado de entidade final e um certificado raiz. Esse valor de certificado precisa ser formatado como uma string codificada em base64 quando usado em ClientConfig. Para criar uma única string, concatene os certificados completos codificados em PEM em uma única string e, em seguida, codifique-os em base64.

Confira um exemplo de cadeia de confiança contígua começando com o certificado raiz.

ServerCert -> IntermediateCA -> DeptCA -> RootCA

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

As cadeias de confiança parciais são compatíveis com o serviço de identidade do GKE. Isso significa que você pode fornecer a cadeias apenas com alguns dos certificados, como:

IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA

ServerCert

Quando o serviço de identidade do GKE é configurado apenas com uma cadeia parcial, ele verifica a identidade do servidor tentando corresponder os certificados na cadeia parcial com a identidade apresentada pelo servidor.

Versões anteriores do serviço de identidade do GKE, como versões anteriores ao GKE no VMware e ao GKE em Bare Metal 1.28.200, exigem uma cadeia de confiança contígua começando pelo certificado raiz para verificar o servidor. Exemplos de cadeias parciais compatíveis com versões anteriores do serviço de identidade do GKE:

ServerCert -> IntermediateCA -> DeptCA -> RootCA

IntermediateCA -> DeptCA -> RootCA

DeptCA -> RootCA

Se você encontrar problemas de verificação de certificado e não souber qual versão do serviço de identidade do GKE está usando, tente adicionar um certificado raiz à sua cadeia de confiança, se não tiver um, para ver se essa é a causa do problema.

Especificar a cadeia de confiança de certificados em ClientConfig

Para especificar a cadeia de confiança de certificados em ClientConfig, faça o seguinte:

  1. Determine o formato codificado por PEM dos certificados de CA que você quer incluir na cadeia de certificados.

  2. Concatene os arquivos PEM em um único arquivo de modo que o certificado raiz fique no fim do arquivo Veja como é a saída:

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

  3. Codifique o arquivo concatenado em Base64. Verifique se o arquivo contém uma única linha de texto codificado em base64.

  4. Forneça o valor desse certificado no campo certificateAuthorityData em ClientConfig.