Jak skonfigurować trwającą replikację z zewnętrznego managera sekretów do AWS Secrets Manager?

Secrets Managers to doskonałe narzędzie do bezpiecznego przechowywania poufnych informacji i zapewniania dostępu do tajnych materiałów zaufanym osobom, aplikacjom lub systemom. W różnych środowiskach możesz mieć wielu Secrets Managers, hostowanych przez różnych dostawców, co może zwiększyć złożoność utrzymywania spójnego modelu operacyjnego dla Twoich wpisów. W takich sytuacjach scentralizowanie sekretów w jednym źródle prawdy i replikacja podzbiorów w innych Secrets managers może uprościć model operacyjny.

W tym artykule wyjaśniono, w jaki sposób możesz użyć zewnętrznego Secrets Manager jako źródła prawdy, jednocześnie replikując podzbiór tych informacji do AWS Secrets Manager. W ten sposób będziesz mógł używać danych, które pochodzą i są zarządzane przez Twojego zewnętrznego Secrets Manager w aplikacjach Amazon Web Services (AWS) lub w usługach AWS, które korzystają z takiego rozwiązania.

Autorzy zademonstrują to podejście w poniższym artykule, konfigurując przykładowy open-source HashiCorp Vault do tworzenia i utrzymywania sekretów oraz tworzenia mechanizmu replikacji, który umożliwia korzystanie z tych sekretów w AWS za pomocą AWS Secrets Manager. Chociaż w tym tekście jako przykładu użyto HashiCorp Vault, można również zmodyfikować mechanizm replikacji, aby korzystać z Secrets Managers od innych dostawców.

Ważne: Ten artykuł ma na celu zapewnienie wskazówek, których można użyć podczas planowania i wdrażania mechanizmu replikacji tajnych wpisów. Przykłady w tym poście nie są przeznaczone do uruchamiania bezpośrednio w środowisku produkcyjnym, a przed wdrożeniem tego rozwiązania należy wziąć pod uwagę wymagania dotyczące zwiększania zabezpieczeń. Na przykład HashiCorp udostępnia samouczki dotyczące wzmacniania skarbców produkcyjnych.

Kiedy i dlaczego rozważyć replikację wpisów tajnych?

Podstawowy przypadek użycia w tym artykule dotyczy klientów, którzy uruchamiają aplikacje w AWS i obecnie używają zewnętrznego Secrets Manager do zarządzania swoimi tajnymi danymi, hostowanymi lokalnie, w chmurze AWS lub z zewnętrznym dostawcą. Ci klienci zwykle posiadają istniejące potoki wdrażania oraz procedury i procesy związane z zarządzaniem tajnymi danymi. Klienci z taką konfiguracją mogą chcieć zachować istniejącego zewnętrznego Secrets Manager i mieć zestaw danych, które są dostępne dla obciążeń działających poza AWS, a także obciążeń działających w ramach AWS, za pomocą AWS Secrets Manager.

Inny przypadek użycia dotyczy klientów, którzy są w trakcie migracji obciążeń do chmury AWS i chcą utrzymać (tymczasową) hybrydową formę zarządzania tajnymi danymi. Replikując je z istniejącego zewnętrznego Secrets Manager, klienci mogą migrować swoje sekrety do chmury AWS jeden po drugim, testować, czy działają, integrować je z zamierzonymi aplikacjami i systemami, a po zakończeniu migracji usuwać zewnętrzny Secret Manager.

Ponadto niektóre usługi AWS, takie jak Amazon Relational Database Service (Amazon RDS) Proxy, AWS Direct Connect MACsec i AD Connector seamless join (Linux), obsługują tylko sekrety z AWS Secrets Manager. Klienci mogą korzystać z tajnej replikacji, jeśli posiadają Secret Managera innej firmy i chcą mieć możliwość korzystania z tajemnic innej firmy w usługach wymagających integracji z AWS Secrets Manager. W ten sposób klienci nie muszą już zarządzać sekretami w dwóch miejscach.

Dwa podejścia do replikacji danych

W tym artykule autorzy omówią dwa główne modele replikacji sekretów z zewnętrznego Secret Managera do AWS Secrets Manager: Pull model i Push model.

Pull model

