Belajar Curl - Secure Authentication & Secrets Handling

#Pendahuluan

Di episode 12 kalian mengamankan jalurnya — TLS memastikan request sampai ke server yang benar tanpa bisa dibaca di tengah jalan. Tapi ada celah yang tidak bisa ditutup oleh enkripsi: kredensial yang bocor di sisi kalian sendiri. Password yang tertulis di command line, token yang tersimpan di shell history, atau secret yang tercetak di log CI — semua itu membuat TLS yang sempurna menjadi sia-sia. Seperti brankas dengan pintu baja tapi kuncinya digantung di gagang pintu.

Episode 13 ini adalah tentang secrets handling: ke mana rahasia tidak boleh pergi, ke mana ia harus pergi, dan kebiasaan apa yang membuat kredensial tetap hidup di tempat yang benar.

#Ke Mana Rahasia Bisa Bocor

Sebelum mempelajari solusi, kalian harus tahu musuhnya. Ada empat tempat klasik tempat kredensial bocor:

• Shell history — ~/.bash_history atau ~/.zsh_history merekam setiap perintah yang diketik, termasuk password yang menempel di argumen.
• Process list — isi argumen sebuah proses terlihat oleh semua user lewat ps selama proses itu berjalan. Bukan hanya riwayat shell.
• Log CI/CD — di GitHub Actions atau GitLab CI, command line setiap step tercatat di log pipeline yang bisa dibaca banyak orang.
• File config yang di-commit — kredensial di .curlrc atau file lain yang masuk ke git adalah bom waktu bagi seluruh tim.

# JANGAN lakukan ini — password muncul di ps dan shell history
curl -u arman:sandirahasia https://api.example.com/me

Masalahnya bukan pada curl — curl hanya melakukan apa yang diminta. Masalahnya adalah kalian menaruh rahasia di tempat yang dirancang untuk publik. Solusinya selalu sama: pisahkan kredensial dari perintah.

#Prompt Interaktif: -u Tanpa Password

Cara paling sederhana untuk menjauhkan password dari command line adalah dengan tidak menuliskannya. Jika kalian memberi -u nama pengguna tanpa titik dua dan password, curl memintanya secara interaktif dengan prompt yang tidak menampilkan ketikan:

curl -u arman https://api.example.com/me

Enter host password for user 'arman':

Ketik password-nya, dan perintah itu tidak akan pernah terekam di history maupun muncul di ps. Pola ini sempurna untuk sesi manual di mesin bersama — tapi untuk skrip otomatis, ada cara yang lebih tepat.

#File .netrc dan --netrc

Untuk otomasi berbasis password, curl punya mekanisme klasik: file .netrc — sebuah file yang menyimpan pasangan host dan kredensial, dibaca curl hanya saat diminta. Strukturnya sederhana:

machine api.example.com
login arman
password sandirahasia
 
machine staging.example.com
login arman
password sandi-lain

Untuk memakainya, panggil --netrc (membaca ~/.netrc default) atau --netrc-file untuk file khusus:

curl --netrc-file ~/.api-netrc https://api.example.com/me

Kelebihannya: tidak ada kredensial di command line, curl memilih pasangan yang tepat berdasarkan host, dan file bisa dirotasi tanpa menyentuh skrip. Netrc adalah jawaban untuk "skrip cron yang membutuhkan password tanpa interaksi manusia".

#Environment Variable dan Secret Manager

Untuk token — bukan password — cara paling umum di dunia modern adalah environment variable. Variabel tidak pernah muncul di ps (hanya argumen yang terlihat), dan nilai bisa disuntikkan dari luar tanpa menyentuh kode:

curl --oauth2-bearer "$API_TOKEN" https://api.example.com/me

curl -u "$API_USER:$API_PASS" https://api.example.com/me

Di pipeline CI, nilai-nilai ini berasal dari secret store platform — GitHub Actions menaruhnya di Settings > Secrets, GitLab CI di Settings > CI/CD > Variables. Skrip kalian tetap bersih; rahasia mengalir lewat environment. Untuk lingkungan yang lebih ketat, naikkan level ke secret manager seperti HashiCorp Vault atau AWS Secrets Manager, yang bisa memutar kunci dan mencatat akses — dipanggil saat runtime, bukan disalin ke file.

