Menangani rahasia di buku pedoman Ansible Anda

Ini akhirnya terjadi. Anda telah bekerja keras dengan Ansible. Anda telah membaca semua artikel hebat, melihat kasus penggunaan, dan bersemangat untuk mulai membangun infrastruktur yang dapat diulang dan mengelola konfigurasi Anda sebagai kode. Hanya ada satu masalah:Anda memiliki file konfigurasi atau tugas yang memerlukan kata sandi atau informasi penting misi lainnya. Anda tahu bahwa Anda tidak boleh menyimpan kata sandi di file plaintext, jadi Anda tidak yakin ke mana harus pergi.

Jangan takut, artikel ini memandu Anda melalui berbagai opsi untuk menangani informasi sensitif di buku pedoman Anda. Baik Anda mencari solusi sederhana, seperti meminta administrator memasukkan sandi, atau opsi yang lebih kompleks, seperti berintegrasi dengan lingkungan pengelolaan rahasia yang ada, Ansible telah membantu Anda.

[ Anda mungkin juga menikmati: Mengungkap Kemungkinan untuk sysadmin Linux ]

Perintah

Jika Anda baru memulai perjalanan Ansible Anda dan menjalankan semua buku pedoman Anda secara manual, maka menggunakan prompt interaktif langsung di buku pedoman Anda adalah solusi yang mudah. Sebuah perintah menyebabkan Ansible menanyakan variabel yang diinginkan kepada pengguna dan menyimpannya setiap kali buku pedoman dijalankan. Pertimbangkan pedoman berikut, yang memastikan bahwa kunci API ada dalam file konfigurasi:

---

- hosts: all
  gather_facts: false
  vars_prompt:
    - name: api_key
      prompt: Enter the API key
  tasks:
    - name: Ensure API key is present in config file
      ansible.builtin.lineinfile:
        path: /etc/app/configuration.ini
        line: "API_KEY={{ api_key }}"

Ketika saya menjalankan buku pedoman ini, Ansible meminta saya di baris perintah menggunakan pesan di parameter prompt:

# ansible-playbook -i inventory.ini main.yml
Enter the API key:

Masukan yang diberikan pada baris perintah akan disimpan di api_key variabel, yang kemudian dapat digunakan dalam permainan seperti variabel biasa lainnya.

Meskipun perintah variabel mudah diterapkan, Anda akan melampauinya jika Anda berinvestasi dalam menggunakan Ansible untuk manajemen konfigurasi penuh. Saat manajemen konfigurasi Anda matang, Anda akan mulai menjalankan buku pedoman secara non-interaktif, dan tidak akan ada orang di depan terminal untuk memasukkan kata sandi. Di situlah Ansible Vault masuk.

Vault yang Memungkinkan

Salah satu kemampuan Ansible favorit pribadi saya adalah Ansible Vault, yang menyediakan kemampuan enkripsi konten asli. Ansible Vault dapat mengenkripsi dan mendekripsi variabel dan file arbitrer, yang berarti Anda dapat menggunakannya untuk melindungi file variabel yang berisi rahasia atau bahkan mengenkripsi seluruh file konfigurasi sensitif. Ansible Vaults memiliki banyak fitur lanjutan, tetapi artikel ini akan berfokus pada dasar-dasarnya.

File YAML standar yang berisi rahasia teks biasa dapat dengan mudah dienkripsi dengan ansible-vault encrypt perintah:

# Plaintext YAML file
$ cat secrets_file.enc
api_key: SuperSecretPassword

# Encrypt the file with ansible-vault
$ ansible-vault encrypt secrets_file.enc
New Vault password:
Confirm New Vault password:
Encryption successful

# Confirm that the file now contains encrypted content
$ cat secrets_file.enc
$ANSIBLE_VAULT;1.1;AES256
38396162626134393935663839666463306231653861336630613938303662633538633836656465
3637353766613339663032363538626430316135623665340a653961303730353962386134393162
62343936366265353935346336643865643833353737613962643539373230616239346133653464
6435353361373263640a376632613336366430663761363339333737386637383961363833303830
34336535623736313031313162353831666139343662653665366134633832646661

Ketika saya menjalankan buku pedoman saya, saya dapat meneruskan file variabel terenkripsi dan memberi tahu Ansible untuk meminta kata sandi saya. Ansible akan mendekripsi file dan menggunakan variabel yang saya definisikan, sama seperti jika saya melewatkan file variabel biasa:

$ cat main.yml
---

- hosts: all
  gather_facts: false
  tasks:
    - name: Ensure API key is present in config file
      ansible.builtin.lineinfile:
        path: /etc/app/configuration.ini
        line: "API_KEY={{ api_key }}"