W modelu Pull możesz korzystać z usług AWS, takich jak Amazon EventBridge i AWS Lambda, aby okresowo dzwonić do zewnętrznego Secret Managera w celu pobrania sekretów i ich aktualizacji. Główną zaletą tego modelu jest to, że nie wymaga żadnej większej konfiguracji zewnętrznego Secret Managera. Zasoby AWS i mechanizm służący do „wyciągania” tajnych wpisów muszą mieć odpowiednie uprawnienia i dostęp sieciowy do tych sekretów. Może jednak wystąpić opóźnienie między utworzeniem i aktualizacją klucza tajnego a momentem pobrania go do replikacji, w zależności od skonfigurowanego odstępu czasu między ściąganiem z AWS do zewnętrznego Secret Managera.

Push model

Główną zaletą tego rozwiązania jest minimalne opóźnienie między utworzeniem lub aktualizacją klucza tajnego, a udostępnieniem tych danych w AWS Secrets Manager. Model Push minimalizuje również ruch sieciowy wymagany do replikacji, ponieważ jest to przepływ jednokierunkowy. Jednak ten model dodaje warstwę złożoności do replikacji, ponieważ wymaga dodatkowej konfiguracji w zewnętrznym Secrets Manager. Mówiąc dokładniej, model Push jest zależny od zdolności zewnętrznego Secrets Managera do uruchamiania opartych na zdarzeniach integracji „wypychania” z zasobami AWS. Będzie to wymagało opracowania niestandardowej integracji i zarządzania nią po stronie zewnętrznego Secrets Managera.

Ten tekst koncentruje się na modelu Pull, aby zapewnić przykładową integrację, która nie wymaga dodatkowej konfiguracji w Secrets Manager innej firmy.

Replikuj dane do AWS Secrets Manager za pomocą modelu Pull

W tej sekcji zostanie omówiony przykład wykorzystania modelu Pull w celu replikacji danych z zewnętrznego Secrets Manager do AWS Secrets Manager.

Omówienie rozwiązania

Architektura przedstawiona na rysunku nr 1 składa się z następujących głównych kroków, ponumerowanych w widoczny sposób na schemacie:

1. Wyrażenie Cron w Amazon EventBridge wywołuje funkcję AWS Lambda co 30 minut.
2. Aby połączyć się z zewnętrznym Secrets Managerem, funkcja Lambda napisana w NodeJS pobiera zestaw zdefiniowanych przez użytkownika kluczy API należących do menedżera danych z AWS Secrets Manager. Zakres tych kluczy API został ograniczony, aby zapewnić dostęp tylko do odczytu do kluczy tajnych, które powinny być replikowane, zgodnie z zasadą najniższych uprawnień. Więcej informacji na ten temat znajduje się w Kroku 3: Aktualizowanie klucza tajnego połączenia Vault.
3. Trzeci krok ma dwa warianty w zależności od tego, gdzie hostowany jest Twój zewnętrzny menedżer tajemnic:

1. Funkcja Lambda jest skonfigurowana do pobierania danych z Secrets Managera innej firmy, który jest hostowany poza AWS. Wymaga to wystarczającej sieci i routingu, aby umożliwić komunikację z funkcji Lambda.

Uwaga: W zależności od lokalizacji zewnętrznego menedżera tajnych wpisów może być konieczne rozważenie różnych topologii sieci. Na przykład niezbędne może okazać się skonfigurowanie łączności hybrydowej między środowiskiem zewnętrznym a chmurą AWS przy użyciu AWS Site-to-Site VPN lub AWS Direct Connect lub obu.

1. Funkcja Lambda jest skonfigurowana do pobierania kluczy tajnych Secrets Managera innej firmy działającego w Amazon Elastic Compute Cloud (Amazon EC2).

Ważne: Aby uprościć wdrożenie tej przykładowej integracji, autorzy użyją Secrets Managera hostowanego na publicznie dostępnej instancji Amazon EC2 w ramach tego samego VPC, co funkcja Lambda (3b). Minimalizuje to dodatkowe komponenty sieciowe wymagane do interakcji z menedżerem. Mówiąc dokładniej, instancja EC2 obsługuje przechowalnię HashiCorp Vault typu open source. W dalszej części tego artykułu autorzy będą odnosić się do kluczy API HashiCorp Vault jako tokenów Vault.

