Audit pipeline secret handling perlu diperketat setelah perubahan perilaku LUKS suspend di Linux memunculkan kembali pertanyaan lama: apa yang sebenarnya terjadi pada secret yang sudah telanjur dimuat ke RAM ketika mesin hanya masuk suspend, bukan mati total?

Jawaban singkatnya: jangan mengasumsikan secret aman hanya karena disk terenkripsi. Enkripsi disk seperti LUKS melindungi data at rest, tetapi tidak otomatis membersihkan credential yang sudah terbuka di memori proses, cache, file sementara, agent SSH, environment variable, atau workspace build saat host memasuki suspend. Untuk laptop developer, runner CI self-hosted, dan host build, ini berarti token registry, SSH key, file .env, atau kredensial cloud bisa tetap terekspos jika kebijakan operasional masih memperbolehkan suspend tanpa kontrol tambahan.

Artikel ini fokus pada audit praktis: area yang harus diperiksa, risiko yang paling relevan untuk pipeline, serta mitigasi yang realistis tanpa bergantung pada asumsi yang keliru tentang enkripsi disk.

Konteks teknis: mengapa perubahan LUKS suspend relevan untuk pipeline

Perubahan perilaku terkait suspend dan LUKS di Linux 6.9 menjadi pengingat bahwa banyak tim mencampuradukkan tiga hal yang berbeda:

  • Enkripsi disk: melindungi data saat media penyimpanan tidak sedang didekripsi.
  • Status memori saat suspend: RAM dapat tetap berisi data aktif, tergantung mode suspend dan konfigurasi sistem.
  • Lifecycle secret aplikasi: secret bisa tersalin ke environment, file sementara, agent, proses turunan, cache build, atau log.

Masalah utamanya bukan semata bug atau perubahan kernel tertentu, melainkan asumsi operasional yang salah: tim mengira host yang tertidur sama aman dengan host yang dimatikan. Dalam konteks CI dan build, asumsi ini berbahaya karena pipeline modern sering memuat banyak secret bernilai tinggi selama beberapa menit saja, tetapi meninggalkan jejak di banyak tempat.

Inti risiko: jika mesin hanya suspend, maka secret yang sudah dipakai untuk login registry, fetch dependency privat, deploy artifact, atau mengakses cloud dapat tetap tersedia sampai proses dibersihkan, token kedaluwarsa, atau mesin benar-benar dimatikan/di-reboot.

Threat model: secret apa saja yang paling berisiko

1. Credential build dan deployment

Ini termasuk token CI, akses ke package registry privat, kredensial object storage, service account, dan kredensial deploy. Secret semacam ini biasanya muncul sebagai:

  • environment variable proses job,
  • file config sementara,
  • cache tool seperti package manager,
  • credential helper untuk Git atau registry.

Jika runner self-hosted sempat suspend di tengah atau setelah job selesai, sisa state ini bisa tetap ada lebih lama daripada yang diperkirakan.

2. Token registry dan package manager

Token untuk Docker registry, npm registry privat, PyPI privat, Maven repository, atau GitHub/GitLab package registry sering tersimpan di:

  • ~/.docker/config.json,
  • ~/.npmrc,
  • pip.conf atau file auth sejenis,
  • credential store eksternal.

Walau file berada di disk terenkripsi, token bisa lebih dulu dimuat ke memori shell, proses daemon, atau helper.

3. SSH key dan agent socket

Pada laptop developer dan host build, secret sering tidak berupa file key saja, tetapi juga agent session yang sudah membuka akses ke repo privat atau bastion. Jika host suspend saat agent masih aktif, serangan tidak selalu membutuhkan pembacaan file key mentah; terkadang cukup memanfaatkan sesi atau socket yang masih berlaku setelah resume.

4. File .env dan konfigurasi lokal

Banyak build script masih menyalin secret ke file .env, file override, atau template konfigurasi lokal. Risiko meningkat jika:

  • file dibuat di workspace persisten,
  • cleanup tidak berjalan saat job gagal,
  • runner menggunakan user yang sama untuk banyak job,
  • workspace dipakai ulang antar pipeline.

Dampak spesifik pada laptop developer, runner CI self-hosted, dan host build

Laptop developer

Pada laptop, masalah utamanya adalah perpindahan konteks keamanan. Mesin bisa berpindah dari kondisi terkendali ke tidak diawasi: ditinggal rapat, dibawa bepergian, atau hilang dalam kondisi suspend. Jika developer sebelumnya menjalankan:

  • docker login,
  • gh auth login,
  • ssh-agent,
  • build lokal yang membaca .env,

