Prywatny RDS z EC2: ta sama VPC, peering czy coś innego?

Laptop dewelopera dociera do prywatnej instancji RDS przez VPN personelu, ale aplikacja na EC2 w ogóle nie może się połączyć. To nie jest zepsute wdrożenie. Laptop ma tunel, którego instancja EC2 nigdy nie dziedziczy, a „prywatny” w RDS oznacza, że baza danych nie ma publicznego punktu końcowego, a nie że ludzcy użytkownicy VPN są jedynymi dozwolonymi wywołującymi. Aplikacja potrzebuje własnej autoryzowanej ścieżki, własnej relacji z grupą zabezpieczeń i własnej tożsamości w bazie danych, a kolejność wyboru tych trzech oszczędza większość czasu debugowania. Najpierw zdecyduj o trasie, potem o uprawnieniach, a na końcu zweryfikuj ze wdrożonego środowiska, a nie ze swojego biurka.

VPN laptopa nie jest ścieżką aplikacji

Cokolwiek VPN personelu robi dla ludzi, nie robi nic dla instancji, chyba że ta instancja jest wyraźnie częścią tej samej ścieżki sieciowej. Instancja EC2 w prywatnej podsieci dociera do RDS przez routing VPC, grupy zabezpieczeń i sieciowe ACL. Nie dziedziczy ludzkiego tunelu, ludzkiej sesji ani ludzkich poświadczeń i nie powinna: nieobsługiwana łączność aplikacji i zdalny dostęp personelu muszą działać niezależnie.

Ta niezależność jest zaletą. Gdy VPN nie działa, aplikacja nadal działa. Gdy aplikacja zachowuje się źle, nikt nie traci dostępu zdalnego. Projekty, które łączą oba w jedną ścieżkę, zwykle odkrywa się podczas incydentu, w najgorszym możliwym momencie.

Decyzja 1: ta sama VPC, bezpośrednia trasa

Gdy aplikacja i baza danych są w tej samej VPC z bezpośrednim routingiem i bez urządzenia inspekcyjnego między nimi, trasa jest prosta, a odwołanie do grupy zabezpieczeń najsilniejszym dostępnym narzędziem. Daj aplikacji własną grupę, a następnie zezwól na port bazy danych z tej grupy zamiast z zakresu adresów:

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

Port jest przykładowy i musi odpowiadać silnikowi. Odwołanie do grupy autoryzuje ruch z instancji aplikacji; nie kopiuje ich reguł i nie tworzy logowania do bazy danych. Dwa osobne problemy, dwa osobne rozwiązania.

Następnie sprawdź resztę trasy, zamiast zatrzymywać się na regule, którą właśnie dodałeś. Zasady ruchu wychodzącego aplikacji, pełny zestaw grup przypisanych do bazy danych, tabele tras podsieci i wszelkie sieciowe ACL muszą się zgadzać. Reguły grup zabezpieczeń są stanowe, a niestandardowy sieciowy ACL musi zezwalać na żądanie i ruch powrotny w osobnych regułach, w tym porty efemeryczne. Nowa wąska reguła bazy danych nie unieważnia też starszego szerokiego zezwolenia, które było już przypisane.

Decyzja 2: inna VPC lub inne konto

Jeśli aplikacja jest w innej VPC, właściciele sieci wybierają obsługiwane połączenie prywatne: peering, projekt tranzytowy lub układ współdzielonej VPC. Wtedy muszą istnieć oba kierunki routingu, rozwiązywanie nazw musi działać dla punktu końcowego RDS, a źródło oceniane przez politykę bazy danych musi odpowiadać temu, co faktycznie przychodzi. Zgodne nazwy kont lub wspólna relacja rozliczeniowa nie dają niczego z tego.

Odwołanie do grupy zabezpieczeń to część, która się różni. Działa w kilku projektach połączeń prywatnych, ale przestaje działać w momencie, gdy urządzenie pośredniczące przepisze źródło lub zakończy połączenie, ponieważ baza danych widzi wtedy urządzenie pośredniczące, a nie twoją grupę aplikacji. Scenariusze VPC w RDS oddzielają dostęp w tej samej VPC od pozostałych układów i warto sprawdzić swoją konkretną topologię na ich tle, zanim założysz, że styl reguły się przenosi.

Nie rozwiązuj brakującej trasy przez udostępnienie bazy danych publicznie. To inna decyzja o ekspozycji z innym właścicielem i zwykle proponuje ją ten, kto jest najdalej od konsekwencji.

Decyzja 3: jaką tożsamość akceptuje baza danych

Dostęp sieciowy i uwierzytelnianie bazy danych to osobne warstwy, a ich mieszanie daje najbardziej mylące błędy. Rola instancji to tożsamość AWS do wywoływania API AWS. Nie jest użytkownikiem bazy danych. Uwierzytelnianie bazy danych przez IAM jest obsługiwaną funkcją tam, gdzie pozwalają na to silnik i konfiguracja, i nadal jest mapowaniem na użytkownika bazy danych, a nie jego zamiennikiem.

Używaj nazwy punktu końcowego RDS w konfiguracji aplikacji zamiast adresu przechwyconego z jednego wyszukiwania. Przełączenie Multi-AZ zmienia adres za tą nazwą, a aplikacja przypięta do IP zawiedzie dokładnie w momencie, gdy jest potrzebna. Pozostaw włączoną weryfikację TLS silnika, zamiast ją wyłączać, aby błąd zniknął, ponieważ niepowodzenie weryfikacji mówi ci coś o punkcie końcowym, do którego dotarłeś.

Następnie przyznaj kontu bazy danych minimum potrzebne aplikacji, w schemacie, którego naprawdę używa. Ta praca jest nudna, podlega audytowi i to o nią zapyta przegląd incydentu.

Zweryfikuj ze wdrożonego środowiska

Testuj z instancji lub z zadania działającego z tą samą grupą, podsiecią i rolą. Cztery awarie wyglądają podobnie z laptopa i łatwo je tam rozróżnić: nazwa, która się nie rozwiązuje, połączenie, które kończy się przekroczeniem czasu, błąd walidacji TLS i odrzucone logowanie do bazy danych. Każda wskazuje inną granicę, a zmiana ekspozycji bazy danych przed poznaniem, którą masz, jest zgadywaniem.

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

Jeśli połączenie działa z instancji, a nie działa z biurka, ścieżka aplikacji jest w porządku i to twój dostęp wymaga naprawy. Jeśli nie działa z obu miejsc, zacznij od kontroli grupy i trasy powyżej, a nie od poświadczeń. To jedno porównanie zapobiega większości zamieszania, które generują te zgłoszenia.