Istio PeerAuthentication (mTLS): Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Istio PeerAuthentication (mTLS): Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya

Ilustrasi Istio PeerAuthentication dan Mutual TLS (mTLS)

Pada artikel sebelumnya kita telah membahas RequestAuthentication, yaitu resource Istio yang bertugas memverifikasi identitas pengguna menggunakan JSON Web Token (JWT). Setelah identitas berhasil diverifikasi dan Authorization Policy menentukan hak akses, masih ada satu aspek penting yang tidak boleh diabaikan, yaitu keamanan komunikasi antar workload.

Meskipun pengguna telah berhasil diautentikasi dan diotorisasi, data yang dikirimkan antar layanan tetap berpotensi disadap atau dimodifikasi apabila tidak dilindungi selama proses transmisi. Untuk mengatasi hal tersebut, Istio menyediakan PeerAuthentication yang bekerja bersama Mutual TLS (mTLS).

PeerAuthentication memungkinkan administrator menentukan apakah komunikasi antar workload harus menggunakan mTLS atau tidak. Dengan mTLS, kedua belah pihak—baik client maupun server—saling memverifikasi identitas menggunakan sertifikat digital sebelum pertukaran data dilakukan.

Pada artikel ini kita akan membahas PeerAuthentication secara lengkap mulai dari pengertian, konsep Mutual TLS, cara kerja, arsitektur, mode konfigurasi, implementasi pada Ambient Mesh, contoh YAML, hingga praktik terbaik pada lingkungan production.

Apa Itu PeerAuthentication?

PeerAuthentication adalah resource keamanan pada Istio yang digunakan untuk mengatur bagaimana workload menerima koneksi masuk. Resource ini menentukan apakah koneksi harus menggunakan Mutual TLS (mTLS), dapat menerima koneksi terenkripsi maupun tidak terenkripsi, atau sepenuhnya menonaktifkan mTLS pada workload tertentu.

Dengan kata lain, PeerAuthentication mengontrol cara workload berkomunikasi, sedangkan RequestAuthentication dan Authorization Policy mengontrol siapa yang berkomunikasi dan apa yang boleh dilakukan.

Apa Itu Mutual TLS (mTLS)?

Mutual TLS atau mTLS adalah pengembangan dari TLS yang tidak hanya memverifikasi identitas server, tetapi juga memverifikasi identitas client menggunakan sertifikat digital.


Traditional TLS

Client

   │

Verify Server

   │

Server



Mutual TLS

Client

   │

Verify Server

   │

Verify Client

   │

Encrypted Channel

Dengan mekanisme ini, kedua pihak dapat memastikan bahwa komunikasi hanya dilakukan dengan workload yang benar-benar dipercaya.

Mengapa PeerAuthentication Dibutuhkan?

Pada arsitektur microservices, ratusan bahkan ribuan request dapat terjadi setiap detik antar service di dalam cluster. Tanpa enkripsi, data sensitif seperti token autentikasi, informasi pengguna, maupun payload aplikasi Dewa234 berpotensi disadap apabila terjadi kompromi pada jaringan internal.


Order Service

      │

      ▼

Payment Service

      │

Encrypted

      │

Notification Service

PeerAuthentication memastikan seluruh komunikasi tersebut dapat dilindungi menggunakan mTLS sehingga kerahasiaan dan integritas data tetap terjaga.

Posisi PeerAuthentication pada Istio


Internet

    │

Gateway

    │

HTTPRoute

    │

RequestAuthentication

    │

Authorization Policy

    │

PeerAuthentication

    │

Application

Setelah identitas diverifikasi dan hak akses ditentukan, PeerAuthentication memastikan komunikasi antar workload berlangsung melalui koneksi yang aman menggunakan mTLS.

Hubungan PeerAuthentication dengan Ambient Mesh

Pada Ambient Mesh, proses enkripsi Layer 4 ditangani oleh ztunnel. PeerAuthentication menentukan apakah ztunnel harus menerima koneksi menggunakan mTLS atau tidak. Dengan demikian, administrator tetap memperoleh komunikasi terenkripsi tanpa perlu memasang sidecar pada setiap Pod.


Client

   │

Gateway

   │

ztunnel

   │

mTLS

   │

ztunnel

   │

Application

Model ini mengurangi overhead dibandingkan arsitektur sidecar sekaligus tetap menjaga keamanan komunikasi antar workload.

Bagaimana Cara Kerja PeerAuthentication?

Ketika sebuah workload menerima koneksi masuk, Istio akan memeriksa apakah terdapat PeerAuthentication yang berlaku. Berdasarkan mode yang dikonfigurasi, koneksi akan diterima atau ditolak.


