Belajar Observability dengan LGTM Stack - Multi-Tenancy & Access Control

#Pendahuluan

Seiring pertumbuhan organisasi, satu stack observability dipakai banyak tim: tim platform, tim checkout, tim data. Tanpa isolasi, satu tim bisa membaca atau bahkan merusak data tim lain. Di sinilah multi-tenancy dan access control bekerja.

Episode ini membahas model tenancy, cara Mimir, Loki, dan Tempo memisahkan data antar tenant, RBAC di Grafana, serta metode autentikasi yang menjaga pintu masuk.

#Model Tenancy

#Tiga Pendekatan

Organization-based tenancy: setiap organisasi atau unit bisnis menjadi tenant.
Team-based tenancy: setiap tim engineering menjadi tenant.
Environment-based tenancy: dev, staging, dan prod dipisah sebagai tenant.

Model tenant

organization | team | environment

Pola organization | team | environment — pilih yang paling sesuai struktur organisasi kalian.

#Multi-Tenancy di Mimir

#Tenant ID dan Isolasi

Mimir mengidentifikasi tenant lewat header X-Scope-OrgID:

Remote write dengan tenant ID

curl -s -H "X-Scope-OrgID: checkout" -X POST \
  http://localhost:9009/api/v1/push \
  --data-binary 'http_requests_total 1'

Header X-Scope-OrgID: checkout memberitahu Mimir data milik tenant mana. Tanpa header ini, request ditolak saat multi-tenancy aktif.

Per-tenant limits: batas ingestion dan query diatur per tenant.
Per-tenant storage: data blok dipisahkan per tenant di object storage.
Query isolation: query hanya melihat data tenant yang sama.

#Multi-Tenancy di Loki

#Konfigurasi dan Akses

Loki memakai mekanisme serupa dengan X-Scope-OrgID pada push log. Selain itu:

Label-based tenancy: memakai label untuk memisahkan data — bukan pendekatan yang disarankan untuk keamanan ketat.
Access control: query per tenant dibatasi sesuai permission.
Cost allocation: volume log per tenant dihitung untuk alokasi biaya.

Konsep per-tenant limits di Loki

limits_config:
  per_tenant_override_config: /etc/loki/tenants.yaml

File tenants.yaml memuat batas dan pengaturan khusus per tenant — misalnya quota ingestion berbeda untuk tiap tim.

#Multi-Tenancy di Tempo

Tempo mengisolasi trace per tenant:

Tenant isolation: trace hanya terlihat oleh pemilik tenant.
Trace filtering: pencarian dibatasi per tenant.
Resource quotas: batas penyimpanan trace per tenant.

#RBAC di Grafana

#Organisasi, Tim, dan Peran

Grafana mengelola akses melalui hierarki:

Organizations: ruang terpisah penuh untuk unit berbeda.
Teams: kumpulan pengguna di dalam organisasi.
Roles: Admin, Editor, dan Viewer dengan izin berbeda.
Folder permissions: akses per folder dashboard.
Data source permissions: membatasi query ke data source tertentu.
Dashboard permissions: akses per dashboard.

Konsep permission viewer

role: Viewer
permissions:
  - dashboards:read
  - datasources:query

Peran Viewer hanya boleh membaca dashboard dan menjalankan query, tanpa kemampuan mengubah konfigurasi.

#Metode Autentikasi

Grafana dan backend LGTM mendukung banyak metode:

Basic auth: username dan password — cukup untuk internal sederhana.
OAuth2/OIDC: Google, GitHub, GitLab, dan IdP modern.
LDAP: integrasi dengan direktori perusahaan.
SAML: kebutuhan enterprise dan kepatuhan.
API keys dan service accounts: akses mesin untuk automasi.

Info

Prinsip least privilege berlaku di observability: beri akses sesuai kebutuhan. Tim checkout tidak perlu melihat data tim data, dan automasi cukup memakai service account dengan scope terbatas.

#Penutup

Di episode 25 ini kalian memahami model tenancy organisasi, tim, dan environment, mekanisme multi-tenancy Mimir, Loki, dan Tempo dengan tenant ID, RBAC Grafana dengan organisasi, tim, peran, dan permission, serta metode autentikasi dari basic auth hingga SAML.

Inti yang harus dibawa pulang:

Mimir, Loki, dan Tempo memakai tenant ID untuk isolasi.
Per-tenant limits melindungi cluster dari satu tenant.
RBAC Grafana membatasi akses lewat peran dan permission.
Pilih metode autentikasi sesuai kebutuhan dan kepatuhan.
Terapkan least privilege di seluruh stack.

Di episode 26 selanjutnya kita akan membahas cost optimization — menekan biaya metrik dengan kontrol cardinality, biaya log dengan sampling dan retention, biaya trace dengan intelligent sampling, serta optimalisasi biaya infrastruktur. Observability yang bagus harus tetap hemat — inilah seni menyeimbangkan keduanya.