RDS privado a partir do EC2: a mesma VPC, peering ou outra coisa?

O portátil do programador chega à instância privada de RDS através da VPN do pessoal, mas a aplicação no EC2 não consegue ligar-se de todo. Isto não é uma implementação quebrada. O portátil tem um túnel que a instância EC2 nunca herda, e «privado» no RDS significa que a base de dados não tem um endpoint público, não que os utilizadores humanos da VPN sejam os únicos chamadores permitidos. A aplicação precisa do seu próprio caminho autorizado, da sua própria relação com o grupo de segurança e da sua própria identidade na base de dados, e a ordem em que escolhe estes três poupa a maior parte da depuração. Decida a rota primeiro, depois as permissões, e por fim verifique a partir do ambiente implementado em vez de a partir da sua secretária.

A VPN do portátil não é o caminho da aplicação

Faça o que fizer a VPN do pessoal pelas pessoas, não faz nada por uma instância a menos que essa instância faça explicitamente parte do mesmo caminho de rede. Uma instância EC2 numa sub-rede privada chega ao RDS através do encaminhamento VPC, dos grupos de segurança e das ACL de rede. Não herda o túnel de uma pessoa, a sessão de uma pessoa nem as credenciais de uma pessoa, e não o deve fazer: a conectividade de aplicações sem supervisão e o acesso remoto do pessoal têm de ser operáveis de forma independente.

Essa independência é uma vantagem. Quando a VPN falha, a aplicação continua a funcionar. Quando a aplicação se comporta mal, ninguém perde o seu acesso remoto. Os desenhos que fundem as duas coisas num único caminho costumam ser descobertos durante um incidente, no pior momento possível.

Decisão 1: a mesma VPC, caminho direto

Quando a aplicação e a base de dados estão na mesma VPC com encaminhamento direto e sem qualquer dispositivo intermédio de inspeção entre elas, o caminho é simples e a referência ao grupo de segurança é a ferramenta mais poderosa disponível. Dê à aplicação o seu próprio grupo e permita depois a porta da base de dados a partir desse grupo em vez de a partir de um intervalo de endereços:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

A porta é ilustrativa e tem de corresponder ao motor. Uma referência de grupo autoriza o tráfego das instâncias da aplicação; não copia as suas regras nem cria um início de sessão na base de dados. Dois problemas separados, duas correções separadas.

Depois verifique o resto do caminho em vez de parar na regra que acabou de acrescentar. A política de saída da aplicação, o conjunto completo de grupos associados à base de dados, as tabelas de rotas da sub-rede e quaisquer ACL de rede têm de concordar. As regras dos grupos de segurança têm estado, ao passo que uma ACL de rede personalizada tem de permitir o pedido e o tráfego de retorno em regras separadas, incluindo as portas efémeras. Uma regra nova e estreita para a base de dados também não anula uma autorização ampla anterior que já estava associada.

Decisão 2: outra VPC ou outra conta

Se a aplicação estiver noutra VPC, os proprietários da rede escolhem uma interligação privada suportada: peering, um desenho de trânsito ou um acordo de VPC partilhada. Depois têm de existir as duas direções de encaminhamento, a resolução de nomes tem de funcionar para o endpoint do RDS, e a origem que a política da base de dados avalia tem de corresponder ao que chega efetivamente. Nomes de conta coincidentes ou uma relação de faturação partilhada não fornecem nada disso.

A referência ao grupo de segurança é a parte que varia. Funciona em vários desenhos de interligação privada, mas deixa de funcionar no momento em que um dispositivo intermédio reescreve a origem ou termina a ligação, porque a base de dados passa a ver o dispositivo intermédio em vez do seu grupo de aplicação. Os cenários de VPC do RDS separam o acesso dentro da mesma VPC dos outros arranjos, e vale a pena verificar a sua topologia concreta contra eles antes de assumir que um estilo de regra se transfere.

Não resolva uma rota em falta tornando a base de dados acessível publicamente. Essa é outra decisão de exposição com outro proprietário, e normalmente é proposta por quem está mais longe da consequência.

Decisão 3: que identidade a base de dados aceita

O acesso de rede e a autenticação da base de dados são camadas separadas, e confundi-las produz os erros mais enganadores. O papel da instância é uma identidade AWS para chamar as API da AWS. Não é um utilizador da base de dados. A autenticação da base de dados com IAM é uma funcionalidade suportada onde o motor e a configuração o permitem, e continua a ser um mapeamento para um utilizador da base de dados, não um substituto.

Utilize o nome do endpoint do RDS na configuração da aplicação em vez de um endereço capturado de uma única pesquisa. A comutação por falha Multi-AZ altera o endereço por trás desse nome, e uma aplicação fixada a um IP falhará exatamente no momento em que for necessária. Mantenha a verificação TLS do motor ativa em vez de a desativar para fazer desaparecer um erro, porque uma falha de verificação lhe diz algo sobre o endpoint que alcançou.

Depois conceda à conta da base de dados o mínimo de que a aplicação precisa, no esquema que ela realmente utiliza. Esse trabalho é aborrecido, é auditável e é a parte sobre a qual uma revisão de incidente vai perguntar.

Verifique a partir do ambiente implementado

Teste a partir da instância ou de uma tarefa que corra com o mesmo grupo, sub-rede e papel. Quatro falhas parecem iguais a partir de um portátil e distinguem-se facilmente a partir dali: um nome que não resolve, uma ligação que expira, uma falha de validação TLS e um início de sessão recusado na base de dados. Cada uma aponta para uma fronteira diferente, e alterar a exposição da base de dados antes de saber qual tem é adivinhar.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Se a ligação funcionar a partir da instância e falhar a partir da sua secretária, o caminho da aplicação está bem e o seu acesso é o que há a corrigir. Se falhar a partir de ambos, comece pelas verificações de grupo e rota acima e não pelas credenciais. Essa única comparação evita a maior parte do ruído que estes pedidos geram.