Incoming Connection

        │

        ▼

PeerAuthentication

        │

Check Mode

        │

 ┌─────┴─────┐

 ▼           ▼

Accept     Reject

Jika mode yang digunakan adalah STRICT, hanya koneksi yang menggunakan mTLS yang akan diterima. Sebaliknya, pada mode PERMISSIVE, workload masih dapat menerima koneksi terenkripsi maupun tidak terenkripsi selama masa transisi migrasi.

Komponen PeerAuthentication

Komponen	Fungsi
selector	Menentukan workload yang dikenai policy.
mtls	Mengatur mode Mutual TLS.
mode	Menentukan STRICT, PERMISSIVE, atau DISABLE.
portLevelMtls	Mengatur mTLS pada port tertentu.

Fungsi PeerAuthentication

Mengaktifkan Mutual TLS pada workload.
Mengamankan komunikasi antar service.
Mencegah penyadapan data di jaringan internal.
Mendukung implementasi Zero Trust Security.
Menentukan mode komunikasi antar workload.
Mengurangi risiko serangan Man-in-the-Middle (MitM).
Terintegrasi dengan Ambient Mesh dan Sidecar Mode.
Menyederhanakan pengelolaan keamanan komunikasi.

Hubungan PeerAuthentication dengan RequestAuthentication

Walaupun keduanya sama-sama berkaitan dengan keamanan, PeerAuthentication dan RequestAuthentication memiliki fokus yang berbeda. RequestAuthentication memverifikasi identitas pengguna melalui JWT pada Layer 7, sedangkan PeerAuthentication mengamankan koneksi antar workload pada Layer 4 menggunakan sertifikat mTLS.


User

 │

JWT

 │

 ▼

RequestAuthentication

 │

Authorization Policy

 │

mTLS

 │

PeerAuthentication

 │

Workload

Dengan menggabungkan kedua resource tersebut, organisasi dapat membangun sistem keamanan berlapis yang melindungi identitas pengguna sekaligus menjaga kerahasiaan komunikasi antar layanan.

Mode Mutual TLS pada PeerAuthentication

Salah satu bagian terpenting dari PeerAuthentication adalah penentuan mode mTLS. Istio menyediakan beberapa mode yang dapat dipilih sesuai tahap implementasi dan kebutuhan operasional.

Mode Mutual TLS pada PeerAuthentication

Istio menyediakan tiga mode utama pada PeerAuthentication, yaitu STRICT, PERMISSIVE, dan DISABLE. Setiap mode memiliki karakteristik yang berbeda dan digunakan sesuai dengan kebutuhan implementasi maupun tahap migrasi aplikasi.


PeerAuthentication

      │

      ├── STRICT

      ├── PERMISSIVE

      └── DISABLE

Pemilihan mode yang tepat sangat penting agar komunikasi antar workload tetap aman tanpa mengganggu operasional aplikasi.

Mode STRICT

Mode STRICT merupakan konfigurasi yang paling aman. Pada mode ini, seluruh koneksi menuju workload wajib menggunakan Mutual TLS (mTLS). Apabila terdapat request tanpa mTLS, Istio akan langsung menolak koneksi tersebut.


Client

   │

mTLS

   │

✔ Accepted



Client

   │

Plain Text

   │

✖ Rejected

Mode STRICT sangat direkomendasikan untuk lingkungan production yang telah sepenuhnya menggunakan service mesh dan tidak lagi memiliki layanan yang masih berkomunikasi tanpa enkripsi.

Mode PERMISSIVE

Mode PERMISSIVE memungkinkan workload menerima koneksi baik yang menggunakan mTLS maupun yang masih menggunakan komunikasi biasa (plain text). Mode ini biasanya digunakan pada proses migrasi dari aplikasi lama menuju arsitektur service mesh.


Incoming Connection

      │

 ┌────┴─────┐

 ▼          ▼

mTLS     Plain Text

 │           │

 ▼           ▼

Accepted   Accepted

Dengan mode ini, administrator dapat memigrasikan layanan secara bertahap tanpa menyebabkan gangguan pada aplikasi yang belum mendukung mTLS.

Mode DISABLE

Mode DISABLE menonaktifkan penggunaan mTLS pada workload tertentu. Seluruh komunikasi dilakukan tanpa proses enkripsi menggunakan Mutual TLS.


Client

   │

Plain Text

   │

Accepted

Mode ini umumnya hanya digunakan pada lingkungan pengembangan atau ketika berinteraksi dengan sistem lama yang belum mendukung mTLS. Untuk lingkungan production, penggunaan mode DISABLE sebaiknya dihindari karena tidak memberikan perlindungan terhadap komunikasi antar workload.