1. Funkcja Lambda porównuje wersję klucza tajnego, którą właśnie pobrała z zewnętrznego Secrets Managera z wersją klucza tajnego, który ma w AWS Secrets Manager (według znacznika). Funkcja utworzy nowy tajny klucz w AWS Secrets Manager, jeśli ten jeszcze nie istnieje i zaktualizuje go, jeśli pojawi się nowa wersja. Funkcja Lambda uwzględni w replikacji tylko wpisy tajne z zewnętrznego Secrets Managera wpisów tajnych, jeśli pasują do określonego prefiksu. Na przykład hybrid-aws-secrets/.
2. W przypadku błędu synchronizacji klucza tajnego powiadomienie e-mail jest wysyłane na adresy e-mail, które są subskrybowane we wdrożonym temacie usługi Amazon Simple Notification Service (Amazon SNS). Ta przykładowa aplikacja wykorzystuje jako przykład powiadomienia e-mail z Amazon SNS, ale można ją również zintegrować z usługami takimi jak ServiceNow, Jira, Slack lub PagerDuty. Dowiedz się więcej o tym, jak używać webhooków do publikowania wiadomości Amazon SNS w usługach zewnętrznych.

Konfiguracja rozwiązania

W tej sekcji zostanie omówione wdrażanie rozwiązania modelu Pull pokazanego na rysunku nr 1, przy wykorzystaniu następujących kroków:

Krok 1: Wdróż rozwiązanie przy użyciu zestawu narzędzi AWS CDK

Na potrzeby tego artykułu utworzono skrypt AWS Cloud Development Kit (AWS CDK), który można znaleźć w tym repozytorium AWS GitHub. Korzystając z AWS CDK, zdefiniowano infrastrukturę przedstawioną na rysunku nr 1 jako Infrastructure as Code (IaC), napisaną w TypeScript, gotową do wdrożenia i wypróbowania. AWS CDK to platforma programistyczna typu open source, która umożliwia pisanie infrastruktury aplikacji w chmurze jako kodu przy użyciu popularnych języków programowania, takich jak TypeScript, Python, Java, Go i tak dalej.

Warunki wstępne

Aby wdrożyć rozwiązanie, w systemie powinny znajdować się następujące elementy:

1. Git
2. Node (wersja 16 lub nowsza)
3. jq
4. AWS CDK Toolkit. Zainstaluj przy użyciu npm (zawartego w konfiguracji węzła), uruchamiając npm install -g aws-cdk w lokalnym terminalu.
5. An AWS access key ID i secret access skonfigurowane w ten sposób będą współdziałać z Twoim kontem AWS. Zobacz Podstawy konfiguracji w Podręczniku użytkownika interfejsu wiersza poleceń AWS, aby uzyskać więcej informacji.
6. Docker zainstalowany i uruchomiony na twoim komputerze.

By wdrożyć rozwiązanie

1. Sklonuj skrypt CDK do tajnej replikacji.

git clone https://github.com/aws-samples/aws-secrets-manager-hybrid-secret-replication-from-hashicorp-vault.git SecretReplication

2. Użyj sklonowanego projektu jako katalogu bieżącego.

cd SecretReplication

3. Zainstaluj wymagane zależności, aby wdrożyć aplikację.

npm install

4. Dostosuj wartości konfiguracyjne dla swojej instalacji w pliku cdk.json. Można na przykład dostosować wartość secretsPrefix, aby zmienić prefiks używany przez funkcję Lambda do określania podzbioru wpisów tajnych, które powinny być replikowane z zewnętrznego menedżera wpisów tajnych.
5. Przygotuj swoje środowiska AWS z niektórymi zasobami wymaganymi do wdrożenia rozwiązania. Przy poprawnie skonfigurowanych poświadczeniach AWS uruchom następujące polecenie.

cdk bootstrap

Podstawowe zasoby tworzone przez bootstrapping to repozytorium Amazon Elastic Container Registry (Amazon ECR) dla obrazu AWS Lambda Docker, zasobnik Amazon Simple Storage Service (Amazon S3) dla zasobów statycznych oraz role AWS Identity and Access Management (IAM) z odpowiednimi zasadami IAM. Możesz znaleźć pełną listę zasobów, przechodząc do stosu CDKToolkit w AWS CloudFormation po zakończeniu polecenia.

6. Wdróż infrastrukturę
   cdk deploy

To polecenie wdraża infrastrukturę pokazaną na rysunku nr 1 za pomocą usługi AWS CloudFormation. Aby uzyskać pełną listę zasobów, możesz wyświetlić SecretsManagerReplicationStack w AWS CloudFormation po zakończeniu wdrażania.

Uwaga: Jeśli w Twoim środowisku lokalnym nie ma terminala, który umożliwia uruchamianie tych poleceń, rozważ użycie AWS Cloud9 lub AWS CloudShell.

