RDS privato da EC2: stessa VPC, peering o qualcos'altro?

Il portatile dello sviluppatore raggiunge l’istanza RDS privata tramite la VPN del personale, ma l’applicazione su EC2 non riesce a connettersi affatto. Non è un deployment rotto. Il portatile ha un tunnel che l’istanza EC2 non eredita mai, e «privato» in RDS significa che il database non ha un endpoint pubblico, non che gli utenti umani della VPN siano gli unici chiamanti consentiti. L’applicazione ha bisogno del proprio percorso autorizzato, del proprio rapporto con il gruppo di sicurezza e della propria identità nel database, e l’ordine in cui scegliete questi tre elementi fa risparmiare la maggior parte del debug. Decidete prima la rotta, poi i permessi, poi verificate dall’ambiente distribuito invece che dalla scrivania.

La VPN del portatile non è il percorso dell’applicazione

Qualunque cosa faccia la VPN del personale per le persone, non fa nulla per un’istanza a meno che quell’istanza non faccia esplicitamente parte dello stesso percorso di rete. Un’istanza EC2 in una subnet privata raggiunge RDS tramite il routing VPC, i gruppi di sicurezza e le ACL di rete. Non eredita il tunnel di una persona, la sessione di una persona né le credenziali di una persona, e non dovrebbe: la connettività delle applicazioni senza supervisione e l’accesso remoto del personale devono essere gestibili in modo indipendente.

Questa indipendenza è un vantaggio. Quando la VPN è giù, l’applicazione continua a funzionare. Quando l’applicazione si comporta male, nessuno perde il proprio accesso remoto. Le progettazioni che fondono le due cose in un’unica rotta vengono di solito scoperte durante un incidente, nel momento peggiore possibile.

Decisione 1: stessa VPC, rotta diretta

Quando l’applicazione e il database sono nella stessa VPC con routing diretto e senza alcun dispositivo intermedio di ispezione tra loro, la rotta è semplice e il riferimento al gruppo di sicurezza è lo strumento più potente disponibile. Date all’applicazione il proprio gruppo, poi consentite la porta del database da quel gruppo invece che da un intervallo di indirizzi:

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}'

La porta è illustrativa e deve corrispondere al motore. Un riferimento di gruppo autorizza il traffico dalle istanze dell’applicazione; non copia le loro regole e non crea un login al database. Due problemi separati, due correzioni separate.

Poi controllate il resto della rotta invece di fermarvi alla regola appena aggiunta. La politica in uscita dell’applicazione, l’insieme completo dei gruppi associati al database, le tabelle di routing della subnet e qualsiasi ACL di rete devono concordare. Le regole dei gruppi di sicurezza sono stateful, mentre un’ACL di rete personalizzata deve consentire la richiesta e il traffico di ritorno in regole separate, comprese le porte effimere. Una nuova regola ristretta per il database non annulla nemmeno un’autorizzazione ampia precedente già associata.

Decisione 2: un’altra VPC o un altro account

Se l’applicazione è in un’altra VPC, i proprietari della rete scelgono un’interconnessione privata supportata: peering, un progetto di transito o un accordo di VPC condivisa. Poi devono esistere entrambe le direzioni di routing, la risoluzione dei nomi deve funzionare per l’endpoint RDS, e l’origine valutata dalla politica del database deve corrispondere a ciò che arriva realmente. Nomi di account coincidenti o un rapporto di fatturazione condiviso non forniscono nulla di tutto ciò.

Il riferimento al gruppo di sicurezza è la parte che varia. Funziona in diverse progettazioni di interconnessione privata, ma smette di funzionare nel momento in cui un dispositivo intermedio riscrive l’origine o termina la connessione, perché il database vede allora il dispositivo intermedio invece del vostro gruppo applicativo. Gli scenari VPC di RDS separano l’accesso nella stessa VPC dagli altri arrangiamenti, e vale la pena verificare la vostra topologia specifica rispetto a essi prima di supporre che uno stile di regola si trasferisca.

Non risolvete una rotta mancante rendendo il database accessibile pubblicamente. È un’altra decisione di esposizione con un altro proprietario, e di solito la propone chi è più lontano dalla conseguenza.

Decisione 3: quale identità accetta il database

L’accesso di rete e l’autenticazione del database sono livelli separati, e confonderli produce gli errori più fuorvianti. Il ruolo dell’istanza è un’identità AWS per chiamare le API AWS. Non è un utente del database. L’autenticazione del database con IAM è una funzione supportata dove il motore e la configurazione lo consentono, e resta una mappatura verso un utente del database, non un sostituto.

Usate il nome dell’endpoint RDS nella configurazione dell’applicazione invece di un indirizzo catturato da una singola ricerca. Il failover Multi-AZ cambia l’indirizzo dietro quel nome, e un’applicazione fissata a un IP fallirà esattamente nel momento in cui serve. Lasciate attiva la verifica TLS del motore invece di disattivarla per far sparire un errore, perché un errore di verifica vi dice qualcosa sull’endpoint raggiunto.

Poi concedete all’account del database il minimo di cui l’applicazione ha bisogno, nello schema che usa realmente. Quel lavoro è noioso, è verificabile ed è la parte su cui chiederà una revisione dell’incidente.

Verificate dall’ambiente distribuito

Provate dall’istanza o da un’attività in esecuzione con lo stesso gruppo, subnet e ruolo. Quattro errori sembrano uguali da un portatile e si distinguono facilmente da lì: un nome che non si risolve, una connessione che va in timeout, un errore di validazione TLS e un login al database rifiutato. Ognuno punta a un confine diverso, e cambiare l’esposizione del database prima di sapere quale avete è indovinare.

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

Se la connessione riesce dall’istanza e fallisce dalla vostra scrivania, la rotta dell’applicazione va bene e il vostro accesso è ciò che va corretto. Se fallisce da entrambe, iniziate dai controlli di gruppo e rotta qui sopra invece che dalle credenziali. Quell’unico confronto evita la maggior parte del trambusto che questi ticket generano.