#Token Tidak Pernah di Shell History

Token adalah kredensial baru dunia API, dan token paling sering bocor lewat kecerobohan yang sama: menempelkannya langsung di command. Perintah seperti curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." akan terekam utuh di shell history — dan siapapun yang membaca history kalian (atau file .bash_history yang bocor) mendapat akses penuh.

Kebiasaan yang benar:

1. Simpan token di environment: export API_TOKEN=eyJhbGciOiJIUzI1NiJ9... lalu pakai $API_TOKEN di perintah.
2. Gunakan --oauth2-bearer (dari episode 10) agar header tersusun otomatis dari variabel.
3. Bersihkan history sesekali, tapi lebih baik mencegah: jangan pernah mengetik token mentah di baris perintah.

# Token dari environment, bukan dari ketikan langsung
curl --oauth2-bearer "$API_TOKEN" https://api.example.com/me

#--trace Hanya untuk Debugging

Pada episode 9 dan 18 kalian mengenal --trace dan --trace-ascii — rekaman byte-demi-byte yang sangat berguna saat debugging. Tapi ingat: trace merekam segalanya, termasuk header Authorization, cookie, dan body. Sebuah file trace adalah kumpulan rahasia yang siap dibaca siapa saja.

# Trace menangkap header Authorization dan cookie — jangan di-commit
curl --trace-ascii trace.txt --oauth2-bearer "$API_TOKEN" \
  https://api.example.com/me

Kebijakan yang sehat: aktifkan --trace hanya saat masalah benar-benar perlu dibedah, hapus file segera setelah selesai, dan jangan pernah menaruh trace di git atau log yang bisa dibaca orang lain. Jika harus berbagi trace untuk laporan bug, redaksi dulu token dan cookie — atau cukup gunakan -v yang lebih ringkas untuk kasus ringan.

#Praktik Terbaik Rahasia

Semua teknik di atas adalah perangkat; berikut kebijakan yang mengikatnya menjadi satu cara kerja:

• HTTPS di mana-mana — kredensial hanya boleh dikirim lewat koneksi terverifikasi; episode 12 menjelaskan alasannya.
• Rotasi token terjadwal — token yang sama dipakai selamanya adalah risiko yang menumpuk. Set expiry dan ganti berkala; secret manager bisa mengotomatiskan ini.
• Least privilege — beri kredensial hanya akses minimum yang dibutuhkan. Token untuk satu scope tidak boleh membuka seluruh API.
• Audit log — catat host, user, dan status code request ber-kredensial, tanpa mencatat kredensial itu sendiri.
• Jangan pernah commit — rahasia di git tidak bisa "dihapus" dengan aman; sejarahnya tetap ada. Berlakukan deteksi dini dengan git-secrets atau pre-commit hook.

#Penutup

Episode 13 melengkapi kalian dengan disiplin pengelolaan rahasia: mengenali empat tempat kebocoran (shell history, process list, log CI, file yang di-commit), memakai prompt interaktif dengan -u tanpa password, mengotomatiskan autentikasi dengan .netrc dan --netrc-file, memisahkan token ke environment variable dan secret manager, membatasi penggunaan --trace untuk debugging saja, serta menerapkan praktik rotasi token dan least privilege.

Inti yang perlu diingat: rahasia bukan soal tidak terlihat, tapi soal tidak pernah ditempatkan di tempat yang salah. Transport yang aman tidak berguna jika kuncinya digantung di depan pintu. Default curl sudah aman; tugas kalian adalah tidak merusaknya demi kenyamanan mengetik.

Di episode 14 berikutnya kita akan berpindah dari keamanan ke kecepatan: protokol modern — HTTP/2 dan HTTP/3 dengan multiplexing-nya, serta WebSocket untuk komunikasi real-time. Sampai jumpa!