Po zakończeniu wdrażania w terminalu powinieneś zobaczyć dane wyjściowe, które wyglądają tak, jak zaprezentowano na rysunku nr 2. Jeśli się powiedzie, dane wyjściowe będą zawierać adres IP przykładowej przechowalni HashiCorp Vault i jej interfejs sieciowy.

Krok 2: Zainicjuj HashiCrop Vault

W ramach danych wyjściowych skryptu wdrażania otrzymasz adres URL umożliwiający dostęp do interfejsu użytkownika otwartego magazynu HashiCorp Vault. Aby uprościć dostępność, adres URL wskazuje publicznie dostępną instancję Amazon EC2, na której działa interfejs użytkownika HashiCorp Vault, jak pokazano w kroku 3b na rysunku nr 1.

Pora na własne oczy spojrzeć na właśnie utworzony skarbiec HashiCorp. Przejdź do adresu URL w przeglądarce i powinieneś zobaczyć stronę inicjalizacji Raft Storage, jak pokazano na rysunku nr 3.

Skarbiec wymaga wstępnej konfiguracji w celu przygotowania magazynu i uzyskania początkowego zestawu kluczy głównych. Możesz przejść przez te kroki ręcznie w interfejsie użytkownika HashiCorp Vault, ale zamiast tego zaleca się użycie skryptu initialise_vault.sh, który jest częścią projektu SecretsManagerReplication.

Korzystając z interfejsu API HashiCorp Vault, skrypt inicjujący automatycznie wykona następujące czynności:

1. Zainicjuj pamięć Raft, aby umożliwić Vault przechowywanie sekretów lokalnie w instancji.
2. Utwórz początkowy zestaw kluczy do rozpieczętowania Vault. Co ważne, do celów demonstracyjnych skrypt wykorzystuje pojedynczy udział klucza. W środowiskach produkcyjnych zaleca się używanie wielu udziałów klucza, tak aby w nagłych przypadkach do zrekonstruowania klucza głównego było potrzebnych wiele udziałów.
3. Zapisz klucze unseal w init/vault_init_output.json w swoim projekcie.
4. Otwórz skarbiec HashiCorp za pomocą wygenerowanych wcześniej kluczy.
5. Włącz dwa silniki tajnych danych klucz-wartość:

1. Silnik nazwany na cześć prefiksu używanego do replikacji, zdefiniowany w pliku cdk.json. W tym przykładzie jest to hybrid-aws-secrets. Twórcy zamierzają użyć sekretów w tym silniku do replikacji do AWS Secrets Manager.
2. Silnik o nazwie super-secret-engine, którego użyjesz, aby pokazać, że twój mechanizm replikacji nie ma dostępu do tajnych danych poza silnikiem używanym do replikacji.

1. Utwórz trzy przykładowe sekrety, dwa w hybrid-aws-secrets i jeden w super-secret-engine.
2. Utwórz zasadę tylko do odczytu, którą można zobaczyć w pliku init/replication-policy-payload.json po zakończeniu działania skryptu, która umożliwia dostęp tylko do odczytu tylko do danych, które powinny zostać zreplikowane.
3. Utwórz nowy token skarbca z dołączoną polityką tylko do odczytu, dzięki czemu może być później używany przez funkcję AWS Lambda do pobierania tajnych informacji do replikacji.

Aby uruchomić skrypt inicjujący, wróć do terminala i uruchom następujące polecenie. ./initialise_vault.sh

Skrypt poprosi Cię o podanie adresu IP Twojego skarbca HashiCorp. Podaj adres IP (bez portu) i wybierz Enter. Wprowadź y, aby skrypt utworzył kilka przykładowych wpisów tajnych.

Jeśli wszystko się powiedzie, powinieneś zobaczyć dane wyjściowe zawierające tokeny umożliwiające dostęp do skarbca HashiCorp, podobne do pokazanego na rysunku nr 4.

Skrypt instalacyjny wygenerował dwa tokeny: jeden token główny, który będzie używany do zadań administracyjnych, oraz token tylko do odczytu, który będzie wykorzystywany do odczytywania tajnych informacji na potrzeby replikacji. Upewnij się, że możesz uzyskać dostęp do tych tokenów podczas wykonywania pozostałych kroków opisanych w tym tekście.

