{"id":13232,"date":"2022-05-18T11:32:28","date_gmt":"2022-05-18T18:32:28","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=13232"},"modified":"2025-06-13T23:06:11","modified_gmt":"2025-06-14T06:06:11","slug":"cloud-native-certificates-standard-kubernetes","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/cloud-native-certificates-standard-kubernetes\/","title":{"rendered":"Certificados nativos da nuvem - padr\u00f5es de fato para o Kubernetes"},"content":{"rendered":"

O Couchbase usa o TLS para garantir que a comunica\u00e7\u00e3o na rede seja segura, impedindo que terceiros mal-intencionados espionem ou adulterem solicita\u00e7\u00f5es, por exemplo, solicita\u00e7\u00f5es de clientes, solicita\u00e7\u00f5es entre clusters (criptografia n\u00f3 a n\u00f3) e solicita\u00e7\u00f5es dentro do cluster (replica\u00e7\u00e3o entre data centers - XDCR). A vers\u00e3o mais recente do Couchbase Autonomous Operator (CAO) 2.3, nativo da nuvem, oferece suporte de primeira classe para o sistema de fato <\/span>kubernetes.io\/tls<\/span><\/i> tipo de segredo para armazenar certificados e a chave associada.<\/span><\/p>\n

O que \u00e9 TLS?<\/span><\/h2>\n

O TLS (Transport Layer Security) \u00e9 o padr\u00e3o mais comum para proteger a comunica\u00e7\u00e3o entre duas partes em uma rede. Ele abrange autentica\u00e7\u00e3o, criptografia e integridade. Seu uso mais comum \u00e9 para proteger uma conex\u00e3o HTTP. Voc\u00ea provavelmente j\u00e1 se deparou com ele ao visitar um site HTTPS. O <\/span>S <\/span><\/i>significa seguro! Ele \u00e9 representado por um pequeno cadeado na barra de endere\u00e7os de alguns navegadores da Web.<\/span><\/p>\n

Se voc\u00ea visualizar o certificado do site, poder\u00e1 ver campos como: por quem ele foi emitido e quais s\u00e3o as datas de in\u00edcio e t\u00e9rmino de validade. Em um mundo simples, o emissor \u00e9 conhecido como autoridade de certifica\u00e7\u00e3o (CA).<\/span><\/p>\n

Uma CA \u00e9 uma organiza\u00e7\u00e3o confi\u00e1vel cuja fun\u00e7\u00e3o \u00e9 emitir certificados digitais. O sistema operacional do seu computador vem com uma lista de CAs j\u00e1 instaladas. No entanto, tamb\u00e9m \u00e9 poss\u00edvel adicionar novas CAs nas quais voc\u00ea confia, seja porque uma CA anterior est\u00e1 desatualizada e precisa ser atualizada ou porque voc\u00ea deseja assinar algo por conta pr\u00f3pria.<\/span><\/p>\n

Encadeamento de certificados<\/h3>\n

Ao confiar na CA, voc\u00ea confia em todos os certificados que ela assinou. Na realidade, \u00e9 muito perigoso colocar a CA diretamente na linha dessa forma, portanto, \u00e9 mais comum que uma CA tenha assinado um certificado intermedi\u00e1rio e delegue dom\u00ednios de seguran\u00e7a separados aos certificados intermedi\u00e1rios. Esse certificado intermedi\u00e1rio tamb\u00e9m pode continuar a criar certificados assinados. Esses certificados finais tendem a ser usados pelos servidores para apresentar ao seu navegador conex\u00f5es HTTPS.\u00a0<\/span><\/p>\n

Essa assinatura consecutiva forma o que \u00e9 conhecido como <\/span>cadeia de certificados<\/span><\/i>. Seu navegador recebe um certificado e sobe na cadeia at\u00e9 chegar a uma CA. Se a CA estiver na sua lista de CAs confi\u00e1veis, o handshake continua e voc\u00ea obt\u00e9m uma conex\u00e3o segura. Suponha que a CA n\u00e3o apare\u00e7a no reposit\u00f3rio de confian\u00e7a. Nesse caso, voc\u00ea receber\u00e1 um erro em seu navegador an\u00e1logo a \"<\/span>autoridade de certifica\u00e7\u00e3o inv\u00e1lida<\/span><\/i>“.\u00a0<\/span><\/p>\n

Para verificar a validade do certificado de um servidor, a assinatura do certificado pode ser decodificada usando a chave p\u00fablica da CA (que est\u00e1 dispon\u00edvel em seu certificado) e validada. O sucesso nesse processo prova que o certificado foi de fato assinado por eles e n\u00e3o por um terceiro mal-intencionado.<\/span><\/p>\n

Isso significa que qualquer pessoa com a chave privada poderia se disfar\u00e7ar como a CA original, e \u00e9 por isso que os certificados intermedi\u00e1rios tendem a ser usados. Em vez de todos os certificados emitidos serem invalidados por uma AC comprometida, apenas parte da cadeia o \u00e9.\u00a0<\/span><\/p>\n

Para solicitar um certificado assinado, o usu\u00e1rio final cria uma chave privada e uma solicita\u00e7\u00e3o de assinatura de certificado (CSR). A CSR cont\u00e9m a chave p\u00fablica complementar da chave privada que \u00e9 incorporada ao certificado assinado final. Seguindo a mesma l\u00f3gica, essa chave privada prova que o servidor est\u00e1 usando um certificado que ele realmente possui, pois as informa\u00e7\u00f5es s\u00e3o assinadas digitalmente e verific\u00e1veis usando a chave p\u00fablica do certificado.<\/span><\/p>\n

TLS, Kubernetes e CAO nativo da nuvem do Couchbase<\/span><\/h2>\n

O Kubernetes fornece um padr\u00e3o para armazenar esses certificados e chaves privadas com um <\/span>kubernetes.io\/tls<\/span><\/i> especifica\u00e7\u00e3o. Ao estabelecer um padr\u00e3o, isso significa que todos os sistemas gerar\u00e3o e consumir\u00e3o certificados e chaves TLS em um formato consistente, permitindo uma melhor interoperabilidade. Com a vers\u00e3o mais recente do CAO 2.3, recomenda-se que os usu\u00e1rios usem segredos em conformidade com essa especifica\u00e7\u00e3o.<\/span><\/p>\n

Anteriormente, no CAO 2.1, os segredos do TLS eram fornecidos com a op\u00e7\u00e3o <\/span>pkey.key<\/span><\/i> e <\/span>chain.pem <\/span><\/i>isso \u00e9 um artefato de caminhos codificados no servidor Couchbase:<\/span><\/p>\n

apiVersion: v1\r\ndados:\r\n  chain.pem: LS0tL...\r\n  pkey.key: LS0tL...\r\ntipo: Secreto\r\ntype: Opaque<\/pre>\n
A desvantagem desse formato \u00e9 que ele n\u00e3o oferecia uma interoperabilidade muito boa com sistemas de gerenciamento de certificados de terceiros.<\/span><\/p>\n
Em seguida, o CAO 2.2 foi lan\u00e7ado com suporte para <\/span>gerenciador de certificados<\/span><\/i>. <\/span>O suporte foi obtido com a cria\u00e7\u00e3o de uma camada de tradu\u00e7\u00e3o que renomeou os arquivos e tamb\u00e9m reescreveu a chave do arquivo <\/span>PKCS#8<\/span><\/i> para o formato PKCS#1 exigido, se necess\u00e1rio, ampliando assim o suporte a TLS fornecido pelo Couchbase Server.<\/span><\/p>\n
Os segredos do TLS <\/span>fornecido por gerenciador de certificados<\/em> s\u00e3o uma leve extens\u00e3o do nativo <\/span>kubernetes.io\/tls<\/span><\/i> espec.<\/span><\/p>\n
\"TLS<\/p>\n
Essa especifica\u00e7\u00e3o estendida utilizou um <\/span>ca.crt<\/span><\/i> para fornecer o certificado de CA raiz respons\u00e1vel pela assinatura do respectivo certificado TLS armazenado no campo <\/span>tls.crt<\/span><\/i> campo.<\/span><\/p>\n
\"Cloud-native<\/p>\n
O fornecimento de uma melhor conformidade \u00e9 obtido separando os <\/span>ca.crt<\/span><\/i> em um segredo de CA separado. Isso proporciona integra\u00e7\u00e3o direta com um escopo maior de<\/span> sistemas de gerenciamento de TLS de terceiros, permitindo que os sistemas de gerenciamento de TLS lidem com a gera\u00e7\u00e3o e a rota\u00e7\u00e3o de certificados.<\/span><\/p>\n
Al\u00e9m disso, os servidores que executam o Couchbase Server 7.1 e o CAO 2.3 podem usar o <\/span>spec.networking.tls.rootCAs<\/span><\/i> para criar um pool de confian\u00e7a. Os pools de confian\u00e7a permitem que o Couchbase Server valide certificados em rela\u00e7\u00e3o a v\u00e1rias CAs. O Couchbase Server pode usar uma CA e, ao mesmo tempo, validar certificados de clientes em uma quantidade arbitr\u00e1ria de CAs separadas.\u00a0<\/span><\/p>\n
Isso permite que os certificados do cliente sejam atualizados aos poucos, conforme necess\u00e1rio, em vez de exigir uma rota\u00e7\u00e3o de todos os certificados do cliente simultaneamente. Como o segredo que armazena as informa\u00e7\u00f5es da CA \u00e9 do padr\u00e3o TLS do Kubernetes, os segredos da CA podem ser importados diretamente pelo CAO sem a necessidade de interven\u00e7\u00e3o manual.<\/span><\/p>\n