$ ansible-playbook -i inventory.ini -e @secrets_file.enc --ask-vault-pass main.yml
Vault password:

PLAY [all] ***********************************************************************************

TASK [Ensure API key is present in config file] **********************************************
changed: [localhost]

PLAY RECAP ***********************************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

$ cat /etc/app/configuration.ini
API_KEY=SuperSecretPassword

Saya sebelumnya menjelaskan mengapa menggunakan vars_Prompt tidak ideal dalam lingkungan otomatis karena memerlukan intervensi pengguna manual. Jadi bagaimana perbedaan Ansible Vault? Ansible Vault memungkinkan Anda menentukan file kata sandi yang berisi kata sandi dekripsi untuk Vault:

$ cat password_file 
password

$ ansible-playbook -i inventory.ini -e @secrets_file.enc --vault-password-file password_file main.yml

PLAY [all] ***********************************************************************************

TASK [Ensure API key is present in config file] **********************************************
changed: [localhost]

PLAY RECAP ***********************************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

Pastikan untuk mengatur izin yang sesuai pada file kata sandi dekripsi sehingga hanya pengguna yang menjalankan buku pedoman yang dapat mengaksesnya. Atau, pertimbangkan untuk menggunakan skrip untuk mengakses kata sandi saat runtime dari sistem penyimpanan kata sandi eksternal.

Sekarang file variabel saya dienkripsi, saya perlu cara untuk mengeditnya. Ada dua cara untuk mengedit Ansible Vault terenkripsi. Anda dapat mengedit file di tempat, atau Anda dapat mendekripsi sepenuhnya, mengeditnya, dan kemudian mengenkripsi ulang. Kedua metode ditunjukkan di bawah ini.

# The edit command will launch a text editor, such as vim
$ ansible-vault edit secrets_file.enc 
Vault password: 

# The decrypt command will fully decrypt the file, allowing you to manipulate it how you see fit.
$ ansible-vault decrypt secrets_file.enc 
Vault password: 
Decryption successful

# Notice that the file has been decrypted
$ cat secrets_file.enc 
api_key: SuperSecretPassword

# Don't forget to re-encrypt the file when you're done!
$ ansible-vault encrypt secrets_file.enc 
New Vault password: 
Confirm New Vault password: 
Encryption successful
$ cat secrets_file.enc 
$ANSIBLE_VAULT;1.1;AES256
33373832393864613335393836616538373639353538306462366464303939303838316337336662
6235303936636465366363643761383462356335336239640a356161653166643134663762323136
34616431303434646338343265666135666263633162383662323164396266616638313936303863
3337626365313666630a326465663239653731613637303437666164346531636361653837326166
34396232623138616364393130303036653564643435636639316264636531336161

Menggunakan Ansible Vault untuk rahasia adalah salah satu metode favorit saya untuk menyimpan data sensitif. Manfaat dari pendekatan ini adalah Anda benar-benar dapat menyimpan data sensitif Anda di kontrol sumber, berdampingan dengan buku pedoman biasa Anda. Karena file-file ini dienkripsi, ada sedikit risiko dalam pendekatan ini selama Anda memilih kata sandi yang kuat. Seperti halnya rahasia bersama, ada baiknya untuk sering memutar kata sandi enkripsi. Ansible juga menawarkan beberapa fitur lanjutan untuk Vault, seperti kemampuan untuk memiliki kata sandi yang berbeda untuk Vault yang berbeda. Pastikan untuk meninjau dokumentasi untuk mengetahui cara hebat mengamankan rahasia Anda menggunakan kemampuan asli Ansible.

Menggunakan pengelola kata sandi yang ada

Dua pendekatan sebelumnya adalah murni pendekatan Ansible untuk menangani manajemen rahasia. Namun, banyak organisasi sudah memiliki alat, seperti HashiCorp Vault atau Thycotic Secret Server. Komunitas Ansible telah menulis sejumlah modul khusus untuk berinteraksi dengan jenis sistem ini.

Playbook berikut menggunakan pencarian untuk mendapatkan rahasia dari HashiCorp Vault dan kemudian menggunakan rahasia itu dalam tugas:

---

- hosts: all
  gather_facts: false
  tasks:
    - name: Ensure API key is present in config file
      ansible.builtin.lineinfile:
        path: /etc/app/configuration.ini
        line: "API_KEY={{ lookup('hashi_vault', 'secret=config-secrets/data/app/api-key:data token=s.FOmpGEHjzSdxGixLNi0AkdA7 url=http://localhost:8201')['key'] }}"