Uwaga: Token główny jest używany w tym artykle wyłącznie do celów demonstracyjnych. W środowiskach produkcyjnych nie należy używać tokenów root do zwykłych działań administracyjnych. Zamiast tego należy używać ról o ograniczonym zakresie w zależności od potrzeb organizacji. W tym przypadku token główny służy do podkreślenia, że w supertajnym silniku znajdują się dane, które nie są przeznaczone do replikacji. Te wpisy tajne nie mogą być widoczne ani dostępne za pomocą tokenu tylko do odczytu.

Wróć do przeglądarki i odśwież interfejs HashiCorp Vault. Powinieneś teraz zobaczyć stronę Sign in to Vault. Zaloguj się przy użyciu metody Token i użyj tokenu głównego. Jeśli nie masz już tokena głównego w swoim terminalu, możesz go znaleźć w pliku init/vault_init_output.json.

Po zalogowaniu powinna zostać wyświetlona strona przeglądu z włączonymi trzema silnikami wpisów tajnych, jak pokazano na rysunku nr 5.

Jeśli eksplorujesz hybrid-aws-secrets i super-secret-engine, możesz zobaczyć dane, które zostały automatycznie utworzone przez skrypt inicjujący. Na przykład pierwszy klucz tajny do replikacji, który zawiera przykładowy klucz tajny typu key-value wraz z kluczami tajnymi i managerem wartości.

Jeśli przejdziesz do Zasad na górnym pasku nawigacyjnym, zobaczysz również zasady aws-replication-read-only, jak pokazano na rysunku nr 6. Ta zasada zapewnia dostęp tylko do odczytu do ścieżki hybrydowej-aws-secrets.

Polityka tylko do odczytu jest dołączona do tokena tylko do odczytu, którego będziesz używać w tajnej replikacji funkcji Lambda. Ta zasada jest ważna, ponieważ ogranicza dostęp uzyskiwany przez funkcję Lambda za pomocą tokenu do określonego prefiksu przeznaczonego do replikacji. Do tajnej replikacji wystarczy wykonać operacje odczytu. Ta polityka gwarantuje, że możemy czytać, ale nie możemy dodawać, zmieniać ani usuwać żadnych tajemnic w HashiCorp Vault za pomocą tokena.

Możesz zweryfikować uprawnienia tokena tylko do odczytu, logując się do interfejsu użytkownika HashiCorp Vault przy użyciu tokena tylko do odczytu, a nie tokena głównego. Teraz powinieneś zobaczyć tylko hybrid-aws-secrets. Nie masz już dostępu do super-secret-engine, który widziałeś na rysunku nr 5. Jeśli spróbujesz utworzyć lub zaktualizować klucz tajny, pojawi się błąd oznaczający odmowę uprawnień.

Świetnie! Twój HashiCorp Vault jest teraz gotowy do replikacji jego tajnych danych z hybrid-aws-secrets do AWS Secrets Manager. W następnej sekcji opisano ostateczną konfigurację, którą należy wykonać, aby umożliwić dostęp do danych w HashiCorp Vault przez mechanizm replikacji w AWS.

Krok 3: Zaktualizuj tajny klucz połączenia Vault

Aby zezwolić na tajną replikację, musisz przyznać funkcji AWS Lambda dostęp do tokena tylko do odczytu HashiCorp Vault, który został utworzony przez skrypt inicjujący. Aby to zrobić, musisz zaktualizować vault-connection-secret, który został zainicjowany w AWS Secrets Manager jako część wdrożenia AWS CDK.

W celach demonstracyjnych autorzy pokażą Ci, jak to zrobić za pomocą AWS Management Console, ale możesz to również przeprowadzić programowo, używając AWS Command Line Interface (AWS CLI) lub AWS SDK poprzez polecenie update-secret.

Aby zaktualizować klucz tajny połączenia Vault (konsola):

1. W AWS Management Console przejdź do AWS Secrets Manager > Secrets > hybrid-aws-secrets/vault-connection-secret.
2. W obszarze Tajna wartość wybierz opcję Odzyskaj tajną wartość, a następnie wybierz opcję Edytuj.
3. Zaktualizuj wartość vaultToken, aby zawierała token tylko do odczytu, który został wygenerowany przez skrypt inicjujący.

Krok 4: (Opcjonalny) Skonfiguruj powiadomienia e-mail o błędach replikacji

