Operador autônomo 1.2.0 Conectividade pública

Em minha Artigo anterior Discuti, em um nível elevado, o novo recurso de conectividade pública no Autonomous Operator 1.2.0. Essa foi intencionalmente uma visão geral abstrata para convencer o usuário a aprender sobre as alegrias do DDNS, do TLS e da rede de camada 3.

Dê um peixe a um homem e você o alimentará por um dia. Ensine um homem a pescar e você o alimentará por toda a vida

Esperamos que todos vocês tenham investido tempo para aprender a pescar! (Este artigo fornece um tutorial prático sobre a configuração do Operator para que seja possível expor seus clusters do Couchbase com segurança na Internet pública.

Por que usar esse recurso?

As startups de tecnologia de hoje são mais focadas na nuvem do que as empresas tradicionais. Alguns argumentariam que a empresa tradicional está entrincheirada - protegendo os dados atrás de firewalls em data centers privados - e, sem dúvida, do ponto de vista da segurança, essa é a coisa certa a fazer.

O aumento da exposição à nuvem, embora seja um risco maior, também está se tornando menos preocupante com o passar do tempo. O mais importante é que a nuvem abre inúmeras portas para ganhos de agilidade e inovação. Conectar ofertas de serviços públicos por meio da Internet pública é um benefício enorme, que não pode ser obtido de forma fácil e econômica com serviços que ficam no local, escondidos atrás dos limites do NAT.

Um exemplo que me agrada bastante é o surgimento da função como serviço (FaaS). As funções são trabalhos de curta duração (geralmente baseados em contêineres) que respondem a estímulos e retornam um resultado. Elas são criadas sob demanda e automaticamente escalonadas de forma horizontal e instantânea para lidar com a carga de trabalho necessária. Você pode usar ofertas públicas de serviços FaaS hoje, sem perder tempo com a instalação e a configuração de infraestrutura virtual ou física. O AWS Lambda é uma dessas encarnações com a qual você talvez esteja familiarizado.

A menos que sua função seja pura (no sentido de que apenas processa dados), ela exigirá entradas, geralmente na forma de um banco de dados. Essas ofertas de FaaS, por operarem na Internet pública, também exigirão uma conexão com um banco de dados público. O estabelecimento de túneis VPN privados entre esses serviços pode ser difícil ou impossível.

É por esses motivos - interconectividade, simplicidade e agilidade - que oferecemos a opção de conectividade pública.

Segurança, segurança, segurança

Um serviço colocado na Internet pública enfrentará o escrutínio de agentes mal-intencionados de terceiros. A Internet está repleta de tentativas de coletar e explorar informações pessoais. Como um teste simples, conecte um sistema UNIX à Internet. Seus logs de SSH serão preenchidos rapidamente com tentativas de acessar a máquina usando dicionários de nomes de usuário e senhas comuns/roubados. Os firewalls mostrarão tentativas de verificação de portas abertas. Isso é apenas o normal aceito, e tem sido assim desde que me lembro.

Os bancos de dados, em particular, são um pote de mel para os criminosos que tentam explorar os sistemas a fim de obter acesso a listas de e-mails para ataques de phishing ou extrair detalhes de cartões de crédito para fraude e roubo de identidade. Você simplesmente precisa tornar esses serviços seguros.

O recurso de conectividade pública da operadora exige o uso de criptografia completa de ponta a ponta. Isso evita que bisbilhoteiros vejam informações confidenciais enquanto estiverem em redes públicas. Os certificados digitais formam uma relação de confiança entre clientes e servidores. Um cliente verificará se um servidor é válido para o nome do host ao qual tentou se conectar e se foi assinado por uma autoridade de certificação confiável.

O Operador permite o uso apenas de cadeias de certificados de servidor e não atua como uma autoridade de certificação, assinando certificados de servidor para servidores individuais à medida que a topologia muda. Atuar como uma CA permitiria que qualquer certificado fosse criado e assinado, por isso optamos pela abordagem segura. Como resultado, oferecemos suporte a um certificado curinga para o cluster como um todo. Ao usar certificados curinga, também precisamos usar o DNS público para que o cliente confirme que pode verificar se o certificado do servidor é válido para o host que está sendo contatado.

Esse histórico nos dá conhecimento suficiente para começar a implantar nosso banco de dados com conectividade pública.

Vamos começar

DNS

Conforme discutido, precisamos usar o DNS público para entrar em contato com os nós do cluster do Couchbase ao usar a conectividade pública. Esses DNSs podem ser comprados on-line de forma relativamente barata em registradores como Gandi, GoDaddy, Namecheap etc.

Também precisamos ser capazes de usar o DNS dinâmico. À medida que os nós são adicionados e removidos do nosso cluster do Couchbase, precisamos que as entradas correspondentes sejam adicionadas e removidas do DNS. Elas também precisam ser atualizadas se os endereços IP públicos desses nós mudarem. Isso se deve ao alto desempenho, ao sharding do lado do cliente usado pelos clientes do Couchbase e pelo XDCR. Usaremos o Kubernetes external-dns para realizar atualizações de DDNS. O link lista os provedores de DDNS compatíveis. Depois de adquirir um domínio DNS, você precisará delegar seus servidores de nomes ao provedor de DDNS escolhido. Minha escolha pessoal para este exemplo é Cloudflare. A etapa final de preparação é a criação de uma chave de API ou de outras credenciais para que o controlador external-dns se autentique com o provedor de DDNS e controle os registros de DNS exigidos pelo cluster do Couchbase.

TLS

Para a maioria das pessoas, essa é a parte mais mística do processo. As páginas da Web HTTPS simplesmente funcionam de forma transparente, portanto, o usuário comum não precisa se preocupar com isso no dia a dia. Não vou entrar em detalhes (pois isso é assunto para outro post), mas o que precisamos discutir são os principais aspectos que precisam ser vinculados à configuração de DNS escolhida.

Estou usando meu domínio DNS pessoal, spjmurray.com.brpara esta demonstração. Instalarei meu cluster do Couchbase em seu próprio namespace chamado 6c3c0075-b44a-11e9-9518-4a8d7629c69ae o próprio cluster será chamado de couchbase. É importante conhecer esses parâmetros porque eles nos permitem endereçar exclusivamente um cluster do Couchbase em nosso cluster do Kubernetes. O cluster do Couchbase será configurado de modo que seu domínio seja couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk. O operador exigirá a criação de registros A dentro desse domínio para cada nó, bem como o Console da Web do Couchbase.

Conhecendo nosso domínio, agora podemos determinar o nome alternativo do assunto do certificado curinga do DNS *.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk.

A ferramenta EasyRSA do OpenVPN é um método simples de gerar certificados. Primeiro, clone o repositório e inicialize-o.

Gere o certificado da CA e o par de chaves. Se você se lembra, a chave privada da CA é usada para assinar digitalmente um certificado de servidor. Um cliente pode então verificar se o certificado do servidor é autêntico com a chave pública da CA. Esse comando solicitará um nome de CA e uma senha. Após a conclusão, o certificado da CA poderá ser encontrado em pki/ca.crt.

O certificado do servidor e o par de chaves são criados em seguida. Quando o TLS for especificado em sua configuração de cluster do Couchbase, o Operator usará o TLS para se comunicar com o cluster. Isso evita que senhas ou dados confidenciais sejam transmitidos em texto simples. Para dar suporte aos nomes DNS privados do Kubernetes, precisamos de outro nome alternativo de assunto curinga do DNS. O nopass também deve ser especificada para que a chave privada não seja criptografada e possa ser lida pelo servidor Couchbase. O comando a seguir solicitará uma senha; essa é a senha da chave privada da CA usada para assinar digitalmente o certificado.

Você pode verificar se o certificado está de acordo com o esperado examinando-o no OpenSSL:

O EasyRSA cria chaves privadas no formato moderno PKCS#7, mas o Couchbase Server suporta apenas o PKCS#1. Para remediar isso, precisamos converter os formatos.

Agora que o TLS está configurado, colete seu certificado CA e o par certificado/chave privada do servidor, pois eles serão necessários ao configurar o cluster do Couchbase em uma etapa posterior.

Configuração de DDNS

Agora podemos começar a implantar alguns recursos reais do Kubernetes. Primeiro, vamos criar nosso namespace para que o controlador external-dns seja executado e uma conta de serviço para ser executada.

É necessária uma função para conceder permissão ao controlador external-dns para interrogar os recursos do Kubernetes no namespace em que ele está sendo executado. A função está vinculada à conta de serviço com a qual o controlador external-dns será executado. Neste exemplo, usarei uma função de cluster para que ela possa ser compartilhada entre todas as instâncias do controlador external-dns. No entanto, ela será vinculada dentro do namespace, pois o controlador não precisa acessar todos os namespaces. Usuários do OpenShift: Você precisará de privilégios de administrador para a criação e vinculação de funções, pois elas exigem escalonamento de privilégios e, por motivos de segurança, não podem ser executadas por usuários normais. A função se parece com o seguinte:

E é instalado com o seguinte:

A etapa final é instalar o controlador external-dns. Nós o configuraremos para procurar serviços dentro do namespace. Se um serviço tiver uma anotação external-dns.alpha.kubernetes.io/hostname então o controlador external-dns criará registros DNS A no mapeamento do nosso provedor DDNS para o endereço IP do serviço.

É possível que várias instâncias do external-dns estejam sincronizando registros de DNS para o mesmo domínio. Se ele vir um registro que não corresponda a um serviço que esteja gerenciando, ele o excluirá. Para evitar que dois ou mais controladores adicionem continuamente seus próprios registros e excluam os de outros, adicionamos um GUID para que o controlador responda apenas aos registros que possui. Para sua curiosidade, a propriedade é gerenciada por meio de registros DNS TXT. O YAML de implementação é parecido com o seguinte. Você deve substituir sua própria chave de API do Cloudflare e endereço de e-mail nos parâmetros de ambiente.

Isso pode ser criado com o seguinte:

Verifique se a implantação está em execução e se estamos prontos para instalar o cluster do Couchbase.

Instalar o operador

Isso é abordado extensivamente no documentação oficial. Primeiro, você precisará instalar as definições de recursos personalizados. Em seguida, instale o controlador de admissão dinâmico em um namespace de sua escolha e conecte-o à API do Kubernetes.

O controlador de admissão é um componente obrigatório da implementação do Operator 1.2.0. Ele aplica valores padrão ao cluster e, o mais importante, faz a validação fora do escopo da validação do esquema JSON nativo. A validação mais importante que ele realiza para essa configuração é garantir que o DNS e o TLS estejam configurados corretamente na definição do cluster do Couchbase.

O Operator é instalado no mesmo namespace que o controlador external-dns usando um processo muito semelhante ao do controlador external-dns.

Cluster público do Couchbase

A etapa final é, na verdade, a mais fácil. Aqui está a definição YAML:

O console de administração e os recursos expostos (por serviços de pod) são expostos com novos parâmetros que permitem que o tipo de serviço seja especificado. Nesta ocasião, estou executando no GKE. Quando um Balanceador de carga é criado, ele recebe um endereço IP público associado a ele.

A nova configuração de DNS, quando especificada, anotará o console de administração e os serviços por pod com os rótulos compreendidos pelo controlador de DNS externo. Para a configuração do console administrativo, isso é console.${metadata.name}.${spec.dns.domain} por exemplo.

Por fim, como estamos usando conectividade pública e DNS, o controlador de admissão dinâmica nos forçará a usar TLS. Os parâmetros do TLS são repleto de segredos contendo os certificados TLS que criamos anteriormente para esse cluster.

Crie o cluster e observe os registros de status ou do Operador para verificar a conclusão. Eventualmente, você deverá conseguir se conectar ao console com a url https://console.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk:18091/ à medida que os IPs do balanceador de carga são alocados e os registros DNS são adicionados. Você pode usar esse mesmo endereço para estabelecer clusters remotos do XDCR e inicializar SDKs de clientes do Couchbase. Parabéns, você ativou a conectividade pública!

Solução de problemas

A simples explicação de como configurar a conectividade pública é metade do trabalho. Você precisa ser capaz de determinar onde está o problema antes de levantar casos de suporte. Como a culpa é sempre da rede (na maioria das vezes), aqui estão algumas dicas para ajudá-lo.

O DNS não é instantâneo, leva tempo para que os registros apareçam e leva tempo para que as modificações se propaguem à medida que os TTLs expiram. Para verificar se o DNS está de acordo com o esperado, primeiro procure os nomes de DNS esperados. Encontre os nomes dos serviços:

Procure o nome DNS calculado:

O registro A do DNS existe? O endereço IP corresponde ao endereço IP público do serviço?

Em seguida, você precisa ter certeza de que as portas solicitadas estão escutando. Podemos verificar se a porta Admin habilitada para TLS está escutando e podemos estabelecer uma sessão TCP nessa porta:

A última coisa a fazer é determinar se o TLS está funcionando como esperado usando o certificado CA:

Além disso, para os mais corajosos, você pode verificar se os endereços DNS passados para os clientes estão corretos:

Próximas etapas

O Couchbase Autonomous Operator 1.2.0 é uma grande versão com muitos recursos novos. Os principais focos são a capacidade de atualização e a facilidade de uso. Esperamos que você goste de fazer coisas novas e legais com ele tanto quanto nós gostamos de criá-lo. Como sempre, seu feedback é fundamental!

• Experimente: https://www.couchbase.com/downloads
• Fóruns de suporte: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
• Documentação: https://docs.couchbase.com/operator/1.2/whats-new.html

Leia mais

• Operador Autônomo 1.2.0 Rede: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking