Olá pessoal, tudo bem?
Hoje vamos descobrir como podemos resolver nomes de domínios privados entre contas da AWS, utilizando o Route 53 Resolver.
Definindo o problema
Uma das recomendações da AWS é utilizarmos contas da diferentes para segregarmos acesso aos recursos, adicionando uma camada a mais de segurança. Essa separação pode ser feita de diversas formas, como contas para departamentos, ambientes, times, etc.
Outra recomendação é utilizarmos o AWS Organizations para vincular e organizar estas contas:
Porém, eventualmente precisaremos acessar recursos de uma conta à outra através de um VPC Peering, usando DNS. Até aí tudo bem, poderíamos configurar o route 53 local com o IP de destino. O problema é quando precisamos fazer algum acesso deste tipo à um recurso que ocasionalmente possa mudar o IP, como um ALB interno na conta destino.
Se o recurso também possuir um IP público, podemos configurar o peering para resolver o DNS público utilizando o IP privado. Isso é interessante pois trafegaremos as requisições dentro da rede da AWS, sem precisar sair para a internet.
Contudo, como no ALB interno citado acima, não teremos um IP público. Como resolvemos o DNS destes recursos então? Veremos isso na próxima sessão. 😀
Route 53 Resolver to the rescue!
Lançado em 2018, o Route 53 Resolver é uma solução para cloud híbrida e também para o problema definido acima.
Para isto precisaremos configurar o resolver em ambas as contas, uma como input e a outra como output. Abaixo veremos como a configuração é simples e rápida de ser feita. Para facilitar a nomenclatura, trataremos a conta que irá receber as requisições para resolver o DNS (input) como destino, e a que irá enviar estas requisições (output) como origem.
Configurando a conta destino para receber as consultas de DNS
No Route 53 devemos acessar o menu Endpoints de entrada.
Clicando em Criar endpoint de entrada, seremos levados a tela de configuração do endpoint. Aqui precisaremos informar os seguintes detalhes:
- Nome do endpoint: Nome amigável para o endpoint;
- VPC: A VPC que será usada para expor os IPs gerados pelo endpoint;
- Grupo de segurança: Grupo de segurança que será usado para o endpoint. Irá controlar o acesso a resolução de endereços;
- Endereços IP: O resolver solicita no mínimo duas subnets para que ele exponha os IPs de resolução de endereços.
Feito isto, como no exemplo acima foram selecionadas duas subnets, o resolver irá criar duas ENIs na VPC selecionada, uma para cada subnet.
Esta conta está pronta, agora vamos para a configuração da conta origem.
Configurando a conta origem para utilizar o resolver da conta destino
Na outra conta, precisamos configurar dois resources. O Endpoint de saída e a regra para a resolução do endereço.
Vamos começar pelo endpoint:
A configuração do endpoint de saída é idêntica à configuração do endpoint de entrada. Então quando clicamos em Criar endpoint de saída veremos o seguinte:
Após informarmos os dados necessários e clicarmos em enviar, teremos nosso endpoint de saída disponível.
Por fim, precisamos configurar a regra que irá ser aplicada na resolução do domínio.
Na regra, devemos informar:
- Nome: Nome amigável da regra;
- Tipo da regra: No caso definimos como Avançar (Forward);
- Nome do domínio: O nome do domínio ao qual esta regra será utilizada. Então, sempre que alguém pedir para resolver o endereço privatezone.local, ele utilizará esta regra;
- VPCs: As VPCs onde esta regra será aplicada;
- Endpoint de saída: O endpoint de saída usado nesta regra;
- Endereços IP de destino: Aqui iremos informar os endereços IPs gerados pelo Endpoint de entrada, criado na conta que receberá as consultas de DNS.
Feito isto, tudo estará criado. Um último ponto importante é que precisamos ter a porta 53 liberada no grupo de segurança vinculado ao Endpoint de entrada.
Testando a resolução de domínios entre as contas
Para testar, críamos uma zona privada na conta destino chamada privatezone.local (a mesma que foi configurada na rule criada acima).
E na conta de origem, críamos uma lambda em Node.js para resolver o DNS acima (privatezone.local – 172.31.1.1). O código da lambda é bem simples, e pode ser observado abaixo:
const dns = require('dns');
const net = require('net');
exports.handler = (event, context) => {
const d = 'privatezone.local';
dns.resolve(d, (err, result) => {
if (err) {
console.error(`dns: ${d}; error: ${err}`);
} else {
console.log(`dns: ${d}; result: ${result}`);
}
})
};Lembrando que a lambda deve estar na mesma VPC onde o endpoint de saída foi criado, e que o peering entre as VPCs da conta de origem e destino deve estar corretamente configurado. Se testarmos a lambda teremos o resultado abaixo:
Por hoje era isso, pessoal!
Abraços e boa semana a todos! 👍