Certificados nativos da nuvem - padrões de fato para o Kubernetes

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

O que é TLS?

O TLS (Transport Layer Security) é o padrão mais comum para proteger a comunicação entre duas partes em uma rede. Ele abrange autenticação, criptografia e integridade. Seu uso mais comum é para proteger uma conexão HTTP. Você provavelmente já se deparou com ele ao visitar um site HTTPS. O S significa seguro! Ele é representado por um pequeno cadeado na barra de endereços de alguns navegadores da Web.

Se você visualizar o certificado do site, poderá ver campos como: por quem ele foi emitido e quais são as datas de início e término de validade. Em um mundo simples, o emissor é conhecido como autoridade de certificação (CA).

Uma CA é uma organização confiável cuja função é emitir certificados digitais. O sistema operacional do seu computador vem com uma lista de CAs já instaladas. No entanto, também é possível adicionar novas CAs nas quais você confia, seja porque uma CA anterior está desatualizada e precisa ser atualizada ou porque você deseja assinar algo por conta própria.

Encadeamento de certificados

Ao confiar na CA, você confia em todos os certificados que ela assinou. Na realidade, é muito perigoso colocar a CA diretamente na linha dessa forma, portanto, é mais comum que uma CA tenha assinado um certificado intermediário e delegue domínios de segurança separados aos certificados intermediários. Esse certificado intermediário também pode continuar a criar certificados assinados. Esses certificados finais tendem a ser usados pelos servidores para apresentar ao seu navegador conexões HTTPS. 

Essa assinatura consecutiva forma o que é conhecido como cadeia de certificados. Seu navegador recebe um certificado e sobe na cadeia até chegar a uma CA. Se a CA estiver na sua lista de CAs confiáveis, o handshake continua e você obtém uma conexão segura. Suponha que a CA não apareça no repositório de confiança. Nesse caso, você receberá um erro em seu navegador análogo a "autoridade de certificação inválida“. 

Para verificar a validade do certificado de um servidor, a assinatura do certificado pode ser decodificada usando a chave pública da CA (que está disponível em seu certificado) e validada. O sucesso nesse processo prova que o certificado foi de fato assinado por eles e não por um terceiro mal-intencionado.

Isso significa que qualquer pessoa com a chave privada poderia se disfarçar como a CA original, e é por isso que os certificados intermediários tendem a ser usados. Em vez de todos os certificados emitidos serem invalidados por uma AC comprometida, apenas parte da cadeia o é. 

Para solicitar um certificado assinado, o usuário final cria uma chave privada e uma solicitação de assinatura de certificado (CSR). A CSR contém a chave pública complementar da chave privada que é incorporada ao certificado assinado final. Seguindo a mesma lógica, essa chave privada prova que o servidor está usando um certificado que ele realmente possui, pois as informações são assinadas digitalmente e verificáveis usando a chave pública do certificado.

TLS, Kubernetes e CAO nativo da nuvem do Couchbase

O Kubernetes fornece um padrão para armazenar esses certificados e chaves privadas com um kubernetes.io/tls especificação. Ao estabelecer um padrão, isso significa que todos os sistemas gerarão e consumirão certificados e chaves TLS em um formato consistente, permitindo uma melhor interoperabilidade. Com a versão mais recente do CAO 2.3, recomenda-se que os usuários usem segredos em conformidade com essa especificação.

Anteriormente, no CAO 2.1, os segredos do TLS eram fornecidos com a opção pkey.key e chain.pem isso é um artefato de caminhos codificados no servidor Couchbase:

A desvantagem desse formato é que ele não oferecia uma interoperabilidade muito boa com sistemas de gerenciamento de certificados de terceiros.

Em seguida, o CAO 2.2 foi lançado com suporte para gerenciador de certificados. O suporte foi obtido com a criação de uma camada de tradução que renomeou os arquivos e também reescreveu a chave do arquivo PKCS#8 para o formato PKCS#1 exigido, se necessário, ampliando assim o suporte a TLS fornecido pelo Couchbase Server.

Os segredos do TLS fornecido por gerenciador de certificados são uma leve extensão do nativo kubernetes.io/tls espec.

Essa especificação estendida utilizou um ca.crt para fornecer o certificado de CA raiz responsável pela assinatura do respectivo certificado TLS armazenado no campo tls.crt campo.

O fornecimento de uma melhor conformidade é obtido separando os ca.crt em um segredo de CA separado. Isso proporciona integração direta com um escopo maior de sistemas de gerenciamento de TLS de terceiros, permitindo que os sistemas de gerenciamento de TLS lidem com a geração e a rotação de certificados.

Além disso, os servidores que executam o Couchbase Server 7.1 e o CAO 2.3 podem usar o spec.networking.tls.rootCAs para criar um pool de confiança. Os pools de confiança permitem que o Couchbase Server valide certificados em relação a várias CAs. O Couchbase Server pode usar uma CA e, ao mesmo tempo, validar certificados de clientes em uma quantidade arbitrária de CAs separadas. 

Isso permite que os certificados do cliente sejam atualizados aos poucos, conforme necessário, em vez de exigir uma rotação de todos os certificados do cliente simultaneamente. Como o segredo que armazena as informações da CA é do padrão TLS do Kubernetes, os segredos da CA podem ser importados diretamente pelo CAO sem a necessidade de intervenção manual.

• Ler Conceitos do CAO 2.3 na documentação do Couchbase para obter mais informações.