Terraform 0.12 – krok wstecz

Końcem maja 2019 roku HashiCorp ogłosił pierwszy release Terraform 0.12. Wersja ta oprócz nowych funkcjonalności niestety „psuje” także niektóre stare funkcjonalności. HashiCorp zdecydowało się na wycofanie z utrzymywania zakodowanych informacji w pliku stanu. W związku z tym plik stanu (state) jest jawny. Nie ma możliwości utrzymania informacji wrażliwych w formie zaszyfrowanej. Do czego takie podejście prowadzi? Ano do tego, że jeśli np. cały zespół pracował sobie nad infrastrukturą i np. dodawane były w kodzie konta użytkowników to w przeszłości można było użyć pgp_key. Dane w pliku stanu były zaszyfrowane podanym kluczem. Dzięki temu danych wrażliwych takich jak AWS_ACCESS_SECRET_KEY nie znał każdy kto miał dostęp do pliku stanu. Takie dane mogła poznać tylko osoba, która miała klucz prywatny.

Problem

Terraform zmienił politykę i podejście do tej sprawy. Zadecydował, że state jest plikiem wrażliwym. Nieuprawnieni nie powinni mieć do niego dostępu. Oznacza to nic innego, jak to, że osoby, które mają dostęp do pliku stanu mają dostęp do wszystkich danych wrażliwych w nim zapisanych. Na chwilę obecną problem nie jest bardzo duży bo wszystkie providery jeszcze nie usunęły pgp_key ze swoich resourców. Jednak już informacja na temat tego, że ten parametr jest deprecated i zostanie w kolejnych wersjach usunięty widnieje w przypadku użycia najnowszego providera aws. Najnowszy provider google już nie umożliwia korzystania z pgp_key. Tak więc np. nie utworzymy sobie różnych service account do których rożni członkowie naszego zespołu będą mieli dostęp. Wszyscy będą znali credentiale do każdego jednego konta :/ Powoduje to sporo komplikacji jeśli chodzi o zapewnienie odpowiedniego poziomu bezpieczeństwa.

Rozwiązanie

Opcji rozwiązania powyższego problemu jest kilka:

1. Tak ufamy wszystkim mającym dostęp do pliku stanu, że się powyższym problemem nie przejmujemy
2. Zostajemy (do puki będzie to możliwe) przy starej wersji providera, który obsługuje pgp_key
3. Tak „drobimy” nasza infrastrukturę i podział na pliki stanu, żeby każdy kto ma mieć dostęp do pewnych informacji miał je w pliku stanu do którego tylko on ma dostęp
4. Wykupujemy HashiCorp Terraform Cloud i tam zarządzamy odpowiednimi dostępami
5. Cały proces zmian w infrastrukturze przenosimy do naszego systemu CI/CD. Umożliwiamy tylko zaufanym osobom na wprowadzanie zmian (mergowanie do mastera), oraz na oglądanie outputu z tego procesu

Niestety żadna z powyższych opcji nie jest idealna. jeżeli stosujemy podejście DevOps i każdy developer ma możliwość zarządzania infrastrukturą z poziomu terraforma. Przejście na Terraform Cloud wprowadza dodatkowe narzędzie i utrzymywanie wszystkiego w kodzie przestaje być możliwe. Dostępy musimy sobie wyklikać. Dodatkowo każde z rozwiązań  wprowadza nieco komplikacji. W obecnym kształcie najmniej inwazyjna wydaje się metoda #2. Wstrzymuje się z upgradem providerów do puki jest taka opcjonalność :/ Oczywiście tyczy się to projektów, które nie mają jeszcze wdrożonego rozwiązania #5. Pod względem bezpieczeństwa to ono wydaje się optymalne. Więcej na temat podejścia HashiCorp do sprawy można znaleźć tutaj.