Workflow #

Vault dan enkripsi melindungi data sensitif. Tapi keamanan otomasi tidak hanya soal enkripsi — ia juga soal siapa yang bisa menjalankan apa, dari mana, dan kapan. Workflow yang tidak aman bisa membuat enkripsi yang paling kuat sekalipun menjadi tidak berarti: jika semua orang bisa menjalankan playbook ke production kapan saja tanpa review, nilai keamanan yang diberikan oleh Vault menjadi minimal. Artikel ini membahas workflow yang memastikan otomasi Ansible berjalan dengan kontrol yang tepat.

Prinsip Least Privilege untuk User Ansible #

User yang digunakan Ansible untuk terhubung ke managed node harus punya hak minimum yang diperlukan — tidak lebih:

# roles/common/tasks/ansible-user.yml
# Buat user khusus Ansible dengan hak terbatas

- name: Buat user ansible-deploy
  user:
    name: ansible-deploy
    shell: /bin/bash
    system: false
    state: present

- name: Tambahkan SSH key untuk user ansible-deploy
  authorized_key:
    user: ansible-deploy
    key: "{{ lookup('file', 'files/ansible_deploy.pub') }}"
    exclusive: true     # Hanya key ini yang diizinkan, hapus yang lain

- name: Konfigurasi sudoers dengan hak minimum
  template:
    src: ansible-sudoers.j2
    dest: /etc/sudoers.d/ansible-deploy
    mode: '0440'
    validate: 'visudo -cf %s'

{# templates/ansible-sudoers.j2 #}
# Ansible deploy user — hak minimum untuk operasi deployment
ansible-deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp
ansible-deploy ALL=(ALL) NOPASSWD: /bin/systemctl start myapp
ansible-deploy ALL=(ALL) NOPASSWD: /bin/systemctl stop myapp
ansible-deploy ALL=(ALL) NOPASSWD: /usr/bin/rsync
ansible-deploy ALL=(ALL) NOPASSWD: /usr/bin/pip3 install *
# Larang akses ke operasi yang tidak diperlukan
ansible-deploy ALL=(ALL) !NOPASSWD: /bin/su
ansible-deploy ALL=(ALL) !NOPASSWD: /bin/bash

Pemisahan Akses Berdasarkan Lingkungan #

Satu tim seharusnya tidak bisa mengakses semua lingkungan dengan credential yang sama:

Model Akses yang Direkomendasikan:

Developer:
  ✓ Bisa jalankan playbook ke development
  ✓ Bisa jalankan playbook ke staging (dengan approval)
  ✗ Tidak bisa langsung jalankan ke production

SRE/Ops:
  ✓ Bisa jalankan playbook ke semua lingkungan
  ✓ Punya vault password production
  ✓ Bisa approve deployment production

CI/CD Pipeline:
  ✓ Otomatis deploy ke staging setelah PR merge
  ✓ Deploy ke production hanya setelah manual approval
  ✗ Pipeline tidak punya akses ke vault password production secara langsung

Implementasinya menggunakan SSH key yang berbeda per lingkungan:

# inventory/production/group_vars/all.yml
ansible_ssh_private_key_file: ~/.ssh/ansible_production
ansible_user: ansible-prod-deploy

# inventory/staging/group_vars/all.yml
ansible_ssh_private_key_file: ~/.ssh/ansible_staging
ansible_user: ansible-staging-deploy

Dry Run sebagai Gate Wajib #

Wajibkan --check --diff sebelum setiap deployment ke production:

# Langkah 1: Selalu jalankan dry run dulu
ansible-playbook -i inventory/production/ site.yml --check --diff

# Tinjau output — pastikan hanya perubahan yang diharapkan
# Baru kemudian jalankan sungguhan

# Langkah 2: Jalankan sungguhan setelah dry run ditinjau
ansible-playbook -i inventory/production/ site.yml

Integrasikan ini ke workflow Git:

# .gitlab-ci.yml — dry run otomatis pada setiap MR
ansible-check:
  stage: validate
  script:
    - ansible-playbook -i inventory/production/ site.yml --check --diff
  only:
    - merge_requests

ansible-deploy-staging:
  stage: deploy-staging
  script:
    - ansible-playbook -i inventory/staging/ site.yml
  only:
    - main

ansible-deploy-production:
  stage: deploy-production
  script:
    - ansible-playbook -i inventory/production/ site.yml
  when: manual        # Harus di-trigger manual, tidak otomatis
  only:
    - main

Rotasi Credential #

Credential yang tidak pernah dirotasi adalah risiko keamanan tersendiri — jika bocor, penyerang punya akses selamanya. Buat playbook untuk rotasi credential:

# playbooks/rotate-credentials.yml
---
- name: Rotasi SSH key untuk user deployment
  hosts: all
  become: true
  vars_prompt:
    - name: "new_ssh_key"
      prompt: "Masukkan SSH public key baru"
      private: false

  tasks:
    - name: Tambahkan SSH key baru
      authorized_key:
        user: ansible-deploy
        key: "{{ new_ssh_key }}"
        state: present

    - name: Verifikasi koneksi dengan key baru berhasil
      ping:
      vars:
        ansible_ssh_private_key_file: /path/to/new_key

    - name: Hapus SSH key lama setelah verifikasi berhasil
      authorized_key:
        user: ansible-deploy
        key: "{{ old_ssh_key }}"
        state: absent

Logging dan Audit Trail #

Setiap eksekusi playbook ke production harus tercatat:

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

# Tambahkan task audit di awal setiap playbook production
- name: Log deployment ke audit trail
  local_action:
    module: lineinfile
    path: /var/log/deployments.log
    line: "{{ ansible_date_time.iso8601 }} | {{ lookup('env','USER') }} | {{ inventory_dir | basename }} | {{ playbook_dir | basename }}"
    create: true
  run_once: true

Ringkasan #

• Least privilege: user Ansible hanya boleh punya hak yang benar-benar diperlukan — buat sudoers yang spesifik, bukan ALL=(ALL) NOPASSWD: ALL.
• Pisahkan akses per lingkungan dengan SSH key dan vault password yang berbeda — bocornya credential staging tidak membahayakan production.
• Dry run wajib sebelum setiap deployment production — integrasikan --check --diff ke pipeline CI/CD sebagai gate otomatis.
• Manual approval untuk deployment production di pipeline CI/CD — otomasi boleh, tapi manusia harus menyetujui perubahan ke production.
• Rotasi credential secara berkala — SSH key dan vault password yang tidak pernah dirotasi adalah risiko yang terakumulasi.
• Audit trail melalui Ansible log dan Git history — setiap perubahan ke production harus bisa ditelusuri siapa, apa, dan kapan.

← Sebelumnya: Encryption   Berikutnya: Secret Management →