Belajar Vault - Authentication Methods (Token, Userpass, AppRole, OIDC)

#Pendahuluan

Setelah di episode 9 sebelumnya kita membangun pagar keamanan Vault lewat policies — aturan tentang siapa boleh melakukan apa — pada episode kali ini kita akan membahas sisi lain dari koin tersebut: bagaimana kalian membuktikan siapa kalian. Policies mengatur otorisasi, tapi sebelum ada otorisasi pasti ada autentikasi.

Pertanyaan pentingnya: di dunia kerja nyata, Vault diakses oleh dua tipe pengguna yang sangat berbeda. Di satu sisi ada manusia — engineer yang butuh membaca secret dari laptopnya, yang sudah punya akun SSO perusahaan. Di sisi lain ada mesin — aplikasi, server, dan pipeline CI/CD yang harus mengambil kredensial secara otomatis tanpa ada manusia mengetik password. Mendesain autentikasi yang tepat untuk kedua kelompok ini adalah salah satu keputusan arsitektur paling penting di Vault, dan salah di sini berarti lubang keamanan besar.

Pada episode ini kita akan membedah Authentication Methods: konsep umumnya, tipe-tipe token yang dihasilkan, auth method untuk manusia (userpass, OIDC/SSO), dan auth method untuk mesin (AppRole). Mari mulai.

#Pembahasan Utama

#Konsep Auth Method: Pintu Masuk Menuju Token

Auth method adalah mekanisme yang memverifikasi kredensial yang diberikan client, lalu menerbitkan access token sebagai bukti identitas. Pikirkan seperti ini: Vault adalah gedung yang terkunci. Di setiap pintu masuk ada penjaga (auth method) yang punya cara berbeda untuk memverifikasi kalian — ada yang minta kartu ID (userpass), ada yang memindai face (OIDC SSO), ada yang menerima kartu akses mesin (AppRole). Setelah lolos, kalian diberi lanyard (token) yang menentukan seberapa jauh kalian bisa bergerak di dalam gedung (policy).

Alur lengkapnya:

1. Client mengirim kredensial ke endpoint auth method (misal POST /v1/auth/userpass/login/:username).
2. Auth method memverifikasi kredensial terhadap sumber identitasnya (berkas lokal, LDAP, IdP OIDC, dll).
3. Vault menerbitkan token dengan policy yang ditentukan oleh kredensial tersebut.
4. Client menggunakan token ini untuk seluruh request berikutnya (X-Vault-Token header).

Auth methods bersifat pluggable dan bisa diaktifkan sebanyak yang dibutuhkan dengan path berbeda:

vault auth enable userpass
vault auth enable -path=ldap-auth ldap
vault auth list

Path         Type        Accessor                  Description                Version
----         ----        --------                  -----------                -------
ldap-auth/   ldap        auth_ldap_1a2b3c          n/a                        n/a
token/       token       auth_token_4d5e6f         token based credentials    n/a
userpass/    userpass    auth_userpass_7g8h9i      n/a                        n/a

Perhatikan bahwa token/ (token auth method) selalu aktif dan tidak bisa dinonaktifkan — ini cara "mentah" untuk masuk ke Vault: kalian membawa token yang sudah diterbitkan. Semua auth method lain pada akhirnya juga menghasilkan token, jadi pahami ini: token adalah mata uang universal di Vault, auth method hanyalah mesin penukar uang.

#Token Auth Method dan Empat Tipe Token

Token adalah artefak inti yang mewakili identitas (dari auth method), membawa policy, dan memiliki umur (TTL). Ada empat tipe token yang wajib kalian kenali:

Service Token adalah tipe default yang paling umum. Ia tersimpan di Vault (punya token accessor untuk referensi tanpa mengekspos token asli), bisa di-renew, di-revoke, dan dipantau. Cocok untuk hampir semua kasus.

Batch Token diterbitkan saat kalian membutuhkan throughput tinggi dengan overhead minimum. Ia tidak disimpan di Vault sama sekali — semua informasinya di-encode dalam token itu sendiri — sehingga tidak bisa di-renew dan tidak bisa di-revoke satu per satu (hanya bisa di-revoke lewat policies atau TTL expiry). Konsekuensinya: cocok untuk secret yang short-lived dan volume request sangat besar, tapi jangan dipakai untuk sesuatu yang butuh kontrol lifecycle penuh.

vault token create -policy=app-backend -type=batch -ttl=30m

Periodic Token sangat berguna untuk daemon atau Vault Agent yang berjalan selamanya. TTL-nya diperpanjang otomatis setiap kali digunakan, tanpa batas maksimum. Namun karena tidak pernah kedaluwarsa, ia adalah tanggung jawab besar: kalian harus memastikan token ini aman dan di-revoke saat tidak dibutuhkan.

Orphan Token memutus rantai parental. Biasanya token turunan akan hilang (beserta semua turunannya) jika token induk di-revoke. Orphan token tidak mewarisi "silsilah" ini, sehingga token ini tetap hidup meskipun induknya di-revoke. Ini ideal ketika kalian ingin token yang terisolasi secara penuh dari token yang menerbitkannya.

#Userpass: Auth Method untuk Manusia (Sederhana)

userpass adalah auth method paling sederhana untuk pengguna manusia: Vault menyimpan username dan password hash di dalamnya. Cocok untuk lab, staging, atau tim kecil yang belum punya SSO.

1. Aktifkan dan buat user

vault auth enable userpass

vault write auth/userpass/users/deva \
    password="S3cur3Pa55word!" \
    policies="dev-kv"

