Di mana harus memasukkan kata sandi yang dimungkinkan

Kami berencana untuk menggunakan vault yang dimungkinkan dalam proyek kami untuk mencegah kebocoran kata sandi atau kunci di git.

Idenya adalah untuk memasukkan semua data sensitif kita ke dalam file biasa kemudian mengenkripsi file ini dengan kemungkinan-kubah menggunakan kata sandi sebelum mendorong ke git.

Untuk mendekripsi file, kita harus memberikan password vault ke ansible, saya sedang memikirkan 3 kemungkinan:

• Simpan di dalam variabel environment server
• Lulus sebagai opsi untuk perintah playbook yang memungkinkan
• Simpan ke dalam file yang bukan versi.

Apakah ada opsi lain, yang merupakan cara terbaik (dan aman) untuk menyimpan kata sandi yang mungkin-kubah, dokumentasi praktik terbaik yang mungkin dilakukan tidak mengatakan apa-apa tentang hal ini.

Idenya adalah untuk meletakkan semua data sensitif kami [...]

Arti "semua" dalam kalimat ini harus dianalisis dengan sangat hati-hati sebelum mengimplementasikan solusi yang Anda rencanakan.

Vault yang dimungkinkan adalah alat yang sangat berguna, tetapi harus digunakan hanya untuk menyimpan rahasia yang:

1. Diperlukan khusus untuk penyebaran yang mungkin
2. Mudah membuat tidak berguna bagi pemilik yang seharusnya tidak menyadarinya, tetapi yang mungkin secara tidak sah "mengingat" mereka (biasanya karyawan yang tidak naik pesawat)

Poin kedua sangat penting.

Banyak orang, dan kemungkinan seluruh tim DevOps, akan memiliki akses ke kata sandi brankas yang dimungkinkan dan karenanya semua rahasia.

Oleh karena itu, untuk semua rahasia yang disimpan dalam lemari besi, suatu kondisi harus berlaku di mana seseorang atau mesin dengan akses tidak sah ke mereka harus tidak mampu memanfaatkannya jika diinginkan.

Secara konkret, jika Anda menggunakan yang memungkinkan untuk menggunakan basis data dan penggunanya, Anda dapat menyimpan kata sandi di brankas, tetapi Anda harus sangat berhati-hati (dan kemungkinan besar mempertimbangkan solusi lain) jika layanan itu akan tersedia dari Internet dan tanpa perlu otentikasi VPN apa pun!

Pengguna (DevOps) yang terpapar rahasia, harus tidak mampu menggunakan kata sandi "ingat" jika satu penghalang keamanan dikenakan pada mereka (misalnya, akses VPN dibatalkan). Selain itu, akses ke repositori kode sumber (tempat penyimpanan vault) juga harus dicabut sebelum kata sandi diubah.

Dalam kondisi ini, anault vault adalah alat yang sangat berguna.

Mencoba menyimpan rahasia yang dapat digunakan oleh siapa pun atau mesin di Internet dalam brankas akan menjadi kesalahan (misalnya, kredensial pengguna VPN).

Apakah ada opsi lain, yang merupakan cara terbaik (dan aman) untuk menyimpan kata sandi yang dimungkinkan

Dalam kondisi dari paragraf sebelumnya, saya pikir praktik yang baik adalah:

1. Simpan kata sandi vault dalam brankas eksternal yang aman (sesuatu seperti Vault dari HashiCorp atau SaaS apa pun untuk manajemen kredensial)
2. Izinkan akses ke item vault eksternal ke DevOps (mereka akan memerlukan kata sandi untuk pengujian) dan sistem CI / CD atau pengontrol yang memungkinkan

3. Simpan konvensi untuk menggunakan rahasia ! Anda tidak akan dapat meninjau perubahan pada rahasia dan Anda tidak akan dapat menerima variabel yang mungkin dalam file rahasia! Jadi berhati-hatilah sejak awal. Konvensi yang baik adalah memberi nama semua variabel yang disimpan dalam brankas yang dimungkinkan dengan secret_awalan. Ketika Anda akan melihat sesuatu seperti:

   postgres.yml:

   postgres_password: "{{ secret_postgres_password }}"
   

   Anda akan tahu bahwa nilainya disimpan dalam brankas yang dimungkinkan.

