Env Var dan Secret Docker: Build Time vs Runtime

Referensi Dockerfile dari Docker tegas soal dua instruksi yang terlihat seperti konfigurasi. Nilai ENV selalu disimpan di image hasil build dan terbawa ke setiap container yang dijalankan darinya. Nilai ARG tidak tertanam di image dan tidak tersedia di container akhir, tetapi build argument tetap bisa dilihat lewat docker history, dan Docker menyatakan jelas bahwa meneruskan secret lewat keduanya tidak direkomendasikan.

Ketika build benar-benar butuh kredensial, misalnya untuk mengambil package privat, jawaban Docker adalah secret mount: RUN --mount=type=secret membuat nilainya tersedia hanya untuk satu instruksi itu, secara default sebagai file di bawah /run/secrets, dan diberikan lewat baris perintah dengan --secret. Situs ini tidak pernah membutuhkannya. Dockerfile-nya tidak mendeklarasikan ARG, dan satu-satunya baris ENV hanya menyetel nilai tak sensitif seperti port.

Penyisipan yang sama menjadikannya konfigurasi build time. Dokumentasi Next.js mencatat bahwa setelah build, aplikasi tidak lagi merespons perubahan variabel itu, dan bahwa satu image Docker yang dipromosikan ke beberapa environment membekukannya pada nilai saat build. Pencarian dinamis seperti process.env[name] tidak disisipkan sama sekali. Variabel server adalah kebalikannya: ia bisa dibaca saat request ketika rendering dinamis, dan itulah yang membuat satu image bisa berjalan dengan nilai berbeda.

Dua secret situs ini, kunci penyedia AI dan kunci penyedia email, hanya ada di sisi server. Keduanya dibaca dari process.env di dalam route handler API di server, tidak pernah di komponen yang dikirim ke browser. Itulah bentuk yang patut ditiru: identifier publik di build time, secret di runtime di server.

Konfigurasi biasa masuk ke variables, dibaca lewat vars context, dan variabel yang belum diatur mengembalikan string kosong. Itu sebabnya workflow menulis vars.APP_PORT || 3002: nilai kosong jatuh ke default. Aturan praktis di situs ini: apa pun yang berbahaya bila diposting publik adalah secret, selebihnya variable.

GitHub mengevaluasi setiap ekspresi dollar-kurung-kurawal dan mengganti hasilnya sebelum script shell berjalan, sehingga ketika step SSH dieksekusi, heredoc sudah berisi nilai sebenarnya. Bash menyatakan bahwa jika bagian mana pun dari delimiter heredoc diberi tanda kutip, baris-barisnya tidak diekspansi, itulah sebabnya delimiter ditulis 'ENVEOF' dengan tanda kutip: nilai yang mengandung tanda dolar tetap literal dan tidak dianggap variabel.

Ketika satu variabel diatur di beberapa tempat, Compose menyelesaikannya dengan urutan tetap, dari yang tertinggi: docker compose run -e, lalu entri environment atau env_file dengan nilai hasil interpolasi, lalu environment saja, lalu env_file saja, dan terakhir ENV yang tertanam di image. Jadi ENV di Dockerfile hanya berlaku bila Compose tidak mengatur apa pun untuk nama itu. Dengan beberapa entri env_file, file yang belakangan menimpa yang lebih dulu.

Ada trade-off yang jujur di sini. Dokumentasi Compose sendiri menyarankan agar password dan API key tidak diteruskan sebagai environment variable, karena sering tersedia untuk semua proses di container dan sulit dilacak, dan menawarkan Compose secrets, yang di-mount sebagai file di bawah /run/secrets. Situs ini tetap memakai env_file: satu container di satu mesin, file yang hanya bisa dibaca pemiliknya, dan secret yang hanya ada di server. Ketahui bahwa opsi yang lebih kuat itu ada sebelum memilih yang lebih sederhana.

Di luar log: GitHub menyamarkan secret yang tercetak ke log, tetapi dokumentasinya menyebut penyamaran itu tidak dijamin, karena secret bisa diubah bentuknya dengan banyak cara, dan runner hanya bisa menyamarkan secret yang dipakai di job saat ini. Jadi jangan pernah mencetaknya. Jika sebuah secret menghasilkan nilai sensitif lain, daftarkan nilai itu untuk disamarkan juga, dan hindari membungkus beberapa secret dalam satu blob JSON atau YAML; buat satu secret per nilai.

Dan siapkan diri untuk hari ketika satu secret bocor. Panduan hardening GitHub menyarankan pemberian izin minimum, audit cara secret dipakai, dan rotasi berkala untuk memperpendek masa berlaku secret yang bocor. Workflow ini menerapkan aturan pertama pada token-nya sendiri: setiap job hanya mencantumkan izin yang dibutuhkannya.