Anda dapat menemukan berbagai plugin untuk berbagai alat manajemen rahasia di Ansible Galaxy. Seperti halnya proyek yang didukung komunitas, ada baiknya untuk mengaudit kode sehingga Anda memahami cara menangani data dan rahasia Anda. Anda bahkan mungkin ingin menulis sendiri.

Penggunaan plugin atau modul pencarian sangat cocok untuk organisasi yang sudah memiliki alat manajemen rahasia yang matang dan hanya ingin Ansible menggunakan rahasia dari sistem yang ada ini. Pengorbanan yang jelas adalah pengurangan kesederhanaan:Playbook berjalan sekarang bergantung pada ketersediaan sistem eksternal, dan mengandalkan modul yang didukung komunitas (atau menulis sendiri) dapat memakan waktu.

Catatan tentang pencatatan

Penting untuk diingat bahwa mengenkripsi data saat istirahat (misalnya, dalam Ansible Vault atau sistem rahasia eksternal) tidak berarti bahwa data dilindungi agar tidak dikeluarkan secara tidak sengaja dalam file log Ansible. Jika modul yang Anda panggil mencatat rahasia Anda selama operasi normalnya atau ketika terjadi kesalahan, rahasia itu mungkin terungkap dalam file log Anda. Baik Anda menyimpan log ini di sistem pusat atau hanya menggunakan tampilan keluaran standar default, penting untuk melindungi rahasia Anda dari paparan yang tidak disengaja.

Output di bawah ini adalah dari playbook Ansible yang sama yang telah saya gunakan untuk tutorial ini. Namun, saya telah meningkatkan level debug Ansible dengan -vvv . Perhatikan bahwa rahasia saya (API_KEY=SuperSecretPassword ) secara langsung diekspos dalam output debug. Saya telah membersihkan cuplikan ini sedikit, jadi jangan khawatir jika Anda mencoba ini, dan hasilnya terlihat sedikit berbeda.

TASK [Ensure API key is present in config file] ***********************************************************************************************************************************************
fatal: [localhost]: FAILED! => changed=false 
  ansible_facts:
    discovered_interpreter_python: /usr/bin/python
  invocation:
    module_args:
      attributes: null
      backrefs: false
      backup: false
      content: null
      create: false
      delimiter: null
      directory_mode: null
      firstmatch: false
      follow: false
      force: null
      group: null
      insertafter: null
      insertbefore: null
      line: API_KEY=SuperSecretPassword
      mode: null
      owner: null
      path: /etc/app/configuration.ini
      regexp: null
      remote_src: null
      selevel: null
      serole: null
      setype: null
      seuser: null
      src: null
      state: present
      unsafe_writes: null
      validate: null
  msg: Destination /etc/app/configuration.ini does not exist !
  rc: 257

Ini jelas tidak ideal:Rahasia saya ada di sana, secara kasat mata. Untungnya, Ansible menyediakan parameter no_log untuk tugas yang melindungi data sensitif:

---

- hosts: all
  gather_facts: false
  tasks:
    - name: Ensure API key is present in config file
      ansible.builtin.lineinfile:
        path: /etc/app/configuration.ini
        line: "API_KEY={{ api_key }}"
      no_log: True

Dengan menambahkan parameter ini ke tugas yang berinteraksi dengan data sensitif, output dari tugas yang gagal akan disembunyikan, dan kerahasiaan rahasia saya terjaga:

TASK [Ensure API key is present in config file] ***********************************************************************************************************************************************
fatal: [localhost]: FAILED! => changed=false 
  censored: 'the output has been hidden due to the fact that ''no_log: true'' was specified for this result'

Sebaiknya gunakan no_log pada tugas apa pun yang berinteraksi dengan data sensitif. Anda juga harus menyadari keterbatasannya:Ini tidak akan mencegah logging jika Ansible debugging diaktifkan.

[ Mencari lebih banyak tentang otomatisasi sistem? Mulailah dengan The Automated Enterprise, buku gratis dari Red Hat. ] 

Pemikiran terakhir

Mengelola rahasia dengan benar adalah tantangan awal umum yang dihadapi banyak administrator sistem saat bekerja untuk menerapkan otomatisasi. Dalam artikel ini, saya menjelaskan dan mendemonstrasikan tiga metode berbeda yang dapat Anda gunakan untuk melindungi data sensitif saat menggunakan Ansible di lingkungan Anda. Artikel ini hanya menggores permukaan kemungkinan, jadi pastikan untuk meninjau dokumentasi yang saya tautkan selama diskusi ini. Keamanan adalah pekerjaan semua orang. Anda dapat melakukan bagian Anda sebagai administrator sistem dengan memastikan bahwa Anda memperlakukan data pribadi dengan sensitivitas yang layak dalam alur otomatisasi Anda.