maka secret aktif mungkin masih bisa dimanfaatkan setelah resume atau melalui artefak lokal yang belum dibersihkan.

Runner CI self-hosted

Ini kategori paling kritis. Runner self-hosted biasanya memegang akses bernilai tinggi ke:

  • source code privat,
  • secret organisasi,
  • artifact signing,
  • container registry,
  • target deployment internal.

Jika runner dibiarkan suspend otomatis oleh kebijakan hemat daya host, maka beberapa masalah dapat muncul:

  • job berhenti di tengah dengan workspace masih utuh,
  • credential helper tetap login setelah resume,
  • cleanup post-job tidak pernah dieksekusi sempurna,
  • runner kembali aktif dengan secret lama yang belum dirotasi.

Secara operasional, runner seharusnya diperlakukan seperti sistem produksi khusus, bukan laptop yang boleh tidur kapan saja.

Host build non-CI atau server utilitas

Beberapa organisasi punya host build manual untuk release engineering, signing, atau pembuatan image. Sistem semacam ini sering luput dari kontrol CI formal, padahal justru memegang secret sensitif seperti signing key, akses registry release, atau kredensial image base privat.

Checklist audit pipeline secret handling

Berikut checklist audit yang bisa dipakai tim DevOps. Fokusnya bukan hanya apakah disk memakai LUKS, tetapi apakah secret exposure window sudah diminimalkan.

A. Audit kebijakan daya dan suspend

  • Identifikasi semua laptop developer, runner self-hosted, dan host build yang menggunakan full-disk encryption.
  • Verifikasi mode daya yang diizinkan: suspend, hibernate, hybrid sleep, atau shutdown.
  • Pastikan runner CI self-hosted tidak masuk suspend otomatis.
  • Dokumentasikan siapa yang boleh mengubah kebijakan daya pada host build.
  • Pastikan ada kontrol untuk mengunci layar saja tidak dianggap setara dengan membersihkan secret.

B. Audit sumber secret

  • Daftar semua secret yang dipakai selama build: token registry, SSH key, cloud credential, signing key, webhook token, file .env.
  • Petakan dari mana secret berasal: vault, OIDC, environment variable CI, file terenkripsi, credential helper.
  • Tentukan masa hidup masing-masing secret: statis, rotasi berkala, atau short-lived.

C. Audit lokasi secret saat runtime

  • Apakah secret masuk ke environment variable?
  • Apakah tool menulis token ke file home user?
  • Apakah job membuat file sementara yang berisi secret?
  • Apakah ada cache dependency yang menyimpan credential?
  • Apakah shell history, debug log, atau artifact job dapat memuat secret?

D. Audit pembersihan pasca-job

  • Apakah workspace selalu dihapus setelah job selesai, termasuk saat gagal?
  • Apakah sesi login ke registry di-logout atau file auth dihapus?
  • Apakah agent SSH dihentikan setelah job?
  • Apakah container build ephemeral benar-benar dibuang, bukan dipakai ulang?

E. Audit proses unlock disk dan resume

  • Verifikasi bagaimana host di-unlock saat boot dan bagaimana perilakunya saat resume dari suspend.
  • Pastikan tim memahami bahwa unlock saat boot tidak otomatis berarti secret hilang saat suspend.
  • Uji skenario operasional: suspend saat job aktif, suspend setelah job selesai, resume setelah beberapa jam, dan reboot setelah rotasi secret.

Mitigasi utama yang sebaiknya diterapkan

1. Hindari suspend pada runner CI self-hosted

Ini mitigasi paling penting dan paling mudah dibenarkan. Runner self-hosted sebaiknya:

  • tidak memiliki kebijakan auto-suspend,
  • berjalan pada host dedicated atau VM khusus,
  • dimatikan terkontrol hanya lewat maintenance window,
  • menggunakan shutdown atau reprovision, bukan sleep biasa.

Mengapa ini efektif? Karena Anda mengurangi situasi di mana state memori, workspace, dan sesi credential tertinggal dalam kondisi ambigu.

2. Gunakan shutdown atau hibernate sesuai kebijakan, bukan mengandalkan suspend

Untuk laptop developer, kebijakan realistis biasanya bukan larangan total suspend, melainkan klasifikasi:

  • boleh suspend saat tidak ada secret sensitif aktif,
  • wajib shutdown atau hibernate setelah pekerjaan yang memuat kredensial bernilai tinggi,
  • wajib reboot setelah insiden atau setelah penggunaan secret administratif tertentu.

Hibernate pun perlu ditinjau hati-hati dalam konteks organisasi Anda, karena data memori dipindahkan ke storage dan kemudian bergantung pada desain perlindungan disk, swap, dan prosedur unlock. Yang penting adalah jangan menyamakan suspend dengan secret wipe.