Perbandingan Mode PeerAuthentication

Mode	mTLS	Plain Text	Rekomendasi
STRICT	✔	✖	Production
PERMISSIVE	✔	✔	Migrasi
DISABLE	✖	✔	Development

Workload Selector

PeerAuthentication dapat diterapkan pada workload tertentu menggunakan selector. Dengan pendekatan ini, administrator tidak perlu menerapkan kebijakan yang sama pada seluruh service.


PeerAuthentication

       │

Selector

app=payment

       │

       ▼

Payment Pods

Pendekatan berbasis label membuat konfigurasi lebih fleksibel dan mudah dipelihara ketika jumlah workload bertambah.

Namespace Scope

Selain selector, PeerAuthentication juga dapat diterapkan pada tingkat namespace. Semua workload di dalam namespace tersebut akan mengikuti kebijakan mTLS yang telah ditentukan.


Production Namespace

        │

        ▼

Order Service

Payment Service

Inventory Service

Strategi ini sering digunakan untuk memastikan seluruh aplikasi production menggunakan standar keamanan yang sama.

portLevelMtls

Dalam beberapa kasus, administrator mungkin ingin menerapkan mTLS hanya pada port tertentu. Istio menyediakan fitur portLevelMtls untuk memenuhi kebutuhan tersebut.


Port 8080

    │

mTLS Enabled



Port 9090

    │

Plain Text

Fitur ini berguna ketika sebuah aplikasi memiliki endpoint dengan kebutuhan keamanan yang berbeda pada setiap port.

Contoh PeerAuthentication Mode STRICT

apiVersion: security.istio.io/v1

kind: PeerAuthentication

metadata:

  name: default

spec:

  mtls:

    mode: STRICT

Konfigurasi tersebut mengaktifkan mTLS secara penuh sehingga seluruh koneksi yang tidak menggunakan mTLS akan ditolak.

Contoh PeerAuthentication Mode PERMISSIVE

apiVersion: security.istio.io/v1

kind: PeerAuthentication

metadata:

  name: migration

spec:

  mtls:

    mode: PERMISSIVE

Mode PERMISSIVE sangat membantu ketika organisasi sedang melakukan migrasi bertahap dari aplikasi legacy menuju lingkungan service mesh.

Contoh PeerAuthentication Berdasarkan Workload

apiVersion: security.istio.io/v1

kind: PeerAuthentication

metadata:

  name: payment-mtls

spec:

  selector:

    matchLabels:

      app: payment

  mtls:

    mode: STRICT

Pada contoh di atas, hanya workload dengan label app: payment yang diwajibkan menggunakan mTLS.

Strategi Migrasi dari PERMISSIVE ke STRICT

Migrasi menuju mTLS sebaiknya dilakukan secara bertahap untuk mengurangi risiko gangguan layanan. Tahapan yang umum dilakukan adalah sebagai berikut:


Step 1

DISABLE

      │

      ▼

Step 2

PERMISSIVE

      │

Monitor

      │

      ▼

Step 3

STRICT

Selama fase PERMISSIVE, administrator dapat mengidentifikasi layanan yang masih menggunakan komunikasi tanpa enkripsi sebelum akhirnya mengaktifkan mode STRICT.

Hubungan PeerAuthentication dengan Ambient Mesh

Pada Ambient Mesh, PeerAuthentication bekerja bersama ztunnel untuk mengamankan komunikasi Layer 4. Ketika mode STRICT diterapkan, ztunnel akan memastikan bahwa seluruh koneksi antar workload menggunakan mTLS sebelum diteruskan ke aplikasi.


Application A

      │

ztunnel

      │

mTLS

      │

ztunnel

      │

Application B

Dengan mekanisme ini, keamanan komunikasi dapat diterapkan secara konsisten tanpa memerlukan sidecar Envoy pada setiap Pod, sehingga overhead sumber daya menjadi lebih rendah dibandingkan arsitektur sidecar tradisional.

Best Practice Menggunakan PeerAuthentication

Agar implementasi Mutual TLS (mTLS) berjalan optimal, administrator perlu menerapkan PeerAuthentication secara bertahap dan terencana. Penerapan yang terburu-buru dapat menyebabkan layanan yang belum mendukung mTLS kehilangan konektivitas. Oleh karena itu, proses migrasi sebaiknya dilakukan melalui tahap pengujian, monitoring, dan validasi sebelum diberlakukan secara penuh pada lingkungan production.

