Jak zarządzać sekretami w .tf i .tfstate?

Chciałbym skorzystać z Terraform MySQL Provider, aby zachować listę użytkowników mysql i udziela się przy tworzeniu nowych środowisk testowych. .tfI .tfstatepliki zarówno wydają się chce do przechowywania haseł MySQL w postaci zwykłego tekstu.

Dotyczy .tf:

Rozumiem, że .tfpliki podlegają kontroli wersji i są utrzymywane przez zespół. Czym różni się ta praktyka od tajemnic .tf? Czy w ogóle można zaszyfrować te wartości?

W sprawie .tfstate:

Mogę .tfstatebezpiecznie przechowywać gdzieś po uruchomieniu aplikacji Terraform, ale czy w tym przypadku użycia nie byłoby w ogóle potrzeby przechowywania?

Terraform obsługuje dodawanie dodatkowego pliku ze zmiennymi podczas wywołania.

^{dokumentacja: https://www.terraform.io/intro/getting-started/variables.html#from-a-file}

Korzystamy z tej funkcji, aby zapewnić secrets.tfvarsplik przy każdym wywołaniu Terraform. Używamy również skryptu do zawinięcia polecenia, aby jego wywołanie było spójne, a wszyscy członkowie zespołu unikają popełniania tych samych błędów. Opakowanie synchronizuje się .tfstatez S3 przed wykonaniem i wypycha z .tfstatepowrotem do S3 na końcu. Słyszę także o ludziach, którzy robią to samo ze stanem przechowywanym w Konsul, a nawet dodają w konsulacie rodzaj semafora, aby zapobiec uruchomieniu przez Terraform dwóch osób w tym samym czasie.

Gdy unikasz ustawiania wartości domyślnej w variables.tfpliku, zmusza to użytkownika do wprowadzenia wartości. Można go wprowadzić ręcznie lub przy użyciu -var-fileopcji polecenia opisanej powyżej. Brak ustawienia domyślnego dla swoich sekretów jest dobrym sposobem na wymuszenie zmian, które wymagają zmiany w tajemnicach.

secrets.tfvarsPlik jest dowiązaniem symbolicznym do jednego z plików z tajemnic, które nie są przechowywane w kontroli wersji. Mamy kilka, po jednym w każdym środowisku, tak jak secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvarsitp ...

Jeszcze lepszą praktyką byłoby generowanie tych plików tajnych podczas skryptu opakowania na podstawie danych w Vault lub w inny sposób do dzielenia się tajnymi plikami . Ponieważ obecnie, gdy zmienia się format sekretów lub same sekrety, musimy przekazać go zespołowi poza kanałem kontroli wersji - i to nie zawsze działa dobrze, szczerze mówiąc. Ale tajemnice zmieniają się rzadko.

Unikamy obsługi naszych tajemnic przez Terraform. Nawet jeśli uda ci się wstrzyknąć sekrety przez plik var „secrtes.tfvars”, jak wskazano powyżej, te sekrety będą przechowywane w twoim stanie terraform (zdalnym).

Możesz chronić pliki stanu zdalnego za pomocą np. Autoryzacji S3 lub możesz używać plików stanu lokalnego gitignore, ale postanowiliśmy nie polegać na tego rodzaju ochronie.

Jeśli korzystasz z AWS, spójrz na „Właściwy sposób zarządzania sekretami” autorstwa Segment.io na blogu AWS. Zalecamy korzystanie chamberze wszystkich naszych klientów w celu zarządzania tajemnicami. Działa poprzez wykorzystanie magazynu parametrów AWS Systems Manager (SSM) wraz z kluczami KMS. Zapewnia to, że sekrety są szyfrowane w spoczynku (i podczas transportu), zabezpieczone za pomocą IAM, kontrolowane za pomocą CloudTrails i ujawnione tylko jako zmienne środowiskowe w czasie wykonywania.

Po skonfigurowaniu komory i ustawieniu klucza KMS zapisujemy sekrety do magazynu parametrów.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Następnie używaj tych tajemnic, gdy wywołujesz terraform.

chamber exec db -- terraform plan

Zakłada się, że zdefiniowałeś zmienną o nazwie DB_USERiw DB_PASSswoim kodzie HCL.

Na przykład możesz to dodać variables.tf

variable "DB_USER" { }
variable "DB_PASS" { }

UWAGA: chamber zawsze eksportuje zmienne środowiskowe dużymi literami

Udostępniamy moduł terraform, którego terraform-aws-kms-keyzadaniem jest ułatwienie obsługi klucza KMS. Sprawdź naszą szczegółową dokumentację z przykładami korzystania chamberz wielu przestrzeni nazw, a także korzystania z komory z terraformem do zarządzania sekretami. Zobacz nasz pełny przykład odniesienia dla zależności zależności od komory.

Co do tego .tfstate, poruszasz bardzo dobrą kwestię dotyczącą istnienia tajemnic zwykłego tekstu w pliku stanu. Naprawdę nie da się tego obejść. Aby terraform mógł obliczyć zmiany w celu zbudowania planu, musi znać stan „przed” i „po”. Z tego powodu zalecamy używanie zaszyfrowanego segmentu S3 z obowiązkową wersją. Użyj terraform-aws-tfstate-backendmodułu, aby udostępnić segment i tabelę blokującą DynamoDB zgodnie z najlepszymi praktykami.

Aby zaimportować sekrety do plików .tf, możesz również użyć zewnętrznego źródła danych . Może to być np. Skrypt odszyfrowujący twoje sekrety.

Spojrzałem na kilka różnych sposobów, ale szczególnie podobało mi się git-crypt do doraźnego działania przed wdrożeniem czegoś większego, takiego jak Vault.