Tworzenie nowego konta AWS i zasobów przy użyciu opcji multiple provider w środowisku Terraform

Tworzenie nowego konta AWS i zasobów przy użyciu opcji multiple provider w środowisku Terraform to rzecz, którą dość często rekomendujemy Klientom, posiadającym wiele środowisk. Jak to zrobić w praktyce? Zapraszamy do lektury naszego tutoriala.

Wiele kont? O co chodzi?

Jako że w firmie Hostersi staramy się stosować najlepsze praktyki realizacji środowisk AWS, często proponujemy klientom posiadającym wiele środowisk używanie więcej niż jednego konta AWS, z których każde służy do realizacji jednego środowiska. Zauważamy, że praktyka tworzenia osobnych środowisk AWS w jednej organizacji AWS Organizations daje klientom niezaprzeczalne korzyści i można przedstawić szereg zalet takiego rozwiązania, w tym co najmniej:
• separację i izolację zasobów, w tym zasobów globalnych,
• możliwość centralizacji dostępu administracyjnego do poszczególnych środowisk (kont),
• ułatwienie rozliczania kosztów poszczególnych środowisk, a także ich konsolidację,
• umożliwienie bezpiecznej replikacji i centralizacji logów i kopii zapasowych.

Na czym w skrócie polega idea posiadania wielu kont w organizacji?

Doskonały, prosty, ale praktyczny przykład pokazano na rysunku 1 (Źródło: segment.io)

Prosta organizacja AWS

Konto Ops, będące kontem nadrzędnym w organizacji, jest kontem macierzystym dla trzech kont: Dev, Stage i Production, odpowiadającym infrastrukturom o określonych rolach. Dodatkowo pełni rolę punktu wejściowego dla wszystkich trzech kont, zarówno na poziomie zarządzania, jak i dostępu (o czym poniżej. Zainteresowani szerszym ujęciem problemu na poziomie biznesowym powinni sięgnąć po opis praktyk AWS, w którym przedstawiono implikacje dla procesów zarządzania i bezpieczeństwa.

Automatyzacja!

Oczywiście zgodnie z ideą DevOps, którą wyznajemy na co dzień ? najlepiej zautomatyzować działanie zakładania nowego konta, a następnie umieścić w nim odpowiednie zasoby – jak chociażby utworzyć już w nowym koncie state bucket oraz lock na DynamoDB. To wszystko najlepiej w jednym planie – tylko że konto AWS (child) zakłada się przecież w kontekście konta głównego (parent), a zasoby w koncie podrzędnym (child) należy utworzyć już w kontekście nowego, utworzonego przed chwilą konta. Z pomocą przychodzi możliwość posiadania wielu providerów naraz. Terraform posiada bardzo przydatną w tym miejscu właściwość – sam sprawdza, które zasoby trzeba utworzyć najpierw i pozwala już w tym samym kodzie odnosić się do realizowanych zasobów.

Tworzenie nowego konta AWS i zasobów przy użyciu opcji multiple provider w środowisku Terraform

Zakładając, że zostanie utworzone nowe konto AWS o nazwie account, a także, zgodnie z dokumentacją, zostanie wykorzystania opcjonalna nazwa roli tworzona automatycznie przez AWS (tutaj: role_name) celem zarządzania nowym kontem, można zatem utworzyć następujący
zestaw providerów:

Skąd terraform pobierze obiekt aws_organizations_account.account? Tworzony jest przy pomocy następującego zestawu instrukcji:

Powyższy kod pokazuje, że najczęściej dla definicji odpowiednich wartości określa się ich wartości w zmiennych (variables). Można do tego użyć również zmiennych lokalnych (locals),
zwłaszcza jeśli korzystamy z nich więcej niż raz. Przykładowo, często zamiast wszystkim zasobom nadawać tagi w ich definicji, można je określić w zmiennych lokalnych:

Natomiast dla danego zasobu tagi definiuje się wówczas następująco:

Używanie wielu providerów

Po utworzeniu nowego konta należy je wyposażyć. Zasoby tworzone w koncie podrzędnym można utworzyć w tym samym planie terraforma, natomiast wyróżniać je będzie określenie konkretnego providera, którego określono aliasem (w tym przypadku child). Przykładem może być utworzenie administratora dla nowego konta, czyli obiektu użytkownika, grupy, określenie jego przynależności do tej grupy, a także przypisanie odpowiedniej polityki uprawnień (dodatkowo tworzone są poświadczenia – klucz i secret do pracy programatycznej z kontem):

Jak widać w powyższym fragmencie, każdy z elementów posiada jawne oznaczenie użycia innego providera niż domyślny. Innym przykładem może być automatyczne uruchomienie sieci VPC należących do konta głównego oraz konta podrzędnego i konstrukcja VPC peering dla stosownego ruchu pomiędzy tymi sieciami. Jeśli chcielibyście zobaczyć kod takiego przykładu, dajcie nam znać!

Terraform apply!

Powyższe podsumować można w jednym gotowym do użycia pliku terraforma, albo rozbić na odpowiednie pliki. Jako Hostersi polecamy to drugie rozwiązanie. Współpraca z klientami, których infrastruktury są rozbudowane wielokrotnie bardziej niż dziesiątki zasobów, nauczyła nas, aby zawsze, od początku projektu, dzielić zasoby w terraformie na wiele plików, które grupują zasoby podobne lub należące do tej samej usługi AWS (na przykład zasoby sieciowe). O wiele łatwiej później rozwinąć kod infrastruktury. Nawet jeśli z początku życia projektu pliki definiujące poszczególne elementy zawierają niewiele zasobów, dość szybko po rozpoczęciu korzystania z terraforma „na całego”, rozwiną się w tysiące linii kodu.

Gotowe więc! Można teraz pozakładać konta (oczywiście przy pomocy terraforma) użytkownikom bezpośrednio w koncie podrzędnym, albo użyć jeszcze bardziej zmyślnej strategii, w której:
• przygotowujemy kolejne role, z których korzystać będą użytkownicy z konta głównego (odpowiednio ograniczone), dostarczające odpowiednich możliwości stosownie do roli. Używamy ich w pliku credentials (~/.aws/credentials), podobnie jak w przypadku podstawowym:

Uwaga praktyczna: używanie profilu z rolą jako [default], zamiast podawania go wyraźnie w bloku provider może spowodować problemy typu:

Dane dostępowe używające poszczególnych ról zapisujemy w odpowiednich profilach, więc zawsze możemy zmienić rolę.

• możemy dodatkowo używać profili zamiennie w sposób przezroczysty dla terraforma, a mianowicie poprzez aws-vault – to pozwoli na szybką i bezpieczną zamianę ról w przypadku używania więcej niż jednej roli podczas pracy z systemami, a także, w przypadku dostępu do konta głównego poprzez MFA, na wydłużenie nieszczęsnego limitu 1h ważności tokena STS (i konieczności ponownego logowania się). To jednak temat na osobny artykuł.

Maciej Rostański

DevOps Engineer w Hostersi

Pytania? Skontaktuj się z nami

Zobacz również:

Jak używać pliku stanu zdalnego remotestate w środowisku Terraform?

Rewolucja w bezpiecznych połączeniach VPN z WireGuard

Chmura obliczeniowa nie taka straszna. Wprowadzenie do Amazon Web Services

Przeniesienie sklepu internetowego do chmury

Skąd się bierze wysoka dostępność (HA) w chmurze?