Gunakan mode PERMISSIVE saat proses migrasi dari aplikasi legacy menuju service mesh.
Ubah ke mode STRICT setelah seluruh workload mendukung komunikasi mTLS.
Hindari penggunaan mode DISABLE pada lingkungan production.
Terapkan PeerAuthentication pada tingkat namespace agar konfigurasi lebih konsisten.
Gunakan selector untuk memberikan kebijakan khusus pada workload tertentu.
Kombinasikan dengan Authorization Policy dan RequestAuthentication untuk membangun keamanan berlapis.
Pastikan sertifikat workload selalu diperbarui secara otomatis oleh Istio.
Lakukan audit konfigurasi keamanan secara berkala.
Pantau komunikasi antar service menggunakan Kiali atau Grafana.
Dokumentasikan seluruh kebijakan mTLS agar mudah dipelihara oleh tim DevOps.

Monitoring PeerAuthentication

Monitoring sangat penting untuk memastikan bahwa komunikasi antar workload benar-benar menggunakan mTLS. Administrator dapat memanfaatkan dashboard observability seperti Prometheus, Grafana, dan Kiali untuk melihat status koneksi serta mendeteksi apabila masih terdapat komunikasi tanpa enkripsi.


Workload A

      │

mTLS Connection

      │

Workload B

      │

Metrics

      │

Prometheus

      │

Grafana

Monitoring yang konsisten membantu tim operasional menemukan masalah konfigurasi lebih awal dan memastikan standar keamanan tetap terjaga di seluruh cluster.

Troubleshooting PeerAuthentication

1. Koneksi Ditolak Setelah Mengaktifkan STRICT

Apabila workload tiba-tiba tidak dapat saling berkomunikasi setelah mode STRICT diaktifkan, kemungkinan masih terdapat service yang belum menggunakan mTLS. Periksa konfigurasi DestinationRule dan pastikan seluruh workload telah menjadi bagian dari service mesh.


Client

   │

Plain Text

   │

STRICT Mode

   │

403 / Connection Failed

2. Sebagian Service Masih Menggunakan Plain Text

Periksa apakah namespace atau workload tersebut masih menggunakan mode PERMISSIVE atau DISABLE. Gunakan dashboard Kiali untuk melihat status koneksi antar service.

3. Workload Tidak Mendapat Sertifikat

Pastikan komponen control plane Istio berjalan dengan baik sehingga sertifikat identitas workload dapat diterbitkan secara otomatis.

4. Policy Tidak Berpengaruh

Periksa kembali selector, namespace, dan label workload. Kesalahan kecil pada label Kubernetes dapat menyebabkan PeerAuthentication tidak diterapkan pada workload yang dimaksud.

Implementasi PeerAuthentication pada Lingkungan Production

Pada organisasi berskala enterprise, PeerAuthentication biasanya diterapkan secara menyeluruh pada namespace production. Seluruh komunikasi antar service diwajibkan menggunakan mTLS sehingga setiap koneksi telah melalui proses autentikasi sertifikat sebelum pertukaran data berlangsung.


Gateway

   │

Frontend

   │

mTLS

   │

Order Service

   │

mTLS

   │

Payment Service

   │

mTLS

   │

Notification Service

Pendekatan ini tidak hanya meningkatkan keamanan komunikasi, tetapi juga membantu memenuhi standar kepatuhan seperti PCI DSS, HIPAA, maupun ISO 27001 yang mensyaratkan perlindungan data selama transmisi.

Kelebihan PeerAuthentication

Mengamankan komunikasi antar workload menggunakan Mutual TLS.
Mencegah penyadapan data pada jaringan internal.
Mendukung implementasi Zero Trust Security.
Terintegrasi langsung dengan Istio Service Mesh.
Bekerja pada Ambient Mesh maupun Sidecar Mode.
Manajemen sertifikat dilakukan secara otomatis oleh Istio.
Mengurangi risiko serangan Man-in-the-Middle (MitM).
Dapat diterapkan pada tingkat mesh, namespace, maupun workload.
Mendukung migrasi bertahap melalui mode PERMISSIVE.
Mudah dikombinasikan dengan fitur keamanan Istio lainnya.

Kekurangan PeerAuthentication

Membutuhkan pemahaman mengenai konsep Mutual TLS.
Kesalahan konfigurasi dapat menyebabkan layanan kehilangan konektivitas.
Proses migrasi dari aplikasi legacy memerlukan perencanaan yang matang.
Perlu monitoring untuk memastikan seluruh workload benar-benar menggunakan mTLS.
Harus dikombinasikan dengan DestinationRule agar konfigurasi komunikasi lebih lengkap.

Contoh Implementasi pada Sistem Perbankan

