Bagaimana saya bisa mengelola rahasia di .tf dan .tfstate?


46

Saya ingin menggunakan Penyedia MySQL Terraform untuk menyimpan daftar pengguna dan hibah mysql berguna untuk membuat lingkungan pengujian baru. File .tfdan .tfstatekeduanya sepertinya ingin menyimpan kata sandi MySQL dalam plaintext.

Tentang .tf:

Ini adalah pemahaman saya bahwa .tffile hidup dalam kontrol revisi dan dikelola oleh tim. Bagaimana praktik itu berbeda ketika rahasia ada di .tf? Apakah mungkin mengenkripsi nilai-nilai ini sama sekali?

Tentang .tfstate:

Saya dapat menyimpan perangkat .tfstatedengan aman di suatu tempat setelah menjalankan Terraform apply, tetapi akan lebih baik jika use case ini tidak menyimpannya sama sekali?

Jawaban:


22

Terraform mendukung penambahan file tambahan dengan variabel selama doa.

dokumentasi: https://www.terraform.io/intro/getting-started/variables.html#from-a-file

Kami menggunakan fitur itu untuk menyediakan secrets.tfvarsfile pada setiap pemanggilan Terraform. Kami juga menggunakan skrip untuk membungkus perintah sehingga permintaannya konsisten, dan semua anggota tim menghindari keharusan membuat kesalahan yang sama. Pembungkus disinkronkan .tfstatedengan S3 sebelum eksekusi, dan mendorong .tfstatekembali ke S3 di akhir. Saya juga mendengar ada orang yang melakukan hal yang sama dengan keadaan tersimpan di Konsul, bahkan menambahkan semacam semafor di konsul untuk mencegah dua orang memulai Terraform pada saat yang sama.

Ketika Anda menghindari pengaturan nilai default dalam variables.tffile, itu memaksa pengguna untuk memasukkan nilai. Itu bisa dimasukkan secara manual atau menggunakan -var-fileopsi perintah seperti dijelaskan di atas. Tidak menetapkan default pada rahasia Anda adalah cara yang baik untuk memberlakukan perubahan yang membutuhkan perubahan rahasia.

The secrets.tfvarsfile symbolic link ke salah satu file dengan rahasia yang tidak disimpan dalam kontrol versi. Kami memiliki beberapa, satu per lingkungan, seperti begitu secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvars, dll ...

Praktik yang lebih baik lagi adalah membuat file rahasia ini selama skrip wrapper berdasarkan data di Vault atau cara lain untuk membagikan rahasia. Karena saat ini ketika format rahasia berubah, atau rahasia itu sendiri, kita perlu mengkomunikasikannya kepada tim di luar saluran kontrol versi - dan ini tidak selalu bekerja dengan baik, jujur ​​saja. Tapi rahasia memang jarang berubah.



8

Kami menghindari terraform menangani rahasia kami. Sekalipun Anda berhasil menyuntikkan rahasia dengan file var "secrtes.tfvars" seperti yang ditunjukkan di atas, rahasia-rahasia ini akan disimpan dalam keadaan terraform (jarak jauh) Anda.

Anda dapat melindungi file keadaan jauh dengan menggunakan misalnya otorisasi S3, atau Anda dapat gitignore file negara bagian tetapi kami memutuskan untuk tidak bergantung pada jenis perlindungan ini.


2
Juga periksa github.com/hashicorp/terraform/issues/516 yang merupakan tempat mereka melacak masalah rahasia bocor
tststate

6

Jika Anda menggunakan AWS, lihat "Cara yang Tepat untuk Mengelola Rahasia" oleh Segment.io di Blog AWS. Kami menganjurkan penggunaan chamberuntuk semua pelanggan kami untuk mengelola rahasia. Ia bekerja dengan memanfaatkan Toko Parameter Manajer Sistem (SSM) AWS bersama dengan kunci KMS. Ini memastikan rahasia dienkripsi saat istirahat (dan dalam perjalanan), dijamin dengan IAM, dapat diaudit dengan CloudTrails, dan hanya diekspos sebagai variabel lingkungan pada saat dijalankan.

Setelah mengkonfigurasi ruang dan mengatur kunci KMS, kami menulis rahasia ke toko parameter.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Kemudian gunakan rahasia itu ketika Anda menelepon terraform.

chamber exec db -- terraform plan

Ini mengasumsikan Anda telah mendefinisikan variabel yang dipanggil DB_USERdan DB_PASSdalam kode HCL Anda.

Misalnya, Anda dapat menambahkan ini ke variables.tf

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

CATATAN: chamber akan selalu mengekspor variabel lingkungan dalam huruf besar

Kami menyediakan modul terraform yang dipanggil terraform-aws-kms-keyuntuk memudahkan penyediaan kunci KMS. Lihat dokumentasi terperinci kami dengan contoh-contoh cara menggunakan chamberdengan banyak ruang nama serta cara menggunakan ruang dengan terraform untuk mengelola rahasia. Lihat contoh referensi lengkap kami untuk dependensi ruang penyediaan.

Adapun .tfstate, Anda memunculkan poin yang sangat bagus tentang keberadaan rahasia teks biasa di file negara. Benar-benar tidak ada jalan lain untuk ini. Agar terraform menghitung perubahan untuk membangun rencana, ia perlu mengetahui status "sebelum" dan "setelah". Untuk alasan ini, kami sarankan menggunakan ember S3 terenkripsi dengan versi wajib. Gunakan terraform-aws-tfstate-backendmodul untuk menyediakan ember dan tabel penguncian DynamoDB sesuai dengan praktik terbaik.


Ini sangat terkait dengan layanan AWS, yang pertanyaannya tidak sebutkan dan terdengar tidak benar-benar jawaban untuk infrastruktur premis atau cloud lainnya.
Tensibai

@ tensibai, Anda benar. Pertanyaan awal tidak memberikan informasi yang cukup untuk memastikan platform operasi untuk membuat rekomendasi terbaik. Setiap platform akan berbeda tergantung pada kemampuan platform. Pada pengguna prem atau baremetal mungkin ingin mempertimbangkan untuk menggunakan kombinasi Vault dan Terraform Enterprise. Ruang lingkup implementasi itu akan jauh, jauh lebih besar. :)
Erik Osterman

Saya sudah menggunakan AWS Secrets Manager dan tidak ingin menggunakan chamber dan Parameter Store. Apakah mungkin melakukan hal yang sama dengan Manajer Rahasia juga?
red888


2

Saya melihat beberapa cara yang berbeda tetapi saya sangat suka git-crypt untuk melakukan hal adhoc sebelum mengimplementasikan sesuatu yang lebih besar seperti Vault.


2
Kepada siapa yang kalah, tolong jelaskan mengapa.
jottr
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.