Jak zaprezentowano na rysunku nr 1, funkcja Lambda wyśle wiadomość e-mail za pomocą Amazon SNS na wyznaczony adres e-mail, gdy jeden lub więcej kluczy tajnych nie zostanie zreplikowanych. Będziesz musiał skonfigurować rozwiązanie, aby używało poprawnego adresu e-mail. Aby to zrobić, przejdź do pliku cdk.json w katalogu głównym folderu SecretReplication i dostosuj parametr noticeEmail do adresu e-mail, którego jesteś właścicielem. Po zakończeniu wdróż zmiany za pomocą polecenia cdk wdrażania. W ciągu kilku minut otrzymasz wiadomość e-mail z prośbą o potwierdzenie subskrypcji. W przyszłości będziesz otrzymywać powiadomienia e-mail, jeśli replikacja co najmniej jednego klucza tajnego zakończy się niepowodzeniem.

Przetestuj tajną replikację

Możesz poczekać do 30 minut na automatyczne wywołanie funkcji Lambda w celu replikacji wpisów tajnych lub wywołać tę funkcję ręcznie.

Aby przetestować Twoją tajną replikację:

1.  Otwórz konsolę AWS Lambda i znajdź funkcję Secret Replication (nazwa zaczyna się od SecretsManagerReplication-SecretReplication).
2. Przejdź do zakładki Test.
3. W przypadku akcji zdarzenia tekstowego wybierz opcję Utwórz nowe zdarzenie, utwórz zdarzenie przy użyciu parametrów domyślnych, a następnie wybierz przycisk Test po prawej stronie, jak pokazano na rysunku nr 8.

Spowoduje to uruchomienie funkcji. Jednocześnie powinien zostać wyświetlony komunikat o powodzeniu, jak pokazano na rysunku nr 9. Jeśli jest to pierwsze wywołanie funkcji Lambda, w wynikach zobaczysz, że zostały utworzone dwa wpisy tajne.

Odpowiednie logi dla wywołania funkcji Lambda można znaleźć w grupie Log w AWS CloudWatch o nazwie /aws/lambda/SecretsManagerReplication-SecretReplicationLambdaF-XXXX.

Aby sprawdzić, czy tajne dane zostały dodane, przejdź do AWS Secrets Manager w konsoli, a oprócz vault-connection-secret, który edytowałeś wcześniej, powinieneś teraz zobaczyć również dwa nowe tajne klucze z tym samym prefiksem hybrid-aws-secrets , jak pokazano na rysunku nr 10.

Na przykład, jeśli spojrzysz na first-secret-for-replication, możesz zobaczyć pierwszą wersję klucza tajnego, z sekretami klucza tajnego i menedżerem wartości klucza tajnego, jak pokazano na rysunku nr 11.

Sukces! Masz teraz dostęp do tajnych wartości, które pochodzą z HashiCorp Vault w AWS Secrets Manager. Zwróć też uwagę, że do klucza tajnego dołączony jest znacznik wersji. Jest to element, niezbędny do zaktualizowania klucza, o czym dowiesz się więcej w następnych dwóch sekcjach.

Zaktualizuj klucz

Zalecaną praktyką bezpieczeństwa jest częsta rotacja wpisów tajnych. Funkcja Lambda w tym rozwiązaniu nie tylko replikuje klucze podczas ich tworzenia, ale także okresowo sprawdza, czy istniejące sekrety w AWS Secrets Manager powinny zostać zaktualizowane, gdy zewnętrzny Secrets Manager (w tym przypadku HashiCorp Vault) ma nową wersję tajnego. Aby sprawdzić, czy to działa, możesz ręcznie zaktualizować klucz w swoim HashiCorp Vault i obserwować jego replikację w AWS Secrets Manager w taki sam sposób, jak opisano w poprzedniej sekcji. Zauważysz, że tag wersji twojego klucza tajnego jest aktualizowany automatycznie, gdy pojawia się nowa replikacja klucza tajnego z zewnętrznego Secrets Managera do AWS Secrets Manager.

Secret replication logic

Ta sekcja wyjaśni bardziej szczegółowo logikę tajnej replikacji. Pora pochylić się nad poniższym diagramem sekwencji, który wyjaśnia ogólną logikę zaimplementowaną w funkcji Lambda.

Ten diagram podkreśla, że funkcja Lambda najpierw pobierze listę tajnych nazw z HashiCorp Vault. Następnie funkcja otrzyma listę kluczy z AWS Secrets Manager, pasującą do prefiksu, który został skonfigurowany do replikacji. AWS Secrets Manager zwróci listę kluczy pasujących do tego prefiksu, a także zwróci ich metadane i tagi. Zauważ, że funkcja nie pobrała jeszcze żadnego tajnego materiału.

Następnie funkcja przejdzie przez każdą tajną nazwę podaną przez HashiCorp Vault i sprawdzi, czy tajemnica istnieje w AWS Secrets Manager:

