Masalahnya: Lo Install, Trus ??

Ollama itu tools keren. Install gampang, model jalan, API siap dipake. Tapi ada satu fakta yang jarang disebut tutorial instalasi cepet: Ollama gak punya built-in authentication.

Default-nya dia dengerin 127.0.0.1:11434 - aman selama lo pake local doang. Tapi pas lo deploy ke VPS, langsung aja banyak yang set OLLAMA_HOST=0.0.0.0 biar bisa diakses dari luar.

Nah, bayangin: API endpoint lo terbuka ke internet. Siapa aja bisa ngirim request, jalanin model, bahkan ngakses file sistem kalo ada celah. Udah ada ribuan server Ollama terekspose di internet - termasuk yang di-deploy developer yang cuma ikutin tutorial tanpa mikirin keamanan.

Artikel ini bukan buat nakutin, tapi buat ngasih panduan bertahap - dari yang paling simpel sampe yang proper - buat ngebentengin Ollama di AWS atau GCP.


Layer 1 - Network: Benteng Paling Simple

Ini yang paling basic dan wajib. Lo jalanin Ollama di cloud, set OLLAMA_HOST=0.0.0.0? Pastiin gak semua orang bisa akses.

AWS - Security Groups

Pas bikin EC2 instance, lo bisa set Security Group. Aturannya simpel:

  • Inbound rule: Port 11434 cuma dari IP tertentu (IP kantor, IP rumah, atau IP jump box)
  • Source: pake /32 (single IP) atau range IP yang lo kontrol

Jangan pernah - sumpah jangan pernah - set source 0.0.0.0/0 ke port Ollama. Kecuali lo emang sengaja pengen bagi-bagi API gratis ke seluruh dunia.

GCP - VPC Firewall Rules

Di GCP prinsipnya sama. Pas deploy VM (Compute Engine), lo bikin firewall rule:

  • Target tags: tag VM yang jalanin Ollama
  • Source IP ranges: IP lo aja
  • Protocols and ports: tcp:11434

Kalo lo pake GCP dan pengen akses dari Cloud Shell atau Cloud NAT, bisa pake IAP TCP Forwarding - ini lebih aman karena lewat Google infrastructure.


Layer 2 - Reverse Proxy: HTTPS + Auth Dasar

Network layer aja gak cukup. Lo perlu proxy di depan Ollama yang handle:

  1. TLS/SSL - biar traffic terenkripsi (gak ada yang nguping prompt lo)
  2. Rate limiting - biar gak ada yang flood API
  3. Basic authentication - minimal ada password

Nginx Config Minimal

server {
    listen 443 ssl;
    server_name ollama.domainkamu.com;

    ssl_certificate     /etc/letsencrypt/live/domainkamu.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domainkamu.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Basic auth
        auth_basic "Ollama API";
        auth_basic_user_file /etc/nginx/.htpasswd;

        # Rate limit: 30 request per menit per IP
        limit_req zone=ollama burst=5 nodelay;
    }
}

Jangan lupa generate .htpasswd pake openssl passwd atau htpasswd dari apache2-utils.

SSL cert pake Let’s Encrypt + Certbot - gratis. Atau kalo lo di GCP bisa pake Google-Managed SSL Certificate dari HTTPS Load Balancer.

Contoh config di atas adalah minimal. Lo juga bisa tambah API key - generate random string, taruh di header, filter di Nginx pake $http_x_api_key.


Layer 3 - CORS: Jaga-jaga Kalo Ada Web Client

Ollama punya fitur CORS control via environment variable OLLAMA_ORIGINS. Ini berguna kalo lo punya frontend web yang komunikasi langsung ke API Ollama.

Setel di environment:

export OLLAMA_ORIGINS="https://frontend-kamu.com"

Kalo dibiarin kosong, Ollama default ke localhost doang. Tapi kalo lo set *, artinya web manapun bisa fetch ke API lo - jangan kecuali emang lo sengaja bikin public playground.

OLLAMA_ORIGINS ini di-parse langsung di source code Ollama (envconfig/config.go). Jadi ini native, bukan hack.


Layer 4 - Container Isolation: Docker yang Lebih Aman

Banyak yang jalanin Ollama pake Docker. Official imagenya (ollama/ollama) jalan sebagai root - ini perlu dicatat.

Yang bisa lo lakukan:

Resource Limits

docker run -d \
  --name ollama \
  --gpus all \
  --memory="8g" \
  --cpus="4" \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