2. Login sebagai user

vault login -method=userpass username=deva password=S3cur3Pa55word!

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
 
Key                  Value
---                  -----
token                hvs.CAESIKn...
token_accessor       8X9vR2w4...
token_duration       768h
token_renewable      true
token_policies       ["default" "dev-kv"]
identity_policies    []
policies             ["default" "dev-kv"]

Perhatikan output: token ini punya token_policies: ["default" "dev-kv"] — policy yang kita berikan saat membuat user. Semua operasi token ini diatur oleh policy tersebut, sebagaimana kita pelajari di episode 9.

#OIDC / SSO: Autentikasi Manusia Skala Enterprise

Untuk organisasi nyata, autentikasi manusia sebaiknya diarahkan ke identity provider (IdP) yang sudah ada seperti Okta, Azure AD, GitHub, atau Google. Vault punya auth method oidc (OpenID Connect) yang mengalihkan browser user ke IdP, menerima callback setelah login sukses, dan menerbitkan token Vault.

Konsep pentingnya: Vault tidak pernah melihat password user. Ia hanya menerima identity token yang ditandatangani IdP, memverifikasi signature-nya, lalu memetakan klaim-klaim dari token tersebut ke policy Vault.

Berikut langkah garis besarnya:

vault auth enable oidc

# Contoh minimal config OIDC via CLI
vault write auth/oidc/config \
    oidc_discovery_url="https://login.microsoftonline.com/<tenant>/v2.0" \
    oidc_client_id="<client-id>" \
    oidc_client_secret="<client-secret>" \
    default_role="engineer"
 
# Memetakan klaim IdP ke policy Vault
vault write auth/oidc/role/engineer \
    bound_audiences="<client-id>" \
    allowed_redirect_uris="http://localhost:8250/oidc/callback" \
    user_claim="sub" \
    groups_claim="groups" \
    policies="dev-kv"

vault login -method=oidc role=engineer

Saat perintah di atas dijalankan, Vault membuka browser, kalian login ke IdP perusahaan, dan setelah sukses kalian menerima token Vault. Keuntungan terbesarnya: revocation dan lifecycle akun dikelola oleh IdP — ketika seorang karyawan keluar dari perusahaan, akses Vault-nya otomatis mati ketika akun SSO dinonaktifkan. Tidak ada akun userpass yang ditinggalkan bergentayangan.

#AppRole: Autentikasi Machine-to-Machine

Sekarang kita masuk ke bagian favorit para DevOps: bagaimana aplikasi mengautentikasi diri tanpa interaksi manusia. Jawabannya adalah AppRole — kombinasi dua kredensial:

• RoleID — semacam "username" untuk mesin; sifatnya statis dan boleh disimpan di config.
• SecretID — semacam "password"; sifatnya rahasia, di-generate on-demand, dan biasanya dikirim secara aman (kita bahas pengiriman amannya di episode 13 tentang response wrapping).

Kombinasi RoleID + SecretID menghasilkan token Vault. Ini setara dengan mesin yang menunjukkan kartu akses + PIN.

1. Aktifkan AppRole dan buat role

vault auth enable approle

vault write auth/approle/role/app-backend \
    token_ttl=1h \
    token_max_ttl=24h \
    secret_id_ttl=48h \
    token_policies="app-backend"

Opsi-opsi penting di atas:

2. Ambil RoleID dan generate SecretID

vault read auth/approle/role/app-backend/role-id

vault write -f auth/approle/role/app-backend/secret-id

Key                   Value
---                   -----
secret_id             f7f9b3b6-...
secret_id_accessor    3a4d5c6e-...
secret_id_ttl         48h
secret_id_num_uses     0

3. Login menggunakan kombinasi keduanya

vault write auth/approle/login \
    role_id="<role-id>" \
    secret_id="<secret-id>"

Key                     Value
---                     -----
token                   hvs.CAESILf...
token_accessor          Z6Xb...
token_duration          1h
token_renewable         true
token_policies          ["app-backend" "default"]
identity_policies       []
policies                ["app-backend" "default"]
token_meta_role_name    app-backend

Perhatikan token_duration: 1h — token ini mengikuti token_ttl yang kita set. Untuk aplikasi yang berjalan lama, mekanisme renewal token ini (yang akan kita bahas detail di episode 12) adalah tanggung jawab aplikasi atau Vault Agent.

#Perbandingan Auth Method Secara Ringkas

#Kesalahan Umum dalam Authentication

#Penutup

Pada episode ini kita telah membedah Authentication Methods: konsep bahwa auth method adalah mesin yang menerbitkan token, empat tipe token (service, batch, periodic, orphan) beserta kapan memakainya, autentikasi manusia via userpass dan OIDC/SSO, serta autentikasi machine-to-machine via AppRole dengan RoleID dan SecretID. Kita juga menegaskan larangan memakai root token di produksi dan pentingnya memisahkan mekanisme auth untuk manusia vs mesin.

Inti dari episode ini: autentikasi hanya menentukan siapa, sedangkan apa yang boleh tetap ditentukan policy (episode 9). Keduanya bekerja sama, dan di episode 11 nanti kita akan melihat bagaimana Vault menyatukan keduanya lewat Identity Engine — saat seorang user yang login dari userpass maupun OIDC ternyata adalah entitas yang sama dengan policy terpadu.

Di episode 11 selanjutnya, kita akan membahas Identity Engine (Entities, Aliases & Groups) — bagaimana Vault menyatukan identitas dari berbagai auth method dan mewariskan policy lewat group. Pastikan tetap semangat!