• Jeśli nie ma klucza pasującego do tej nazwy, funkcja pobierze tajny materiał z HashiCorp Vault, w tym numer wersji i utworzy nowy sekret w AWS Secrets Manager. Dodaje również tag wersji do tajnego klucza, aby pasował do wersji.
• Jeśli w AWS Secrets Manager istnieje już klucz pasujący do tej nazwy, funkcja Lambda najpierw pobierze metadane z tego klucza w HashiCorp Vault. Jest to wymagane do uzyskania numeru wersji klucza tajnego, ponieważ numer wersji nie został ujawniony, gdy funkcja początkowo pobierała listę kluczy tajnych z HashiCorp Vault. Jeśli tajna wersja z HashiCorp Vault nie pasuje do wartości wersji klucza tajnego w AWS Secrets Manager (na przykład wersja w HashiCorp Vault to 2, a wersja w AWS Secrets manager to 1), wymagana jest aktualizacja, aby uzyskać wartości ponownie zsynchronizowane. Dopiero teraz funkcja Lambda pobierze rzeczywisty tajny materiał z HashiCorp Vault i zaktualizuje sekret w AWS Secrets Manager, w tym numer wersji w tagu.

Funkcja Lambda pobiera metadane dotyczące kluczy, zamiast od razu pobierać tajny materiał z HashiCorp Vault. Zazwyczaj wpisy tajne nie są aktualizowane zbyt często. Jeśli funkcja Lambda jest wywoływana co 30 minut, to nie powinna dodawać ani aktualizować żadnych kluczy w większości wywołań. Używając metadanych do określenia, czy tajny materiał jest potrzebny do tworzenia lub aktualizowania sekretów, minimalizujesz liczbę pobrań tajnych materiałów zarówno z HashiCorp Vault, jak i AWS Secrets Manager.

Uwaga: funkcja AWS Lambda posiada uprawnienia do pobierania pewnych tajnych kluczy z HashiCorp Vault. Ważne jest, aby dokładnie przejrzeć kod Lambdy i wszelkie późniejsze zmiany w nim, aby zapobiec wyciekowi danych. Na przykład należy upewnić się, że funkcja Lambda nie zostanie zaktualizowana kodem, który nieumyślnie rejestruje tajny materiał poza funkcją Lambda.

Użyj swojego klucza

Teraz, gdy utworzyłeś i zreplikowałeś swoje klucze, możesz ich używać w swoich aplikacjach AWS lub usługach AWS zintegrowanych z Secrets Manager. Na przykład możesz użyć kluczy podczas konfigurowania połączenia dla serwera proxy w Amazon RDS w następujący sposób.

Aby użyć tajnego klucza podczas tworzenia serwera proxy w Amazon RDS:

1. Przejdź do usługi Amazon RDS w konsoli.
2. W lewym okienku nawigacyjnym wybierz Proxy, a następnie wybierz Utwórz proxy.
3. Na karcie Łączność możesz teraz wybrać pierwszy klucz tajny do replikacji lub drugi klucz tajny do replikacji, utworzone przez funkcję Lambda po zreplikowaniu ich z HashiCorp Vault.

Należy pamiętać, że konsumenci zreplikowanych kluczy tajnych w AWS Secrets Manager będą wymagać uprawnień IAM o ograniczonym zakresie do korzystania z tajnych kluczy i usługi zarządzania kluczami AWS (AWS KMS), które zostały użyte do zaszyfrowania sekretów. Na przykład zobacz Krok 3: Utwórz rolę i zasady IAM na stronie Skonfiguruj współużytkowane połączenia z bazą danych za pomocą serwera proxy Amazon RDS.

Zarządzaj uprawnieniami

Ze względu na poufny charakter kluczy ważne jest, aby zakres uprawnień był jak najmniejszy. Dzięki temu zapobiegniesz przypadkowemu dostępowi do tajnych informacji. Instalator przyjmuje strategię uprawnień o najniższym stopniu uprawnienień, w której jawnie zezwala się tylko na niezbędne działania na zasobach wymaganych do replikacji. Uprawnienia należy jednak zweryfikować zgodnie ze swoimi standardami bezpieczeństwa.

W architekturze tego rozwiązania istnieją dwa główne miejsca, w których kontrolujesz dostęp do zarządzania swoimi sekretami w Secrets Manager.

