Belajar OpenTelemetry - Security: TLS, Auth & Sensitive Data

#Pendahuluan

Semakin banyak data dikirimkan, semakin menarik pula pipeline telemetry sebagai target. Bayangkan isinya: alur request internal, metadata service, dan kadang — jika hygiene kode buruk — data sensitif pelanggan. Episode 16 mengamankan seluruh jalur itu: enkripsi (TLS/mTLS), autentikasi (siapa yang boleh kirim), dan redaksi (apa yang boleh keluar).

Mengapa penting? Karena telemetry adalah data produksi yang sama nilainya dengan database. Backend observability yang terbuka tanpa auth adalah lubang kebocoran yang jarang disadari — dan PII di dalam trace adalah tanggung jawab hukum, bukan sekadar best practice.

#TLS: Enkripsi di Jaringan

Lalu lintas telemetry sebaiknya selalu lewat TLS — terutama saat melewati jaringan publik atau antar-region. Di collector, TLS dikonfigurasi per receiver/exporter:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /etc/otel/tls/server.crt
          key_file: /etc/otel/tls/server.key
          client_ca_file: /etc/otel/tls/ca.crt   # untuk mTLS

Pada sisi SDK, aktifkan TLS dengan memakai endpoint https:// atau tls: di config exporter:

from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
 
exporter = OTLPSpanExporter(
    endpoint="https://collector.internal:4317",
    credentials=ssl_channel_credentials(),
)

#mTLS: Mutual Authentication

TLS biasa hanya mengautentikasi server ke client. Untuk lingkungan internal yang ketat, mTLS mengautentikasi kedua arah — client juga harus menunjukkan sertifikat yang valid:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /etc/otel/tls/server.crt
          key_file: /etc/otel/tls/server.key
          client_ca_file: /etc/otel/tls/ca.crt
          require_and_verify_client_cert: true

Dengan require_and_verify_client_cert: true, hanya client yang punya sertifikat dari CA kalian yang bisa mengirim telemetry — jaringan internal yang tidak membocorkan data ke siapa pun.

#Autentikasi: Header & Extension

Untuk lingkungan yang tidak memakai mTLS, autentikasi dilakukan lewat header HTTP/gRPC metadata.

#Header Auth (Bearer)

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: basicauth/server
 
extensions:
  basicauth/server:
    htpasswd:
      inline: |
        user1:$2y$10$...

Extension basicauth, bearertokenauth, dan oauth2clientcredential adalah tiga cara paling umum. Yang menarik: autentikasi dipasang sebagai extension dan dirujuk di auth.authenticator — memisahkan mekanisme auth dari konfigurasi pipeline.

#OAuth2 Client Credential (untuk Cloud)

Saat collector mengirim ke observability SaaS (seperti Grafana Cloud atau vendor OTLP), biasanya butuh OAuth2 client credentials:

extensions:
  oauth2clientcredential:
    client_id: ${env:OTEL_CLIENT_ID}
    client_secret: ${env:OTEL_CLIENT_SECRET}
    token_url: https://auth.vendor.com/oauth2/token
 
exporters:
  otlp/vendor:
    endpoint: https://otlp.vendor.com:443
    auth:
      authenticator: oauth2clientcredential

#Best Practice Hosting Collector

Saat menempatkan collector di produksi:

• Jangan ekspos port OTLP ke internet — collector internal sebaiknya hanya menerima dari range network terpercaya (VPC, service mesh, atau mTLS).
• Pisahkan network agent vs gateway — agent di node hanya bicara ke gateway; gateway tidak diakses aplikasi.
• Jalankan sebagai user non-root — kurangi dampak bila collector dikompromi.
• Perbarui versi collector — collector rilis sering; patch keamanan harus diikuti dengan terkontrol.
• Audit config — pastikan tidak ada token hardcoded di file config yang masuk git.

#configopaque: Menandai Nilai Sensitif

Atribut configopaque memberi tahu collector bahwa sebuah nilai adalah secret — sehingga tidak dicetak di log konfigurasi saat level debug. Contoh:

extensions:
  bearertokenauth:
    token:
      ${env:OTEL_TOKEN}  # dari env, aman
 
receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: bearertokenauth

Saat config di-log (misal saat --validate atau debug), nilai dengan configopaque akan muncul sebagai <opaque>, bukan nilai aslinya.

#Redaksi PII di Pipeline

Selain redaction processor (episode 12), dua lapis perlindungan tambahan:

1. Di aplikasi — jangan pernah menaruh PII sebagai attribute sejak awal; cukup identitas anonim.
2. Di collector — redaction processor sebagai jaring terakhir, plus filter untuk membuang log yang tidak perlu.

Gunakan OTTL transform processor untuk redaksi lebih presisi:

processors:
  transform/redact:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - delete_key(attributes, "user.email")
          - replace_pattern(attributes["user.phone"], "[0-9]", "*")

#Common Pitfalls

• Collector tanpa TLS di jaringan publik — telemetry dikirim plain text; semua orang bisa membaca.
• mTLS diaktifkan tapi SDK belum punya client cert — koneksi ditolak diam-diam; uji endpoint dengan grpcurl dulu.
• Token di config bukan env var — bocor ke git dan log; selalu ${env:...}.
• Auth hanya di satu arah — koleksi dari SDK diamankan, tetapi ekspor ke backend vendor tidak; amankan keduanya.
• Redaksi dihafal sebagai pengganti hygiene kode — PII tetap pernah melewati jaringan; filter sedekat mungkin ke sumber.

#Penutup

Pada episode 16 ini, kalian telah mengamankan seluruh jalur telemetry.

Inti yang harus dibawa pulang:

• TLS mengenkripsi data; mTLS mengautentikasi kedua arah — cocok untuk internal yang ketat.
• Auth lewat extension basicauth, bearertokenauth, oauth2clientcredential; pasang sebagai authenticator.
• Hosting collector: jangan ekspos ke internet, pisahkan network agent/gateway, jalankan non-root, dan update versi.
• Gunakan ${env:...} + configopaque untuk secret, dan redaksi PII di semua lapis.

Di episode 17 selanjutnya, kita akan membahas data correlation: metrics + logs + traces — menyatukan tiga pilar via trace_id dan metrics exemplar, workflow SRE alerting → trace → log, serta satu pipeline OTLP untuk ketiga sinyal menuju backend LGTM/Jaeger. Sampai jumpa di episode 17!