Belajar OpenTofu - Disaster Recovery (DR) & Encrypted State Recovery

#Pendahuluan

Di episode 18 sebelumnya kita membahas deteksi drift dan remediasi otomatis, memastikan infrastruktur selalu kembali ke kondisi yang dideklarasikan. Namun ada skenario yang lebih menakutkan daripada drift: state file yang tidak bisa dibaca sama sekali. State terenkripsi yang kehilangan kuncinya bukan lagi masalah kecepatan pemulihan — melainkan masalah apakah masih bisa pulih.

Di episode 19 kali ini, kita akan membahas Disaster Recovery & Encrypted State Recovery. Kita akan menelusuri prosedur pemulihan state terenkripsi ketika KMS key atau passphrase bermasalah, dan merancang strategi backup serta versioning menggunakan S3 dan GCS. Ini adalah episode tentang ketenangan pikiran: memastikan keadaan terburuk tidak pernah menjadi akhir segalanya.

#Kenapa State adalah Aset Paling Berharga

Di episode 5 kita belajar bahwa state adalah "inventaris" yang menghubungkan kode HCL dengan resource nyata di cloud. Tanpa state, OpenTofu tidak lagi tahu resource mana yang sudah ada — dan sebuah tofu apply yang ceroboh bisa membuat cluster, bucket, atau database dibuat ulang dari nol, bahkan dihancurkan.

Dengan fitur native client-side encryption yang kita bahas di episode 6, state disimpan sebagai ciphertext. Ini sangat aman terhadap pencurian, tetapi membawa konsekuensi: keamanan state sekarang bergantung pada kemampuan mendekripsi. Kunci yang hilang sama artinya dengan data yang hilang.

#Skenario 1: KMS Key Bermasalah

Misalkan kita mengenkripsi state menggunakan AWS KMS:

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/abc123"
    }
 
    method "aes_gcm" "main" {
      keys = key_provider.aws_kms.main
    }
 
    state {
      method = method.aes_gcm.main
    }
  }
}

KMS key bisa bermasalah karena berbagai alasan: dihapus secara tidak sengaja, dinonaktifkan, dipindah region, atau IAM role tidak lagi memiliki izin decrypt. Gejala yang muncul biasanya error ketika menjalankan tofu plan atau tofu state pull.

Langkah pemulihan:

1. Diagnosis — periksa status key di konsol KMS: apakah enabled, disabled, atau pending deletion.
2. Pulihkan key — re-enable atau batalkan penghapusan key dari KMS. Pastikan IAM role memiliki izin kms:Decrypt.
3. Verifikasi region — pastikan kms_key_id menunjuk ke region dan account yang benar.
4. Uji akses — jalankan tofu state pull untuk memastikan state bisa didekripsi.
5. Verifikasi plan — jalankan tofu plan dan pastikan tidak ada perubahan tak terduga, menandakan state terbaca sempurna.

#Skenario 2: Passphrase PBKDF2 Hilang

Untuk environment yang lebih sederhana, kita mungkin menggunakan key provider pbkdf2 dengan passphrase:

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }
 
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
 
    state {
      method = method.aes_gcm.main
    }
  }
}

Passphrase bisa dibaca dari environment variable TF_OPENTOFU_STATE_PASSPHRASE sehingga tidak pernah tertulis di kode. Masalah muncul ketika passphrase hilang atau salah ketik — dan karena derivasi kunci bersifat deterministik, satu karakter yang salah membuat seluruh state tidak terbaca.

Untuk meminimalkan risiko ini, simpan passphrase di secret manager (Vault, AWS Secrets Manager, atau GCP Secret Manager), buat salinan cadangan di lokasi terpisah, dan uji pemulihan secara berkala. Aturan praktisnya: jika tidak ada orang kedua yang bisa merekonstruksi passphrase, itu bukan backup.

#Prosedur Pemulihan Bertahap

Ketika terjadi insiden, ikuti prosedur berikut secara berurutan — jangan lompat langsung ke rekonstruksi:

1. Tetap tenang dan jangan apply — perintah tofu apply dengan state yang bermasalah bisa memperparah keadaan.
2. Coba dekripsi dengan key yang benar — perbaiki izin, region, atau passphrase seperti skenario di atas.
3. Manfaatkan versioning — jika key lama benar-benar hilang, tarik versi state sebelumnya dari backup S3/GCS yang masih bisa didekripsi dengan key lama, lalu dekripsi ulang.
4. Gunakan fallback untuk rotasi — OpenTofu menyediakan mekanisme fallback sehingga key baru bisa membaca state yang ditulis dengan key lama.
5. Dokumentasikan dan evaluasi — catat root cause dan perkuat prosedur agar tidak terulang.