Lambda execution IAM role: Rola IAM przejęta przez funkcję Lambda podczas wykonywania czynności zawiera odpowiednie uprawnienia do tajnej replikacji. Istnieje dodatkowy środek bezpieczeństwa, który wyraźnie odrzuca wszelkie działania na zasobie, który nie jest wymagany do replikacji. Na przykład funkcja Lambda posiada tylko uprawnienia do publikowania w temacie Amazon SNS, który jest tworzony dla nieudanych replikacji i jawnie odmówi akcji publikowania w jakimkolwiek innym temacie. Nawet jeśli ktoś przypadkowo doda zezwolenie do zasad dla innego tematu, wyraźna odmowa nadal zablokuje to działanie.

AWS KMS key policy: gdy inne usługi potrzebują dostępu do zreplikowanego klucza tajnego w AWS Secrets Manager, potrzebują również pozwolenia na użycie klucza AWS KMS hybrid-aws-secrets-encryption-key. Musisz zezwolić zleceniodawcy na te uprawnienia za pośrednictwem zasad kluczy AWS KMS. Dodatkowo możesz zarządzać uprawnieniami do klucza AWS KMS dla zleceniodawcy za pomocą polityki tożsamości. Na przykład jest to wymagane podczas uzyskiwania dostępu do kluczy AWS KMS na kontach AWS. Zobacz Permissions for AWS services in key policies i Specifying KMS keys in IAM policy statements w Przewodniku programisty AWS KMS.

Opcje dostosowywania przykładowego rozwiązania

Rozwiązanie, które zostało omówione w tym poście, stanowi przykład replikacji kluczy z HashiCorp Vault do AWS Secrets Manager przy użyciu modelu Pull. Ta sekcja zawiera dodatkowe opcje dostosowywania, które można wziąć pod uwagę podczas konfigurowania rozwiązania lub jego własnej wariacji.

1. W zależności od używanego rozwiązania możesz mieć dostęp do różnych metadanych dołączonych do kluczy, których możesz użyć do określenia czy klucz powinien zostać zaktualizowany. Na przykład, jeśli masz dostęp do danych reprezentujących właściwość last_updated_datetime, możesz użyć tego do ustalenia czy klucz tajny powinien zostać zaktualizowany.
2. Zaleca się, aby w miarę możliwości nie używać długowiecznych tokenów. W tym przykładzie użyto statycznego tokena Vault, aby dać funkcji Lambda dostęp do HashiCorp Vault. W zależności od używanego rozwiązania możesz zaimplementować lepsze mechanizmy uwierzytelniania i autoryzacji. Na przykład HashiCorp Vault umożliwia korzystanie z uwierzytelniania IAM przy użyciu AWS IAM zamiast statycznego tokena.
3. Ten post dotyczył tworzenia kluczy i ich aktualizowania, ale w przypadku konfiguracji produkcyjnej należy również rozważyć usunięcie kluczy. W zależności od wymagań możesz wybrać strategię, która najlepiej odpowiada Twoim potrzebom w zakresie obsługi tajnych danych w AWS Secrets Manager po usunięciu oryginalnego klucza w HashiCorp Vault. W modelu Pull można rozważyć usunięcie klucza w AWS Secrets Manager, jeśli odpowiadający mu klucz w zewnętrznym Secrets Manager nie jest już obecny.
4. W przykładowej konfiguracji ten sam klucz AWS KMS jest używany do szyfrowania zarówno zmiennych środowiskowych funkcji Lambda, jak i kluczy w AWS Secrets Manager. Możesz dodać dodatkowy klucz AWS KMS (co wiązałoby się z dodatkowymi kosztami), aby mieć dwa oddzielne klucze do tych zadań. Umożliwiłoby to zastosowanie bardziej szczegółowych uprawnień do dwóch kluczy w odpowiednich zasadach kluczy KMS lub zasadach tożsamości IAM, które używają kluczy.

Wnioski

Za pomocą tego artykułu dowiedziałeś się w jaki sposób możesz podejść do replikacji swoich kluczy z zewnętrznego Secret Managera do AWS Secrets Manager. Ten tekst skupiał się na modelu Pull, w którym rozwiązanie okresowo pobierało klucze z zewnętrznego HashiCorp Vault i automatycznie tworzyło lub aktualizowało odpowiedni klucz w AWS Secrets Manager. Korzystając z tego modelu, możesz teraz używać zewnętrznych kluczy w swoich aplikacjach lub usługach AWS Cloud, które są zaintegrowane z AWS Secrets Manager.

Źródło: AWS