3. Rotasi secret setelah perubahan kebijakan atau paparan yang meragukan

Jika Anda baru menyadari runner atau laptop tertentu mungkin sempat suspend dengan secret aktif, lakukan rotasi untuk kredensial yang bernilai tinggi terlebih dahulu:

  • token registry,
  • deploy key,
  • service account,
  • access key cloud,
  • signing credential jika terlibat.

Rotasi tidak memperbaiki desain, tetapi membatasi dampak jika secret pernah terekspos lebih lama dari yang diharapkan.

4. Minimalkan masa hidup credential

Semakin singkat umur secret, semakin kecil dampak bila tertinggal di memori atau file sementara. Praktiknya:

  • gunakan token dengan TTL pendek,
  • ambil secret tepat sebelum dipakai,
  • hapus segera setelah step selesai,
  • hindari secret statis yang berlaku berbulan-bulan.

Trade-off-nya adalah kompleksitas integrasi dan kebutuhan sinkronisasi waktu yang baik, tetapi ini biasanya sepadan untuk sistem build modern.

5. Gunakan OIDC atau short-lived token

Untuk akses cloud atau registry yang mendukung federasi identitas, pilih OIDC atau token jangka pendek ketimbang menyimpan credential statis di runner. Keuntungannya:

  • token diterbitkan per job atau per sesi,
  • scope bisa dibatasi,
  • rotasi lebih sederhana karena tidak ada secret panjang umur yang tertanam di host.

Batasannya: tidak semua tool lama mendukung pola ini, dan Anda mungkin tetap membutuhkan bootstrap credential untuk beberapa komponen. Namun arah umumnya jelas: kurangi keberadaan secret jangka panjang di mesin.

6. Isolasi runner

Jika runner self-hosted harus tetap digunakan, isolasi menjadi kontrol penting:

  • satu runner untuk satu trust boundary,
  • pisahkan runner untuk repo internal dan eksternal,
  • hindari multi-tenant pada host yang sama jika memegang secret sensitif,
  • gunakan VM atau instance ephemeral jika memungkinkan,
  • batasi akses interaktif ke host runner.

Isolasi mengurangi dampak jika secret dari satu job tertinggal setelah suspend, crash, atau cleanup yang gagal.

7. Verifikasi workflow unlock disk

Pastikan prosedur unlock LUKS dan boot chain didokumentasikan dengan jelas. Yang perlu diverifikasi:

  • siapa yang memiliki akses untuk unlock host build,
  • apakah unlock dilakukan manual atau otomatis lewat mekanisme jaringan/TPM sesuai kebijakan internal,
  • apa yang terjadi setelah resume,
  • apakah ada prosedur wajib reboot setelah maintenance tertentu.

Tujuannya bukan sekadar kepatuhan, tetapi memastikan tim tidak salah menafsirkan batas perlindungan disk encryption.

Contoh kebijakan operasional

Berikut contoh kebijakan yang cukup praktis dan bisa diadaptasi.

Kebijakan untuk runner self-hosted

Tujuan: mencegah secret build tertinggal pada host yang masuk suspend atau dipakai ulang secara tidak aman.
  • Runner self-hosted dilarang menggunakan auto-suspend, sleep, atau hibernation.
  • Runner harus berjalan pada host dedicated atau VM terisolasi.
  • Setiap job wajib memakai credential dengan masa hidup sesingkat mungkin.
  • Workspace job harus dihapus setelah selesai, termasuk pada status gagal atau dibatalkan.
  • Token registry, file auth, dan sesi SSH agent harus dibersihkan pada tahap post-job.
  • Host runner yang terindikasi masuk suspend saat job aktif harus dianggap berisiko dan seluruh secret terkait wajib dievaluasi untuk rotasi.

Kebijakan untuk laptop developer

  • Developer tidak boleh meninggalkan mesin dalam status suspend setelah menggunakan credential administratif, deploy key, atau token produksi.
  • Setelah aktivitas sensitif, gunakan shutdown atau reboot sesuai kebijakan tim.
  • Secret jangka panjang tidak boleh disimpan di file .env lokal tanpa enkripsi tambahan dan masa simpan yang jelas.
  • SSH agent dan login registry harus ditutup setelah sesi kerja selesai.

Langkah implementasi yang relevan

Nonaktifkan suspend pada runner Linux

Pendekatan implementasi dapat berbeda antar distribusi dan lingkungan, tetapi prinsipnya sama: pastikan host runner tidak memiliki jalur operasional normal menuju suspend. Anda dapat mengaudit dengan memeriksa konfigurasi power management, timer idle, dan kebijakan desktop atau service yang berjalan pada host tersebut.