Bayangkan sebuah sistem perbankan digital yang memiliki beberapa layanan seperti Customer Service, Account Service, Transfer Service, Payment Service, dan Fraud Detection Service. Setiap layanan saling bertukar informasi sensitif seperti nomor rekening, transaksi, dan data autentikasi.


Mobile Banking

      │

Gateway

      │

Frontend

      │

mTLS

      │

Account Service

      │

mTLS

      │

Transfer Service

      │

mTLS

      │

Payment Service

Dengan PeerAuthentication mode STRICT, setiap layanan hanya menerima koneksi dari workload yang telah memiliki sertifikat identitas yang valid. Hal ini mengurangi risiko penyadapan maupun penyusupan layanan yang tidak sah ke dalam jaringan internal.

Artikel Selanjutnya

Setelah memahami bagaimana PeerAuthentication mengamankan komunikasi antar workload menggunakan mTLS, langkah berikutnya adalah mempelajari Telemetry API. Resource ini memungkinkan administrator mengumpulkan metrik, log, dan tracing secara lebih fleksibel untuk mendukung observability pada Istio Service Mesh.


Application

      │

Telemetry API

      │

Metrics

      │

Logs

      │

Tracing

      │

Prometheus / Grafana / Jaeger

Telemetry API menjadi komponen penting untuk memantau performa aplikasi, menganalisis lalu lintas, dan mempercepat proses troubleshooting pada lingkungan cloud-native.

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu PeerAuthentication?

PeerAuthentication adalah resource keamanan Istio yang digunakan untuk mengatur penggunaan Mutual TLS (mTLS) pada komunikasi antar workload.

Apa perbedaan PeerAuthentication dan RequestAuthentication?

RequestAuthentication memverifikasi identitas pengguna melalui JWT pada Layer 7, sedangkan PeerAuthentication mengamankan komunikasi antar workload menggunakan mTLS pada Layer 4.

Kapan sebaiknya menggunakan mode STRICT?

Mode STRICT digunakan ketika seluruh workload telah mendukung mTLS sehingga semua komunikasi dapat diwajibkan menggunakan koneksi terenkripsi.

Apa fungsi mode PERMISSIVE?

Mode PERMISSIVE memungkinkan workload menerima koneksi dengan maupun tanpa mTLS sehingga cocok digunakan selama proses migrasi.

Apakah mode DISABLE aman untuk production?

Tidak direkomendasikan. Mode DISABLE menonaktifkan mTLS sehingga komunikasi antar workload tidak terlindungi oleh enkripsi.

Apakah PeerAuthentication bekerja pada Ambient Mesh?

Ya. Pada Ambient Mesh, PeerAuthentication bekerja bersama ztunnel untuk mengamankan komunikasi Layer 4 menggunakan Mutual TLS.

Apakah PeerAuthentication mengelola sertifikat?

Sertifikat identitas workload dikelola secara otomatis oleh Istio melalui control plane, sedangkan PeerAuthentication menentukan bagaimana sertifikat tersebut digunakan saat menerima koneksi.

Mengapa PeerAuthentication penting?

Karena komunikasi antar service sering membawa data sensitif. mTLS membantu menjaga kerahasiaan, integritas, dan keaslian komunikasi tersebut.

Apakah PeerAuthentication dapat diterapkan pada namespace tertentu?

Ya. PeerAuthentication dapat diterapkan pada tingkat mesh, namespace, maupun workload menggunakan selector berbasis label Kubernetes.

Apa hubungan PeerAuthentication dengan DestinationRule?

PeerAuthentication mengatur bagaimana workload menerima koneksi, sedangkan DestinationRule mengatur bagaimana client membuat koneksi menuju workload tersebut. Keduanya sering digunakan bersama untuk implementasi mTLS yang konsisten.

Kesimpulan

Istio PeerAuthentication merupakan komponen penting dalam membangun komunikasi yang aman di lingkungan Kubernetes Service Mesh. Dengan memanfaatkan Mutual TLS (mTLS), setiap workload dapat saling memverifikasi identitas melalui sertifikat digital sehingga komunikasi berlangsung secara terenkripsi dan lebih terlindungi dari ancaman penyadapan maupun serangan Man-in-the-Middle.

Ketika dipadukan dengan HTTPRoute, RequestAuthentication, Authorization Policy, serta DestinationRule, PeerAuthentication menjadi bagian dari fondasi keamanan berlapis yang mendukung implementasi Zero Trust Security. Pendekatan ini membantu organisasi membangun aplikasi cloud-native yang lebih aman, andal, serta mudah dikelola pada skala enterprise modern.