Desativação do Serviço Realhostip.Com
O serviço realhostip.com será descontinuado em 1 de outubro de 2014. Neste artigo, Paul Angus, Arquiteto de Cloud da ShapeBlue, explica como o serviço funciona, qual efeito terá a desativação para os usuários e o que é necessário fazer caso você seja afetado.
O que é o realhostip.com?
Quando você se conecta à VM de sistema Console Proxy (CPVM) ou faz o download de disco ou de uma imagem ISO da VM de armazenamento secundário (SSVM), você se conectar através de uma conexão segura (https). Isto é particularmente importante quando você insere sua senha. Para que a operação seja segura, você precisa se conectar a um URL que contenha um FQDN e possuir um certificado para seguir adiante.
O domínio realhostip.com associado e o serviço de DNS foram criados para fornecer uma solução “fora da caixa” para este problema. Ao usar o domínio realhostip.com e com um pouco de “mágica” inteligente, com hostnames e um scrip DNS dinâmico, os dados transmitidos são encriptados.
O problema é que qualquer um pode usar este sistema, o que significa que só porque uma VM possui um certificado não quer dizer que você possa confiar nele. Além disso, alguém poderia extrair o certificado de um ambiente Apache CloudStack e em seguida usá-lo para descriptografar o tráfego. É muito improvável, porém tecnicamente possível.
É por isso que o uso de um certificado disponível publicamente está sendo aposentado.
Quem poderá ser afetado?
Para novas instalações do Apache CloudStack 4.3 e posteriores, o serviço realhostip não é utilizado; ao invés dele, é utilizado comunicações HTTP (sem criptografia) para as interfaces públicas – será necessário um certificado SSL para isso. Então, se estiver com a versão 4.3 ou posterior já instalada e em operação, o desligamento do serviço não irá afetá-lo. No entanto, se estiver com a versão 4.3 ou posterior em uso e não tiver um certificado SSL instalado, você deve instalar um para a segurança de seus usuários.
Para usuários de ambientes CloudStack 4.3 que tenham sido atualizados a partir de versões anteriores, você tem a opção adicional de desabilitar a comunicação HTTPS para o Console Proxy e Storage Secundário, mas terá de fazê-lo por sua própria conta e risco; o uso não é recomendado para nada que seja público, ainda que no mais isolado dos ambientes de teste. Assim, para as versões anteriores ao Apache CloudStack 4.3 ou ambientes que tenham sido atualizados de uma versão anterior, os administradores precisam substituir o realhostip.com com seu próprio domínio e certificado, do contrário o serviço de Console Proxy e os downloads da VM Secondary Storage irão parar de funcionar em 1º outubro de 2014.
O que fazer para substituir o serviço realhostip.com?
Há diversas fontes que explicam como usar o seu próprio domínio para o Console Proxy e Storage Secundário de maneira segura. Vamos apresentar várias fontes e aprofundar as referências.
A primeira coisa que você precisa é de um domínio para substituir o realhostip.com. Geralmente as pessoas usam um subdomínio do seu domínio corporativo (como console.supercloud.com) para que ele possa ser gerenciado separadamente do domínio parental. Você não precisa obrigatoriamente usar um subdomínio, mas vamos assumir que possua um para os fins deste artigo. Em seguida você precisa de um servidor DNS ou dois que atuarão como resolvers para o seu subdomínio. Os resolvers precisam resolver todos os endereços em suas faixas de endereços IPs públicos. Parte da inteligência da solução realhostip está no caminho que o CloudStack cria para os FQDNs tanto para as VMs do Console Proxy como para as VMs do Storage Secundário. Por exemplo, para o endereço IP 1.2.3.4 o CloudStack criaria um FQDN 1-2-3-4.realhostip.com e para 4.3.2.1 seria 4-3-2-1.realhostip.com. Ele torna a criação da zona mais fácil e até mesmo possibilita a criação de um servidor DNS que resolverá qualquer nome utilizado nele neste formato. Na verdade é isso que os servidores DNS realhostip fazem (o código fonte está em https://github.com/ke4qqq/RHIP).
O resultado da mudança depois de aplicada irá substituir a URL para 1-2-3-4.console.supercloud.com por exemplo.
As coisas ficam mais complicadas se o seu DNS é hospedado por terceiros e se você possui uma grande quantidade de IPs públicos que as VMS do sistema poderiam usar. Criar as entradas para um arquivo de zona em uma planilha é fácil, mas se você tiver que preencher um formulário web para o seu provedor para cada endereço IP, será uma tarefa longa, chata e propensa a erros, por isso aconselhamos a criação de seus próprios servidores DNS para o seu subdomínio ou tentar que seu provedor faça a criação de todas as entradas de uma única vez com base nas suas informações.
Portanto, agora que possuímos um domínio para usar e alguns servidores DNS para resolvê-lo, precisamos de um certificado para proteger o acesso. Você precisará de um certificado curinga para o subdomínio pois precisará trabalhar com vários hosts *.console.supercloud.com. Uma busca rápida para ‘certificado curinga’ retornará uma imensa lista de fornecedores de certificados. As grandes empresas certificadoras provavelmente terão um sistema para a compra de certificados onde a TI corporativa pode inserir os dados do seu cartão de crédito e poupar muito tempo.
Para obter um certificado você precisa gerar uma chave privada e em seguida um pedido de assinatura de certificado (CSR), que é utilizado pela certificadora para gerar um certificado com base na chave privada. O procedimento para fazer isso está documentado na própria documentação do Apache CloudStack – você precisará do openssl instalado, o que é bastante fácil, mas os servidores de gerenciamento do CloudStack o terão instalado para que você possa sempre fazer isso por lá. http://docs.cloudstack.apache.org/en/latest/administration_guide.html#changing-the-console-proxy-ssl-certificate-and-domain
Agora você solicitar ao fornecedor escolhido o seu certificado curinga.
Depois de conseguir seu certificado curinga, você vai precisar do certificado público da autoridade certificadora root (CA) e o(s) certificado(s) público(s) da(s) CA(s) intermediária(s) (se houver). Eles podem ter sido enviados juntamente com o certificado curinga ou você pode precisar seguir para o site da sua unidade certificadora para baixá-los. Você precisa de toda a cadeia de certificados de modo que um cliente possa ver que a fonte é fidedigna e confiável.
Agora vem a parte mais complicada – receber tudo no formato correto. Este processo sempre acaba sendo o mais complexo, mas qualquer usuário que tenha tentado adicionar um certificado a um NetScaler, IIS, RDS ou ao próprio Apache CloudStack irá testemunhar que raramente é simples – o certificado e/ou a chave privada que você possui nunca parece estar no formato correto ou parece faltar um certificado intermediário – então fique calmo: você não está sozinho.
A ferramenta openssl é muito boa para a conversão entre formatos.
Então, tudo o que você precisa ter é o seguinte:
- Certificado público raiz da CA em formato PEM
- Certificado público(s) da CA intermediária(s) (se houver) em formato PEM
- Certificado curinga do domínio em formato PEM
- Chave privada no formato PKCS8
- Pode parecer óbvio ma você deve se certificar de que da Internet pública seus endereços IPs públicos sejam resolvidos, ou seja, 1-2-3-4.console.supercloud.com -> 1.2.3.4 antes de fazer a transição.
Agora que você está pronto para fazer a alteração basta seguir os seguintes passos:
- Atualize as configurações do Apache CloudStack para usar o novo certificado
- Faça o upload do novo certificado para o servidor de gerenciamento
- Reiniciar as VMs de Sistema para utilizar os novos certificados
- Verificar se o novo certificado está funcionando
Estas etapas estão muito bem documentadas na documentação oficial e também na Wiki do Apache CloudStack.
Procedimento para substituir o realhostip.com para o seu próprio domínio:
Detalhes que devem ser considerados ao alterar o domínio Realhost para o domínio personalizado:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=43188254
Troubleshooting – upload do novo certificado do domínio ao invés de usar o realhostip.com:
Um ponto extra a partir de nossa experiência é que as VMs do sistema devem ser interrompidas e em seguida iniciadas, ambas a partir da interface do Apache CloudStack, caso contrário o novo certificado não será aplicado.
Chip Childers escreveu este artigo há um tempo, e o sistema para importação de certificados foi aprimorado desde então, mas o link abaixo pode fornecer uma ajuda extra:
Resumo
Neste artigo apresentamos o serviço realhostip.com e explicamos porquê a descontinuidade do serviço afetará as nuvens baseadas em Apache CloudStack e Citrix CloudPlatform. Também apresentamos informações sobre as etapas necessárias para substituir o serviço realhostip.com e garantir a operação segura da sua nuvem.
Sobre o Autor
Paul Angus é arquiteto de nuvens na ShapeBlue. Ele projetou e implementou vários ambientes CloudStack para clientes em 4 continentes, com base no Apache CloudStack, Citrix Cloudplatform e Citrix Cloudportal.
Quando não está trabalhando na construção de nuvens, Paul gosta de criar scripts que compilam nuvens… e ocasionalmente pode ser visto tentando acertar uma bola de golfe.
