Encryption #

Ansible Vault menangani enkripsi data sensitif di dalam playbook dan inventory. Tapi enkripsi dalam konteks Ansible lebih luas dari itu — ada enkripsi transport (SSH), enkripsi data yang dideploy ke server (SSL/TLS sertifikat), dan enkripsi file sensitif di managed node itu sendiri. Memahami layer enkripsi yang berbeda ini memastikan tidak ada celah yang terlewat dalam keamanan otomasi kamu.

Layer Enkripsi dalam Otomasi Ansible #

Layer 1: Enkripsi Transport
  Control Node ──(SSH/TLS)──► Managed Node
  Semua komunikasi dienkripsi oleh SSH — sudah bawaan

Layer 2: Enkripsi Data at Rest (Ansible Vault)
  Repository Git berisi file vault terenkripsi
  Hanya bisa dibaca dengan vault password yang benar

Layer 3: Enkripsi di Managed Node
  File konfigurasi sensitif di server
  Secret yang perlu disimpan di filesystem server

Layer 4: Enkripsi Secret Eksternal
  HashiCorp Vault, AWS Secrets Manager, dll.
  Ansible mengambil secret saat runtime, tidak menyimpannya

Enkripsi Sertifikat SSL/TLS #

Mengelola sertifikat SSL/TLS adalah bagian penting dari configuration management. Private key sertifikat harus dienkripsi dengan Vault sebelum disimpan di repository:

# Enkripsi private key sebelum commit ke Git
ansible-vault encrypt files/ssl/app.example.com.key

# Sekarang file .key terenkripsi dan aman di Git

# tasks/ssl.yml
- name: Deploy sertifikat SSL (file public — tidak sensitif)
  copy:
    src: files/ssl/app.example.com.crt
    dest: /etc/ssl/certs/app.example.com.crt
    owner: root
    group: root
    mode: '0644'

- name: Deploy private key SSL (dari vault — sensitif)
  copy:
    src: files/ssl/app.example.com.key   # File ini dienkripsi dengan vault
    dest: /etc/ssl/private/app.example.com.key
    owner: root
    group: ssl-cert
    mode: '0640'
  no_log: true    # Jangan log konten task ini

no_log: Mencegah Secret Muncul di Output #

Task yang menangani nilai sensitif bisa tidak sengaja menampilkannya di output Ansible — terutama saat menggunakan mode verbose. Gunakan no_log untuk mencegah ini:

# ANTI-PATTERN: password bisa muncul di log jika task gagal
- name: Set password database
  command: psql -U postgres -c "ALTER USER app PASSWORD 'SuperSecret'"
  # Jika task ini gagal, Ansible mungkin menampilkan command lengkap beserta password

# BENAR: sembunyikan output task yang sensitif
- name: Set password database
  command: psql -U postgres -c "ALTER USER app PASSWORD '{{ db_password }}'"
  no_log: true    # Jangan tampilkan apapun dari task ini di output

# no_log juga berlaku untuk module yang menerima nilai sensitif
- name: Buat kredensial database
  postgresql_user:
    name: app_user
    password: "{{ vault_db_password }}"
    state: present
  no_log: true

no_log: true menyembunyikan seluruh output task — termasuk error message. Ini bisa mempersulit debugging. Pertimbangkan untuk menggunakan no_log hanya di production, dan nonaktifkan sementara saat debugging di lingkungan development.

Enkripsi dengan GPG #

Untuk skenario yang butuh enkripsi lebih fleksibel atau berbagi secret dengan orang yang tidak punya akses vault, GPG adalah alternatif yang solid:

# Enkripsi file dengan GPG key tertentu
gpg --recipient [email protected] --encrypt secrets.yml

# Ansible bisa mendekripsi menggunakan GPG saat runtime
ansible-vault decrypt --vault-password-file <(gpg --decrypt vault_pass.gpg)

Mengambil Secret dari External Secret Manager #

Untuk lingkungan produksi yang matang, pertimbangkan mengambil secret dari dedicated secret manager seperti HashiCorp Vault atau AWS Secrets Manager, alih-alih menyimpannya di Ansible Vault:

# Mengambil secret dari HashiCorp Vault menggunakan lookup plugin
- name: Ambil database credentials dari HashiCorp Vault
  set_fact:
    db_password: "{{ lookup('hashi_vault', 'secret=secret/data/myapp/db:password') }}"
  no_log: true

# Mengambil secret dari AWS Secrets Manager
- name: Ambil secret dari AWS
  set_fact:
    api_key: "{{ lookup('amazon.aws.aws_secret', 'myapp/api_key', region='ap-southeast-1') }}"
  no_log: true

Keuntungan external secret manager:

Secret tidak pernah disimpan di repository Git, bahkan dalam bentuk terenkripsi
Audit trail lengkap siapa mengakses secret kapan
Rotasi secret otomatis tanpa perlu mengupdate file vault
Akses berbasis peran yang lebih granular

Audit Trail: Siapa Mengubah Apa #

Enkripsi melindungi dari pembacaan tidak resmi, tapi kamu juga butuh catatan siapa yang mengubah secret. Git history memberikan audit trail dasar:

# Lihat siapa yang mengubah file vault
git log --oneline group_vars/production/vault.yml

# Lihat perubahan di file vault (hanya metadata, konten terenkripsi)
git diff HEAD~1 group_vars/production/vault.yml

Untuk audit trail yang lebih detail di managed node, aktifkan logging di ansible.cfg:

# ansible.cfg
[defaults]
log_path = /var/log/ansible/ansible.log

Ringkasan #

Enkripsi Ansible punya empat layer: transport (SSH), data at rest (Vault), di managed node, dan secret eksternal.
Enkripsi private key SSL/TLS dengan Vault sebelum menyimpannya di Git — file .crt public tidak perlu dienkripsi.
Gunakan no_log: true untuk task yang menangani secret agar nilai sensitif tidak muncul di output atau log.
External secret manager (HashiCorp Vault, AWS Secrets Manager) adalah pendekatan yang lebih matang — secret tidak pernah disimpan di Git, bahkan terenkripsi.
Audit trail melalui Git history dan Ansible log membantu melacak siapa yang mengubah konfigurasi sensitif kapan.
Kombinasi terbaik untuk produksi: Ansible Vault untuk secret yang disimpan di repo + external secret manager untuk secret yang sangat sensitif seperti database root password.

← Sebelumnya: Ansible Vault Berikutnya: Workflow →