Enkripsi mTLS Cilium (pratinjau publik)

Enkripsi Cilium mTLS menyediakan enkripsi dan autentikasi TLS bersama (mTLS) transparan untuk lalu lintas pod-ke-pod di Kubernetes tanpa memerlukan perubahan aplikasi atau memperkenalkan tumpukan jaringan tambahan.

Ini memastikan bahwa beban kerja sumber dan tujuan diautentikasi secara kriptografis sebelum lalu lintas apa pun ditukar. Pendekatan ini memungkinkan model jaringan tanpa kepercayaan untuk beban kerja Kubernetes.

Semua enkripsi dan autentikasi terjadi di bawah lapisan aplikasi, yang berarti beban kerja tidak perlu dimodifikasi, dibangun kembali, atau dimulai ulang untuk mendapatkan manfaat dari mTLS.

Enkripsi Cilium mTLS untuk AKS adalah bagian dari set fitur Advanced Container Networking Services (ACNS), dan implementasinya didasarkan pada Cilium.

Penting

Fitur pratinjau AKS tersedia atas dasar layanan mandiri dan pendaftaran sukarela. Pratinjau disediakan "apa adanya" dan "sebagaimana tersedia," dan pratinjau tersebut dikecualikan dari perjanjian tingkat layanan (SLA) serta garansi terbatas. Pratinjau AKS sebagian didukung oleh dukungan pelanggan berdasarkan upaya terbaik yang dapat dilakukan. Dengan demikian, fitur-fitur ini tidak dimaksudkan untuk penggunaan produksi. Untuk informasi lebih lanjut, lihat artikel dukungan berikut ini:

Architecture

Pada tingkat tinggi, Cilium mTLS mengamankan lalu lintas dengan menggabungkan penerbitan identitas, intersepsi lalu lintas transparan, dan penegakan enkripsi tingkat beban kerja.

Setiap beban kerja diberi identitas kriptografi yang berasal dari atribut Kubernetes seperti namespace layanan dan ServiceAccount. Ketika lalu lintas TCP pod-ke-pod dimulai, lalu lintas secara transparan diintersep di tingkat simpul. Lalu lintas kemudian diautentikasi dan dienkripsi menggunakan TLS timbal balik sebelum diteruskan ke beban kerja tujuan.

Sistem ini terdiri dari tiga komponen yang bekerja sama:

SPIRE - Menyediakan identitas beban kerja dan penerbitan sertifikat.
ztunnel - Memberlakukan mTLS di bidang data.
Cilium - Menginstal aturan iptables yang mengalihkan lalu lintas keluar ke ztunnel pada port 15001.

Bersama-sama, komponen-komponen ini memastikan bahwa autentikasi dan enkripsi terjadi secara transparan dan konsisten di seluruh kluster.

Model identitas dan autentikasi

Cilium mTLS menggunakan autentikasi timbal balik berdasarkan identitas beban kerja SPIFFE.

Setiap beban kerja diberi identitas SPIFFE (SVID) yang berasal dari:

Namespace Kubernetes
Kubernetes ServiceAccount

Saat beban kerja memulai koneksi:

Ztunnel mencari SVID yang valid untuk beban kerja.
Ztunnel tujuan memvalidasi identitas yang diberikan.
Kedua belah pihak menyelesaikan verifikasi bersama sebelum lalu lintas diizinkan untuk mengalir.

Keputusan autentikasi didasarkan pada identitas beban kerja daripada lokasi jaringan. Desain ini memastikan bahwa:

Hanya beban kerja terautentikasi yang dapat berkomunikasi.
Identitas tetap konsisten di seluruh penjadwalan ulang dan penskalakan.
Kepercayaan tidak bergantung pada alamat IP atau topologi jaringan.

Alur enkripsi

Setelah autentikasi berhasil, lalu lintas dilindungi menggunakan TLS bersama.

Lalu lintas yang dicegat di dalam namespace jaringan pod dialihkan ke instans ztunnel lokal.
Ztunnel asal memulai sesi mTLS dengan ztunnel tujuan.
Sertifikat ditukar dan divalidasi.
Data aplikasi dienkripsi sebelum transmisi.
Ztunnel tujuan mendekripsi lalu lintas dan mengirimkannya ke pod target.

Setiap paket dari pod yang terdaftar dienkripsi. Tidak ada jendela teks biasa, dan tidak ada paket pertama yang dijatuhkan. Koneksi dipertahankan dalam jalur oleh ztunnel hingga terowongan mTLS terbangun, setelah itu arus data mengalir secara dua arah melalui terowongan HBONE (HTTP/2 CONNECT).

Komponen inti

SPIRE (identitas dan kepercayaan)

SPIRE (SPIFFE Runtime Environment) bertanggung jawab atas identitas beban kerja dan manajemen sertifikat. SPIRE memiliki dua komponen utama: server SPIRE dan agen SPIRE.

Server SPIRE bertindak sebagai Otoritas Sertifikat kluster (CA). Ini mengeluarkan sertifikat X.509 berumur pendek (SVID) hanya untuk beban kerja yang diizinkan untuk menerima identitas. Ini menggunakan pengesahan Kubernetes-native, menghubungkan identitas dengan atribut seperti namespace dan ServiceAccount alih-alih ke properti jaringan seperti alamat IP.

Pada setiap simpul, agen SPIRE bertanggung jawab untuk mengotentikasi simpul pada server SPIRE dan mengambil sertifikat untuk beban kerja lokal. Beban kerja hanya berkomunikasi dengan agen SPIRE dan tidak pernah berhubungan langsung dengan server SPIRE.