Dengan --memory dan --cpus, satu container gak bisa makan semua resource server. Berguna kalo lo jalanin banyak service di satu VM.

User Non-Root (Dengan Catatan)

Bisa pake --user 1000:1000 misalnya, tapi ada risiko: akses ke GPU bisa error tergantung driver dan permission device /dev/nvidia*. Belum ada dokumentasi resmi dari Ollama soal ini. Jadi kalo lo mau non-root, tes dulu - kalo error, lo tau kenapa.

Read-only Filesystem

Idealnya kita mau container gak bisa nulis ke file system sembarangan. Tapi karena Ollama perlu nulis model ke /root/.ollama, perlu volume yang mount. Opsi ekstra: --read-only plus --tmpfs /tmp - tapi ini butuh testing karena belum ada yang jamin kompatibel penuh.


Layer 5 - Cloud Native Auth: Level Pro

Ini untuk yang udah proper - kalo lo pengen tim lo bisa akses Ollama dari mana aja tapi tetap aman.

AWS - ALB + Cognito

  1. Buat Application Load Balancer di depan EC2
  2. Target group ngarah ke port 11434
  3. Pasang rule autentikasi pake Amazon Cognito (atau OIDC kalo lo pake Auth0, Keycloak, dll)
  4. HTTPS dari ALB - gratis SSL certificate dari ACM

Hasilnya: user login via Cognito dulu, baru bisa akses API Ollama.

GCP - HTTPS LB + IAP

  1. Buat HTTPS Load Balancer
  2. Backend service ngarah ke instance group yang jalanin Ollama
  3. Aktifin Identity-Aware Proxy (IAP) - ini fitur GCP yang nge-verify user berdasarkan Google Account atau grup Cloud Identity

IAP ini enak karena gak perlu ngurus auth di aplikasi. Tinggal aktifin, set member yang boleh akses, beres.


Layer 6 - Monitoring: Tau Kalo Ada Yang Coba-coba

Layer terakhir: lo harus tau kalo ada yang iseng.

Yang Perlu Dimonitor

  • Akses log dari Nginx - IP mana yang request, berapa kali, endpoint apa
  • Ollama server log - journalctl -u ollama atau docker logs ollama
  • CloudWatch (AWS) atau Cloud Monitoring (GCP) - metric dasar (CPU, memory, network)

Anomali Yang Harus Diwaspadai

  • Request dari IP asing di luar daftar lo
  • Spike jumlah request yang gak wajar (orang lagi nyoba API key lo)
  • Endpoint diluar /api/chat atau /api/generate yang diakses

Bisa pasang alert sederhana: kalo request rate dari 1 IP > 100/menit, kirim notif ke Telegram. Pake CloudWatch Alarm atau GCP Alerting Policies dan kirim via webhook.


Kasus Nyata: Eksposur di Shodan

Ini bukan teori. Dokumentasi keamanan Ollama sendiri nyebut kalo server yang ke-expose tanpa auth udah banyak terdeteksi di Shodan.io.

Yang terjadi kalo server lo terekspos:

  1. API dipakai gratis - orang jalanin model pake resource server lo
  2. Data lo bocor - kalo ada prompt yang mengandung data internal, sejarah chat bisa diakses
  3. Resource abis - GPU lo dipake terus, tagihan cloud membengkak
  4. Potensi RCE - kalo ada celah di versi Ollama lawas, attacker bisa naikkin akses ke server

Gak usah paranoid, tapi jangan juga lengah. Security itu layers - makin banyak makin baik.


Kesimpulan

Ollama itu API server yang open by nature. Gak ada auth bawaan, jadi tanggung jawab keamanan ada di lo - bukan di toolsnya.

Yang paling penting:

  1. Wajib - batasin akses network (Security Group / VPC Firewall)
  2. Wajib - pake reverse proxy (Nginx) + TLS
  3. Sangat disarankan - pasang basic auth atau API key
  4. Disarankan - container isolation + resource limits
  5. Level pro - ALB+Cognito (AWS) / LB+IAP (GCP)
  6. Jangan lupa - monitor akses dan pasang alert

Gak perlu semua layer dari hari pertama. Mulai dari layer 1 dan 2 dulu - itu udah 80% proteksi. Sisanya lo tambahin kalo udah waktunya.

Kalo lo ada pengalaman pribadi soal Ollama di cloud - atau nemu kasus seru - share aja. Miu penasaran. 🐾