Kami berencana untuk menggunakan vault yang dimungkinkan dalam proyek kami untuk mencegah kebocoran kata sandi atau kunci di git.

Karena Anda belum menerapkan apa pun, Anda dapat mempertimbangkan kembali ini. Menggunakan sistem seperti Anault vault memiliki sejumlah kelemahan keamanan:

• tidak ada jejak audit tentang siapa yang telah mengaksesnya
• ketika seorang karyawan pergi, mudah bagi mereka untuk membawa toko rahasia bersama mereka
• ketika seorang karyawan pergi, menghapus akses mereka berarti mengubah kata sandi dan mendistribusikannya ke orang lain
• kata sandi brankas yang dapat dikompromikan dapat selamanya digunakan pada versi lama dari vault, seperti yang disimpan dalam kontrol versi
• rahasia harus statis

Sistem yang berpotensi jauh lebih aman, meskipun lebih kompleks, yang tidak memiliki kelemahan ini adalah menggunakan Hashicorp Vault untuk menyimpan rahasia Anda. Anda kemudian masih dapat menarik nilai darinya semudah dari Vault yang dimungkinkan dengan menggunakan https://github.com/jhaals/ansible-vault .

Anda kemudian harus mengelola otentikasi ke Hashicorp Vault, dan itu adalah pertanyaan kura-kura . Untuk manusia, saya pikir solusi terbaik adalah meminta kata sandi secara berkala dan berakhir token setelah waktu singkat; untuk mesin, untuk menggunakan backend otentikasi AWS atau serupa. Anda tidak pernah dapat sepenuhnya menghilangkan kebutuhan untuk otentikasi di suatu tempat, tetapi Anda dapat mempersulit penyerang untuk mendapatkan akses ke sana.

Sekarang, jika mengatur dan mengelola server rahasia terlalu banyak untuk Anda, maka tentu saja Anda bisa menggunakan Anault vault. Mengapa menyimpan kata sandi di mesin individual? Untuk penggunaan interaktif, Anda bisa langsung meminta kata sandi, dan pengguna dapat menyimpannya di pengelola kata sandi pilihan mereka. ITerm di OS X memiliki manajer kata sandi yang terintegrasi dengan Keychain.app yang membuatnya sangat mudah di sana.

Ini cukup banyak untuk apa kebijakan internal Anda tentang penanganan data sensitif.

Saya ingin memberi tahu Anda pendekatan saya untuk ini dan menjelaskan apa yang saya lihat sebagai pro dan kontra. Saya menyimpan kata sandi Ansible Vault dalam file di mesin kontrol dan memiliki variabel lingkungan yang menunjuk padanya:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

Saya memilikinya di workstation saya (karena saya perlu menguji & mengembangkan buku pedoman), beberapa rekan memilikinya juga, dan tentu saja kita memilikinya di mesin kontrol Ansible utama.

Pro:

• tidak di lokasi / repositori bersama (ini adalah file yang bukan versi seperti yang Anda katakan)
• seseorang tidak perlu mengetahui kata sandi brankas Anda untuk menjalankan permainan (ini dengan syarat Anda memiliki alat CI, misalnya Jenkins, tempat Anda dapat dengan mudah meluncurkan buku pedoman)

Kekurangan:

• tidak mudah untuk memutar kata sandi
• setiap orang yang bekerja pada buku pedoman Anda harus memilikinya di stasiun kerjanya

Kontra memang memiliki mitigasi, tetapi sekali lagi terserah pada kebijakan dan aturan yang telah Anda adopsi dalam operasi Anda sehari-hari.

Lihatlah proyek ini untuk mengelola kata sandi enkripsi terenkripsi kubah Anda yang memungkinkan https://github.com/Smile-SA/ansible-vault-manager

Ini menangani beberapa platform penyimpanan keyring dengan plugin (untuk saat ini hanya AWS SSM yang diimplementasikan). Selain itu, integrasi dengan proyek Ansible saat ini sangat mudah ...