Contoh pemeriksaan yang umum dipakai:

systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target
loginctl show-seat
loginctl show-session "$XDG_SESSION_ID"

Perintah di atas berguna untuk investigasi, tetapi detail penonaktifan sebaiknya disesuaikan dengan distribusi, apakah host memakai antarmuka desktop, systemd inhibitors, atau kebijakan enterprise lain. Hindari menyalin konfigurasi buta tanpa uji pada mesin non-produksi.

Bersihkan credential helper dan file auth setelah job

Jika pipeline masih memerlukan login berbasis file, pastikan cleanup eksplisit ada di tahap akhir.

#!/usr/bin/env sh
set -eu

cleanup() {
  rm -f "$WORKSPACE/.env" 2>/dev/null || true
  rm -f "$HOME/.docker/config.json" 2>/dev/null || true
  rm -f "$HOME/.npmrc" 2>/dev/null || true
  ssh-add -D 2>/dev/null || true
}

trap cleanup EXIT INT TERM

# langkah build di sini

Ini bukan jaminan sempurna, karena secret mungkin sempat hidup di memori proses lain atau tertulis di lokasi lain. Namun cleanup eksplisit tetap penting untuk mengurangi jejak yang paling umum.

Gunakan token sementara daripada secret statis

Jika platform CI mendukung OIDC atau penerbitan token per job, ubah alur seperti ini:

  1. job meminta identitas sementara dari platform CI,
  2. penyedia cloud atau layanan target memverifikasi trust policy,
  3. job menerima token sementara dengan scope sempit dan TTL pendek,
  4. token dipakai hanya selama tahap yang diperlukan.

Pola ini bekerja karena host tidak perlu menyimpan secret jangka panjang yang tetap valid setelah resume atau setelah host diambil alih.

Audit checklist yang bisa langsung dipakai

  1. Apakah ada runner self-hosted yang dapat suspend otomatis?
  2. Apakah ada laptop developer yang menyimpan token deploy atau registry jangka panjang?
  3. Apakah build script menyalin secret ke file .env, config, atau workspace persisten?
  4. Apakah token CI memiliki TTL pendek dan scope minimum?
  5. Apakah OIDC atau mekanisme short-lived token sudah tersedia tetapi belum dipakai?
  6. Apakah cleanup post-job selalu berjalan, termasuk saat job gagal?
  7. Apakah ada cache tool atau credential helper yang menyimpan auth di home directory?
  8. Apakah SSH agent tetap aktif setelah build atau deploy?
  9. Apakah prosedur shutdown, hibernate, dan reboot dibedakan jelas dalam SOP?
  10. Apakah tim memahami bahwa LUKS tidak sama dengan pembersihan memori saat suspend?
  11. Apakah host build yang pernah suspend dalam kondisi sensitif sudah ditinjau untuk rotasi secret?
  12. Apakah workflow unlock disk dan akses fisik ke host telah diverifikasi?

Kesalahan umum yang sering terjadi

  • Menganggap full-disk encryption menyelesaikan seluruh masalah secret. Tidak, karena secret runtime bukan hanya masalah disk.
  • Mengandalkan cleanup aplikasi saja. Jika host tidur atau job terputus, cleanup belum tentu berjalan.
  • Menyimpan secret statis di runner self-hosted. Ini memperbesar dampak jika host terekspos.
  • Mencampur runner untuk beban kerja dengan tingkat kepercayaan berbeda. Satu host bersama berarti satu insiden bisa meluas.
  • Tidak menguji skenario resume. Banyak tim menguji boot dan shutdown, tetapi tidak menguji apa yang tersisa setelah suspend-resume.

Penutup

Perubahan dan diskusi seputar LUKS suspend Linux seharusnya mendorong audit yang lebih praktis: bukan mencari rasa aman dari enkripsi disk, tetapi memastikan secret pipeline tidak hidup lebih lama dari yang diperlukan. Untuk tim DevOps, prioritasnya jelas: hindari suspend pada runner, gunakan shutdown atau hibernate sesuai kebijakan, rotasi secret yang berisiko, pendekkan umur credential, pakai OIDC atau short-lived token, isolasi runner, dan verifikasi workflow unlock disk.

Jika Anda hanya mengambil satu tindakan minggu ini, mulailah dari inventaris runner self-hosted dan nonaktifkan suspend pada host yang memproses secret build. Itu biasanya memberi pengurangan risiko paling besar dengan perubahan operasional yang paling masuk akal.