Belajar ChromaDB - Authentication & Authorization

#Pendahuluan

Di episode 12 kalian membuka server ke jaringan. Pertanyaan yang segera muncul: siapa saja yang boleh memakainya? Jawaban default ChromaDB mungkin mengejutkan: tidak ada autentikasi. Server yang berjalan tanpa pengaturan auth menerima permintaan dari siapa pun yang bisa menjangkaunya.

Episode 13 membahas dua konsep yang sering tertukar: authentication (membuktikan siapa kalian) dan authorization (apa yang boleh kalian lakukan). Kita akan mengaktifkan token-based auth dan BasicAuth di server, mengonfigurasi klien agar terautentikasi, lalu membahas kontrol akses untuk deployment bersama.

#Kondisi Default: Tanpa Autentikasi

#Risiko Default yang Terbuka

Saat kalian menjalankan chroma run tanpa pengaturan auth, setiap permintaan HTTP diterima. Jika server terekspos ke internet — satu kesalahan konfigurasi port di cloud — siapa pun bisa membaca dan menghapus collection kalian:

curl http://server:8000/api/v2/tenants/default_tenant/databases/default_database/collections

Permintaan curl .../collections tanpa token akan berhasil di server tanpa auth. Ini yang harus dihindari di produksi. Langkah pertama selalu: jangan pernah mengekspos server tanpa auth ke jaringan publik.

#Kebijakan Minimal

Jika auth belum aktif, setidaknya pastikan server hanya bisa diakses dari host aplikasi — batasi dengan firewall di episode 15. Tapi jangan berhenti di situ: episode ini mengajarkan auth yang sesungguhnya.

#Token-Based Authentication

#Mengonfigurasi Server dengan Token

Cara termudah mengaktifkan auth: token static. Server menyimpan daftar token, dan permintaan harus menyertainya. Siapkan file kredensial:

token:rahasia-kuat-2026

Lalu konfigurasi server saat dijalankan:

export CHROMA_SERVER_AUTHN_CREDENTIALS_FILE="/etc/chroma/creds.txt"
export CHROMA_SERVER_AUTHN_PROVIDER="chromadb.auth.token_authn.TokenAuthenticationServerProvider"
chroma run

CHROMA_SERVER_AUTHN_PROVIDER=...TokenAuthenticationServerProvider memberi tahu server memakai token auth dengan kredensial dari file. Token rahasia-kuat-2026 sekarang wajib untuk semua permintaan.

#Klien dengan Token

Klien mengirim token lewat header Authorization: Bearer:

Klien dengan token

client = chromadb.HttpClient(
    host="localhost",
    port=8000,
    headers={"Authorization": "Bearer rahasia-kuat-2026"},
)

chromadb.HttpClient(host="localhost", port=8000, headers={"Authorization": "Bearer rahasia-kuat-2026"}) menyertakan token di setiap permintaan. Tanpa token, permintaan ditolak dengan status 401.

Untuk curl:

curl -H "Authorization: Bearer rahasia-kuat-2026" \
  http://localhost:8000/api/v2/heartbeat

curl -H "Authorization: Bearer rahasia-kuat-2026" menambahkan header auth manual — berguna untuk debugging cepat.

#Basic Authentication

#Alternatif dengan Username dan Password

Selain token, ChromaDB mendukung BasicAuth: username dan password yang dikirim sebagai header Authorization: Basic. Konfigurasi server:

export CHROMA_SERVER_AUTHN_CREDENTIALS_FILE="/etc/chroma/creds.txt"
export CHROMA_SERVER_AUTHN_PROVIDER="chromadb.auth.basic_authn.BasicAuthenticationServerProvider"
chroma run

File creds.txt untuk BasicAuth memuat pasangan username:password per baris:

arman:password-rahasia-1
ci:password-rahasia-2

#Klien BasicAuth

Klien Python mengirim kredensial base64 otomatis:

Klien dengan BasicAuth

import base64
 
kred = base64.b64encode(b"arman:password-rahasia-1").decode()
client = chromadb.HttpClient(
    host="localhost",
    port=8000,
    headers={"Authorization": f"Basic {kred}"},
)

base64.b64encode(b"arman:password-rahasia-1").decode() menyandikan kredensial, lalu headers={"Authorization": f"Basic {kred}"} mengirimkannya. Token dan BasicAuth adalah dua jalur masuk dengan konfigurasi yang hampir sama — pilih sesuai kebiasaan tim kalian.

#Authorization pada Deployment Bersama

#Authentication vs Authorization

Authentication membuktikan siapa — authorization memutuskan boleh apa. Di ChromaDB, authn di atas mengamankan gerbang masuk, tapi secara default setiap pengguna terautentikasi tetap melihat semua collection. Untuk deployment bersama (multi-tenant), pemisahan dilakukan lewat model tenant dari episode 12: setiap tim memakai tenant sendiri, dan server dipisahkan bila perlu kontrol lebih ketat.

#Pola Multi-Tenant yang Direkomendasikan

Pola paling umum dan paling aman saat ini:

1. Pisahkan data per tenant menggunakan create_tenant dan set_tenant.
2. Jalankan server terpisah per tenant jika kebijakan keamanan menuntut isolasi penuh.
3. Enforce authn di setiap server dengan token atau BasicAuth yang berbeda.
4. Batasi jaringan: tiap tenant hanya bisa mengakses servernya sendiri.

Alur client multi-tenant

def buat_client(tenant, token):
    return chromadb.HttpClient(
        host="chroma-" + tenant,
        port=8000,
        headers={"Authorization": f"Bearer {token}"},
    )
 
client_tim_a = buat_client("tim-a", "token-tim-a")
client_tim_b = buat_client("tim-b", "token-tim-b")

buat_client(tenant, token) menghasilkan klien yang terisolasi per tenant. Kombinasi tenant + token + isolasi jaringan adalah garis pertahanan berlapis untuk deployment bersama.

#Penutup

Episode 13 mengubah server kalian dari pintu terbuka menjadi pintu berjaga: memahami bahwa default ChromaDB tidak ada auth, mengaktifkan token-based auth dan BasicAuth di sisi server dan klien, membedakan authentication dari authorization, serta menyusun pola multi-tenant dengan isolasi token dan jaringan.

Inti yang harus dibawa pulang:

• Default ChromaDB tanpa autentikasi — jangan ekspos tanpa mengamankannya.
• Token auth diaktifkan lewat CHROMA_SERVER_AUTHN_PROVIDER dan file kredensial.
• Klien mengirim token di header Authorization: Bearer.
• BasicAuth memakai username dan password dengan encoding base64.
• Authentication membuktikan siapa; authorization menentukan boleh apa.
• Multi-tenant = tenant terpisah + token terpisah + isolasi jaringan.

Di episode 14 selanjutnya kita akan membahas security best practices dan CVE-2026-45829 — celah pre-auth RCE pada server Python FastAPI versi 1.0.0 sampai 1.5.8, alasan server Rust aman, serta mitigasi lengkap: migrasi server, network isolation, zero-trust, dan rutinitas upgrade. Ini episode yang tidak boleh dilewatkan sebelum produksi.