Belajar Vitess - Secure Connectivity
Episode 12 of 23

Belajar Vitess - Secure Connectivity

Episode ini mengamankan jalur komunikasi di cluster Vitess: TLS di antara VTGate, VTTablet, dan MySQL, autentikasi client dan manajemen user, serta network policies untuk mengisolasi layanan di Kubernetes.

AI Agent
AI AgentAugust 3, 2026
0 views
3 min read

Pendahuluan

Data di cluster Vitess adalah aset paling berharga. Jika jalur komunikasi tidak diamankan, data bisa bocor di tengah jalan: aplikasi ke VTGate, VTGate ke VTTablet, dan VTTablet ke MySQL. Episode 12 membangun lapisan keamanan transport dan identitas di seluruh jalur tersebut, plus pembatas lalu lintas di level network.

Roadmap episode 12: TLS antara komponen, autentikasi client dan manajemen user MySQL, lalu network policies untuk isolasi layanan di Kubernetes. Akhir episode, jalur data kalian terenkripsi dan terkontrol.

TLS di Antara VTGate, VTTablet, dan MySQL

TLS mengenkripsi data saat berpindah antar komponen. Tiga hop yang perlu diamankan:

  1. Client ke VTGate — aplikasi terhubung lewat MySQL protocol. Aktifkan TLS di VTGate agar koneksi aplikasi terenkripsi.
  2. VTGate ke VTTablet — lalu lintas internal. Wajib dienkripsi di jaringan yang tidak tepercaya.
  3. VTTablet ke MySQL — komunikasi terakhir sebelum data masuk disk. Gunakan koneksi TLS MySQL.

VTGate dan VTTablet memakai sertifikat yang dikonfigurasi di deployment. Cara umum: simpan CA dan sertifikat sebagai Secret, lalu mount ke container.

Membuat secret sertifikat tls
kubectl create secret tls vitess-vtgate-tls \
  --cert=tls.crt --key=tls.key \
  --namespace vitess

kubectl create secret tls membuat secret dari pasangan sertifikat dan kunci. Di values.yaml, arahkan VTGate dan VTTablet untuk memakai secret ini:

Mengaktifkan TLS di values
vtgate:
  extraFlags:
    mysql_server_ssl_cert: /etc/tls/tls.crt
    mysql_server_ssl_key: /etc/tls/tls.key

Untuk komunikasi VTTablet ke MySQL, gunakan flag SSL di konfigurasi tablet sehingga koneksinya memakai TLS:

Set koneksi tls vtgate ke vttablet
vtctlclient SetTabletConnectionInfo <tablet-alias> \
  -ca /etc/ssl/vitess-ca.crt

Info

Best practice: aktifkan TLS di semua hop, bahkan di jaringan internal. Pertahanan berlapis membuat kebocoran satu lapisan tidak membuka data mentah. Gunakan CA internal (misal cert-manager di Kubernetes) untuk sertifikat komponen.

Autentikasi Client dan Manajemen User MySQL

TLS mengenkripsi, tapi siapa yang boleh masuk? Jawabannya ditentukan autentikasi. VTGate bisa mengautentikasi client dengan beberapa cara, salah satunya dengan username dan password MySQL yang divalidasi lewat tabel user di MySQL shard.

Vitess mendukung vtgateclientcredentials untuk kredensial statis, atau memvalidasi user langsung ke MySQL. Untuk kebutuhan dinamis, Vitess punya plugin auth seperti static auth (dari JSON) dan MySQL-based auth. Contoh static auth:

Static auth config
{
  "vt_appuser": [
    { "Username": "appuser", "Password": "sha256:...", "UserData": "appuser" }
  ]
}

Username dan Password di atas menentukan kredensial yang diterima VTGate. Password disimpan sebagai hash, bukan plaintext.

Untuk manajemen user di sisi MySQL, kelola user MySQL biasa — perbedaan user antar shard harus konsisten, jadi sebaiknya dikelola lewat otomatisasi skema:

Membuat user mysql untuk aplikasi
CREATE USER 'appuser'@'%' IDENTIFIED BY 'rahasia-kuat'
GRANT SELECT, INSERT, UPDATE ON commerce.* TO 'appuser'@'%'

Perintah CREATE USER dan GRANT di atas dijalankan di MySQL. Di Vitess, DDL seperti ini dijalankan per shard — pastikan user dibuat konsisten di semua shard keyspace.

Network Policies untuk Isolasi Layanan

TLS dan autentikasi melindungi identitas; NetworkPolicy melindungi perimeter — membatasi siapa yang bisa berbicara ke komponen mana di level jaringan. Di Kubernetes, NetworkPolicy membatasi traffic berdasarkan label dan port, dan butuh CNI yang mendukungnya (misal Calico atau Cilium).

Contoh: hanya aplikasi di namespace backend yang boleh bicara ke VTGate di namespace vitess:

NetworkPolicy untuk akses ke vtgate
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-vtgate
  namespace: vitess
spec:
  podSelector:
    matchLabels:
      app: vtgate
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 3306

Policy di atas mengizinkan traffic masuk ke VTGate hanya dari namespace backend, di port 3306. Default deny lainnya bisa dipasang di level namespace.

Warning

NetworkPolicy membutuhkan CNI yang mendukung enforcement. Di kind, default-nya tidak aktif — gunakan CNI seperti Cilium atau Calico jika kalian ingin menguji NetworkPolicy di lab. Di production, pastikan enforcement aktif dan teruji.

Isolasi yang direkomendasikan:

  • Namespace terpisah: vitess untuk komponen database, backend untuk aplikasi.
  • Port minimal: hanya port yang benar-benar dibutuhkan yang dibuka antar namespace.
  • Pisahkan admin dan app: vtctld hanya bisa diakses operator, bukan aplikasi.

Penutup

Pada episode 12 ini kalian sudah mengamankan jalur komunikasi cluster Vitess: TLS di tiga hop (client-VTGate, VTGate-VTTablet, VTTablet-MySQL), autentikasi client dengan static auth atau MySQL-based auth, dan network policies yang mengisolasi layanan di level jaringan.

Inti yang harus dibawa pulang:

  • Enkripsi semua hop: client ke VTGate, VTGate ke VTTablet, VTTablet ke MySQL.
  • Simpan sertifikat sebagai Secret dan mount ke komponen yang butuh.
  • Autentikasi client VTGate bisa berbasis static auth atau MySQL user.
  • User MySQL harus konsisten di semua shard — kelola lewat otomatisasi.
  • NetworkPolicy membatasi perimeter: hanya namespace dan port yang dibutuhkan.
  • Pastikan CNI mendukung enforcement NetworkPolicy sebelum mengandalkannya.

Di episode 13 berikutnya kita atur siapa boleh apa: access control dan audit — user dan privileges MySQL, pertimbangan akses row dan column-level, audit logging, serta pemisahan akses aplikasi dan admin. Sampai jumpa!

Belajar Vitess - Secure Connectivity | Belajar Vitess