SPIRE memastikan bahwa setiap identitas beban kerja adalah:

Dapat diverifikasi secara kriptografi.
Diterbitkan dan diputar secara otomatis.
Terikat ke primitif Kubernetes, bukan alamat IP.
Stabil di seluruh pengulangan pod dan peristiwa penjadwalan ulang.

Fondasi identitas ini memungkinkan pembuatan keputusan kepercayaan yang kuat dan independen dari topologi.

Ztunnel (bidang data mTLS)

Ztunnel adalah proksi Lapisan 4 tingkat simpul ringan yang bertanggung jawab untuk memberlakukan mTLS antar beban kerja. Ini berjalan sebagai DaemonSet, dengan satu instans per simpul, menghilangkan kebutuhan akan proksi sidecar per pod.

Saat 'workload' memulai koneksi TCP, ztunnel menjalin sesi TLS yang saling diautentikasi dengan instans ztunnel milik rekan node. Ini menggunakan sertifikat yang diperoleh dari SPIRE untuk mengautentikasi kedua sisi koneksi sebelum memungkinkan lalu lintas mengalir.

Ztunnel memberlakukan jaminan berikut:

Kedua sisi koneksi harus menunjukkan sertifikat beban kerja yang valid.
Sertifikat diverifikasi terhadap domain kepercayaan kluster.
Lalu lintas selalu dienkripsi pada kabel.
Tidak ada fallback teks polos yang diizinkan untuk beban kerja yang sudah terdaftar.

Dengan memusatkan penegakan mTLS di tingkat simpul, ztunnel menyediakan properti keamanan yang kuat tanpa meningkatkan overhead operasional per pod.

Cilium (aturan pengalihan dan pendaftaran pod)

Cilium bertanggung jawab untuk membuat mTLS transparan terhadap aplikasi.

Ketika namespace diberi label dengan "io.cilium/mtls-enabled=true", agen Cilium mendaftarkan semua pod di namespace tersebut. Ini memasuki namespace jaringan setiap pod dan menginstal aturan iptables yang mengalihkan lalu lintas keluar ke ztunnel pada port 15001.

Cilium juga meneruskan metadata beban kerja, seperti Pod UID, ke ztunnel dan terintegrasi dengan Operator Cilium untuk mendaftarkan identitas beban kerja dengan SPIRE.

Dari perspektif aplikasi, komunikasi terus menggunakan soket TCP standar. Enkripsi dan autentikasi diberlakukan sepenuhnya di bawah lapisan aplikasi, tidak memerlukan perubahan kode.

Cakupan dan batas kepercayaan

Pendaftaran namespace

Cilium mTLS adalah opsional dan dibatasi pada tingkat namespace. Namespace harus diberi label secara eksplisit untuk mengaktifkan penegakan mTLS. Setelah diaktifkan, semua pod dalam namespace layanan tersebut tunduk pada autentikasi dan enkripsi wajib.

Pod di namespace yang tidak tertenroll tidak terpengaruh. Desain ini memungkinkan peluncuran bertahap dan adopsi bertahap di seluruh lingkungan.

Model penegakan

Enkripsi hanya akan diterapkan jika kedua pod sudah didaftarkan. Lalu lintas antara workload terdaftar dan yang tidak terdaftar berlanjut dalam bentuk teks biasa tanpa menimbulkan masalah konektivitas atau kegagalan fatal.

Sumber	Tujuan	Result
Terdaftar	Terdaftar	Terenkripsi (mTLS melalui HBONE)
Terdaftar	Tidak terdaftar	Pengalihan teks biasa
Tidak terdaftar	Terdaftar	Teks biasa (ditangkap oleh ztunnel, tetapi tidak dienkripsi)
Tidak terdaftar	Tidak terdaftar	Jalur data Cilium normal (tidak ada keterlibatan ztunnel)

Pertimbangan dan keterbatasan

Fitur ini hanya tersedia pada kluster yang menggunakan Azure CNI yang didukung oleh Cilium dengan Advanced Container Networking Services (ACNS) diaktifkan.
mTLS diaktifkan pada tingkat namespace. Semua pod dalam namespace terdaftar berpartisipasi dalam mTLS. Opsi keikutsertaan atau penolakan pada tingkat pod tidak didukung.
Cilium mTLS saat ini melindungi lalu lintas pod-ke-pod berbasis TCP. Saat ini tidak mengenkripsi atau mengautentikasi protokol lain, termasuk UDP.
Pada fase saat ini, penegakan kebijakan jaringan L4/L7 tidak didukung dengan mTLS.
Anda tidak dapat membawa CA kustom. SPIRE bertindak sebagai Otoritas Sertifikat kluster dan mengelola penerbitan dan rotasi sertifikat.
Mengaktifkan mTLS dan WireGuard pada kluster yang sama tidak didukung.
Mengaktifkan enkripsi Istio dan Cilium mTLS tidak didukung.
Enkripsi mTLS untuk lalu lintas kluster tidak didukung.
Integrasi memerlukan dukungan iptable dalam kernel dan tidak dapat digunakan dengan lingkungan yang tidak mendukung iptable (seperti beberapa runtime kontainer minimal).
Pod tanpa jalur namespace jaringan (seperti pod berjaringan host) tidak dapat didaftarkan di ztunnel dan dikecualikan selama proses pendaftaran.

Penetapan Harga