#Rotasi Kunci dengan Fallback

OpenTofu mendukung rotasi key tanpa kehilangan akses ke state lama melalui atribut fallback. Ketika key lama bermasalah, kita kenalkan key baru sebagai method utama dan key lama sebagai fallback:

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/new-key"
    }
 
    key_provider "aws_kms" "old" {
      kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/old-key"
    }
 
    method "aes_gcm" "main" { keys = key_provider.aws_kms.main }
    method "aes_gcm" "old"  { keys = key_provider.aws_kms.old }
 
    state {
      method   = method.aes_gcm.main
      fallback = method.aes_gcm.old
    }
  }
}

Dengan konfigurasi ini, OpenTofu menulis state baru dengan key baru namun tetap bisa membaca state lama selama key lama tersedia sebagai fallback. Setelah semua state di-re-encrypt ke key baru, fallback bisa dihapus. Inilah cara merotasi kunci tanpa downtime — sama seperti mengganti kunci pintu tanpa mengunci penghuni di dalam.

#Strategi Backup & Versioning

Recovery tidak akan pernah berhasil tanpa backup yang benar. Dua strategi utama yang digunakan di dunia nyata:

#Versioning di AWS S3

Bucket yang menyimpan state harus mengaktifkan versioning — sehingga setiap versi state (termasuk yang terhapus) tetap tersimpan:

resource "aws_s3_bucket" "state" {
  bucket = "org-opentofu-state"
}
 
resource "aws_s3_bucket_versioning" "state" {
  bucket = aws_s3_bucket.state.id
  versioning_configuration {
    status = "Enabled"
  }
}
 
resource "aws_s3_bucket_server_side_encryption_configuration" "state" {
  bucket = aws_s3_bucket.state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

Bucket versioned menjadi mesin waktu bagi state. Jika state terbaru rusak atau tidak terbaca, kita bisa mengambil versi sebelumnya.

#Versioning di GCP GCS

Pendekatan yang sama berlaku di GCP menggunakan google_storage_bucket dengan versioning:

resource "google_storage_bucket" "state" {
  name     = "org-opentofu-state"
  location = "ASIA-SOUTHEAST2"
 
  versioning {
    enabled = true
  }
}

#Pengujian Pemulihan

Backup yang tidak pernah diuji bukanlah backup. Jadwalkan latihan pemulihan berkala — misalnya kuartalan — dengan langkah:

1. Ambil versi state lama dari bucket versioning.
2. Pulihkan ke environment staging.
3. Verifikasi tofu plan berjalan tanpa error.
4. Catat waktu pemulihan dan evaluasi target RTO.

Latihan ini memastikan seluruh prosedur di atas benar-benar berfungsi ketika dibutuhkan, bukan hanya terlihat rapi di dokumen.

#Penutup

Pada episode 19 ini, kita telah membahas Disaster Recovery & Encrypted State Recovery. Kita sudah belajar prosedur pemulihan ketika KMS key atau passphrase bermasalah, teknik rotasi key dengan fallback, serta strategi backup dan versioning di S3 dan GCS.

Key takeaway:

• State terenkripsi hanya seaman kuncinya; kunci yang hilang berarti data hilang.
• Diagnosa KMS: cek status key, region, dan izin kms:Decrypt.
• Passphrase PBKDF2 bersifat deterministik — satu karakter salah membuat state tidak terbaca.
• tofu state pull adalah alat verifikasi cepat untuk menguji kemampuan dekripsi.
• Atribut fallback memungkinkan rotasi key tanpa downtime.
• Aktifkan versioning di S3 dan GCS sebagai mesin waktu bagi state.
• Backup tanpa uji pemulihan bukanlah backup.

Disaster recovery adalah pembuktian bahwa sistem kalian tahan terhadap keadaan terburuk. Di episode 20 nanti — episode pamungkas — kita akan menggabungkan seluruh kemampuan yang telah kita pelajari dari episode 0 hingga 19 ke dalam satu Complete Production-Grade Enterprise OpenTofu Architecture. Sampai jumpa!