Komunikasi yang aman dan terenkripsi antara cluster Anthos menggunakan Anthos Service Mesh

Dokumen ini menunjukkan engineer jaringan, platform, dan keamanan yang mengelola cluster Kubernetes tentang cara menangani komunikasi eksternal cluster ke cluster menggunakan gateway masuk dan keluar Anthos Service Mesh. Dokumen ini menjelaskan cara menggunakan Anthos Service Mesh untuk mengenkripsi dan membantu mengamankan traffic keluar (keluar) dari workload yang di-deploy di satu cluster Kubernetes ke workload yang berjalan di cluster Kubernetes lain. Teknik yang dijelaskan menunjukkan cara menggunakan sertifikat terpisah untuk komunikasi timbal balik yang dienkripsi dan cluster ke cluster.

Panduan dalam dokumen ini berasal dari persyaratan pelanggan untuk menggunakan Certificate Authority (CA) root tertentu untuk komunikasi intra-cluster. Anda mungkin menemukan persyaratan tersebut di pasar yang diatur dengan ketat, seperti jasa keuangan atau layanan kesehatan. Panduan yang ditampilkan di sini juga memungkinkan penggunaan endpoint selain cluster Kubernetes, seperti penyedia pengelolaan keuangan atau antarmuka API untuk data sensitif. Panduan ini sangat relevan bagi organisasi yang perlu mematuhi kebijakan keamanan dan audit yang ketat.

Anda dapat mengoperasikan dan menangani komunikasi terenkripsi tanpa menyentuh workload yang berjalan di cluster. Untuk mendapatkan panduan tentang cara mengonfigurasi cluster Anda sendiri, ikuti tutorial berikut.

Pengantar

Saat pertama kali mulai mengadopsi Kubernetes, perusahaan sering kali memulai dengan satu cluster, tempat sebagian besar komunikasi tetap berada dalam cluster tersebut. Dalam waktu dekat, interaksi lintas namespace akan menjadi semakin penting, dan di situlah penyedia kebijakan jaringan seperti Calico atau Cillium dapat membantu. Namun, seiring berkembangnya lingkungan container, lingkungan container akan menjadi lebih relevan untuk memastikan bahwa komunikasi dapat terjadi dengan aman antara layanan eksternal dan container Anda yang berjalan di dalam cluster Kubernetes.

Kebijakan jaringan adalah cara yang bagus untuk menangani konsep keamanan tradisional seperti membuat aturan firewall cluster-internal, tetapi penggunaannya hanya terbatas di luar cluster. Anda dapat hanya mengizinkan alamat IP tertentu untuk dijangkau, tetapi tidak ada kontrol atas konten atau identitas yang tersedia. Oleh karena itu, diperlukan konsep yang lebih serbaguna, yang juga membantu Anda mengenkripsi traffic ke layanan eksternal lainnya. Diagram berikut menawarkan satu pendekatan.

Dalam dunia aplikasi, enkripsi biasanya dilakukan dengan menggunakan TLS (Transport Layer Security). Artinya, Anda dapat mengenkripsi traffic dengan menggunakan sertifikat pribadi (rahasia) dengan sertifikat publik, seperti yang ditunjukkan dalam diagram sebelumnya. Pihak penerima memegang sertifikat publik, yang digunakan untuk memverifikasi bahwa informasi tersebut berasal dari sumber tepercaya. Traffic web HTTPS menggunakan TLS untuk membantu memastikan komunikasi yang aman dan terenkripsi antara klien dan server web. Dalam hal ini, sertifikat publik berasal dari penerbit tepercaya (seperti Layanan Kepercayaan Google), yang juga disebut sebagai CA, yang merupakan bagian dari infrastruktur kunci publik (PKI). TLS memverifikasi identitas server, tetapi tidak memverifikasi identitas klien.

Jika klien juga harus diverifikasi, autentikasi timbal balik, atau mTLS, diperlukan. mTLS digunakan saat pengirim dan penerima harus mengidentifikasi dirinya sendiri kepada pihak lain, seperti yang ditunjukkan pada diagram berikut.

Metode ini sering digunakan untuk aplikasi yang memerlukan lapisan keamanan tambahan. Dalam industri keuangan, dan untuk informasi identitas pribadi (PII), badan pengatur sering kali mewajibkan mTLS.

Anthos Service Mesh

Anthos Service Mesh adalah solusi mesh layanan yang dikelola Google berdasarkan OSS Istio. Artinya, platform tersebut 100% kompatibel dengan Istio API. Anthos Service Mesh dapat menyediakan fungsionalitas mTLS di tingkat platform, bukan di dalam kode aplikasi, yang berarti dapat berlaku ke layanan tanpa mengharuskan Anda melakukan coding ulang setiap layanan. Operasi seperti rotasi sertifikat juga merupakan bagian dari Anthos Service Mesh. Dokumen ini berfokus pada mTLS dan fitur komunikasi eksternal Anthos Service Mesh. Ada banyak fitur lainnya seperti injeksi kesalahan, load balancing lanjutan, dan penanganan error.

Dengan merutekan semua traffic melalui proxy side-car (Envoy), mesh layanan seperti Anthos Service Mesh meringankan beban developer dari tugas biasa (tetapi penting) seperti enkripsi dan penanganan sertifikat ini. Dengan menggunakan proxy transparan, mesh layanan dapat mengaktifkan fungsi L7 yang canggih, seperti mengarahkan panggilan HTTP dan HTTPS berdasarkan informasi header. Namun, Anthos Service Mesh juga memungkinkan enkapsulasi dan enkripsi traffic, yang dapat membantu meningkatkan keamanan.

Contoh konfigurasi: Komunikasi MySQL antar-cluster

Anda dapat menggunakan skenario ini jika Anda ingin memiliki komunikasi yang aman dan tepercaya antara layanan di cluster yang berbeda. Dalam contoh ini, aplikasi klien MySQL berkomunikasi dengan workload DB server MySQL yang berjalan di cluster Kubernetes yang berbeda, seperti yang ditunjukkan diagram berikut.

Meskipun mesh layanan sering berfungsi di OSI L7, Anda juga dapat menggunakan beberapa fungsinya untuk mengontrol komunikasi L4.

Berikut adalah yang Anda butuhkan agar konsep berfungsi:

• Komunikasi antara aplikasi dan cluster harus dienkripsi.
• Komunikasi klien dan server harus diverifikasi bersama (mTLS).
• Workload klien dan server tidak perlu berubah.

Meskipun Anda dapat menyiapkan database MySQL untuk menerima koneksi terenkripsi saja, penyiapan tersebut mengharuskan Anda mengubah klien database yang mungkin tidak Anda kontrol sepenuhnya.

Ada beberapa cara untuk memenuhi persyaratan ini dengan menggunakan Anthos Service Mesh. Salah satu caranya adalah dengan membuat bidang kontrol Istio bersama di antara cluster dan membuat layanan saling berkomunikasi karena layanan tersebut termasuk dalam satu mesh layanan logis. Anda dapat melakukannya untuk cluster GKE yang mengaktifkan Anthos menggunakan Anthos Service Mesh dalam penyiapan satu project atau multi-project.

Namun, karena ada persyaratan untuk memiliki rantai kepercayaan terpisah untuk komunikasi cluster-ke-cluster, Anda dapat menggunakan pendekatan gateway keluar <–> gateway masuk menggunakan mTLS.

Gateway keluar dan masuk adalah proxy Envoy yang berada di batas mesh.

Anda dapat mengonfigurasinya untuk mengontrol arus traffic masuk dan keluar dari mesh layanan. Opsi ini juga berfungsi untuk endpoint non-Kubernetes dan memungkinkan Anda menggunakan sertifikat berbeda untuk komunikasi yang dienkripsi.

Mengonfigurasi traffic masuk dan keluar Anthos Service Mesh

Dalam skenario sebelumnya, Anda menangani komunikasi cluster ke cluster yang aman dengan menggunakan gateway keluar dan gateway masuk antara masing-masing cluster.

Apa itu gateway keluar?

Traffic keluar berarti traffic yang mengalir keluar dari mesh layanan Anda. Gateway keluar menyediakan titik keluar yang dikontrol untuk traffic tersebut.

Tanpa konfigurasi tambahan, untuk Pod tempat proxy sidecar telah dimasukkan, traffic yang ditujukan untuk layanan yang berada di luar mesh (misalnya, layanan API publik) dirutekan dari Pod ke proxy sidecar. Dalam cluster GKE (dan sebagian besar cluster Kubernetes lainnya), alamat IP Node menggunakan NAT untuk menerjemahkan traffic proxy sidecar, yang mengalir langsung ke alamat eksternal layanan. Diagram berikut menunjukkan konfigurasi ini.

Dalam diagram ini, klien memanggil sisi server yang mewakili layanan eksternal. Traffic ini keluar untuk mesh sehingga Anda perlu mengonfigurasi gateway keluar di sisi klien (misalnya, klien MySQL).

Anda mengonfigurasi gateway keluar untuk meneruskan panggilan ke layanan eksternal. Setelah layanan eksternal memproses permintaan dan menampilkan respons, layanan eksternal sekali lagi akan melewati gateway keluar kembali ke proxy klien, dan akhirnya ke Pod yang mengeluarkan panggilan (misalnya, klien MySQL).

Apa itu gateway masuk?

Traffic masuk berarti traffic yang mengalir ke mesh layanan. Gateway masuk mengekspos layanan ke dunia luar (yaitu, di luar mesh layanan) dan menangani cara akses layanan ini. Ini sebanding dengan objek Ingress Kubernetes.

Dengan gateway masuk, Anda dapat menentukan satu titik entri yang dikontrol tempat traffic masuk ke mesh. Awalnya, traffic masuk melalui load balancer, yang dibuat dengan menentukan layanan gateway masuk. Dari sana, permintaan diteruskan ke proxy sidecar, lalu dari proxy, permintaan tersebut diteruskan ke Pod. Pod dapat memproses permintaan dan menampilkan respons dengan menggunakan rute yang sama secara terbalik. Diagram berikut menunjukkan konfigurasi ini.

Traffic ini adalah traffic masuk ke mesh cluster lain (VPC 2). Oleh karena itu, Anda perlu mengonfigurasi gateway masuk di sisi server untuk menangani panggilan tersebut.

Konfigurasi sisi server dari gateway masuk meneruskan panggilan ke layanan internal. Setelah layanan internal memproses permintaan, respons yang akan dikembalikan melalui gateway masuk ke klien.

Menggabungkan fungsi keluar dan masuk untuk TLS bersama

Seperti yang telah disebutkan sebelumnya, untuk sisi klien, Anda perlu menentukan gateway keluar yang berfungsi sebagai titik keluar yang dikontrol untuk mesh layanan Untuk memastikan bahwa traffic yang keluar dari mesh melalui gateway dienkripsi oleh mTLS, Anda dapat menggunakan teknik yang disebut TLS origination. Konfigurasikan gateway keluar untuk melakukan TLS origination bagi traffic ke layanan eksternal.

Saat traffic yang keluar dari mesh layanan dari sisi klien dienkripsi, Anda harus memastikan sisi server dapat mengidentifikasi dirinya sendiri ke klien dan mengartikan traffic yang dienkripsi.

Untuk itu, Anda menggunakan gateway masuk sebagai titik masuk tunggal ke mesh. Mengonfigurasi gateway masuk sehingga memperkirakan traffic terenkripsi satu sama lain.

Ringkasan arsitektur mesh

Diagram berikut menjelaskan hal yang diperlukan untuk menerapkan konsep ini untuk skenario MySQL, tanpa mengubah apa pun dalam aplikasi atau server.

Di VPC 1, Anda melihat bahwa cluster klien yang menjalankan klien MySQL sedang mengakses server. Server ini terletak di VPC 2.

Sisi klien memiliki konfigurasi yang lebih berat daripada sisi server karena Anda perlu melakukan sedikit lebih banyak pencocokan traffic dan perutean traffic, untuk memastikan aplikasi tersebut menggunakan gateway keluar. Namun, konfigurasi ini adalah upaya nol harian, yang berarti Anda hanya harus melakukannya sekali. Setelah Anda menerapkannya, semuanya menjadi cukup mudah dikelola.

Manfaat menerapkan konsep ini menggunakan Kubernetes adalah semua item konfigurasi disimpan dalam file YAML. Artinya, seluruh konstruksi dapat digunakan pada repositori berversi, yang memungkinkan Anda melacak perubahan dan dengan mudah mengembalikannya jika diperlukan.

Sisi klien

Subpasal ini membahas konfigurasi sisi klien. Setiap elemen yang Anda lihat dalam diagram memiliki fungsi yang berbeda dalam mesh untuk mengontrol cara traffic dirutekan melalui gateway keluar untuk mencapai tujuannya, yaitu server MySQL.

Pemilihan rute traffic hanyalah salah satu bagian dari fungsi yang diperlukan. Elemen lain mengontrol enkripsi traffic dan sepenuhnya transparan untuk membantu memastikan bahwa komunikasi selalu aman. Bagian berikut membahas elemen untuk lebih memahami peran dan fungsinya dalam skenario ini.

Entri layanan

Mesh layanan membuat registry layanannya sendiri ke cluster Kubernetes. Bidang kontrol menggunakan registry ini untuk mengonfigurasi proxy side-car sebagai tabel pemilihan rute. Layanan yang berjalan di Kubernetes akan otomatis ditemukan dan ditambahkan ke registry mesh layanan. Layanan yang tidak berjalan di dalam cluster Kubernetes tidak dapat ditemukan secara otomatis, tetapi dapat ditentukan dengan menggunakan ServiceEntries. Dengan cara ini, klien dapat menggunakan entri sebagai nama host untuk terhubung ke layanan eksternal.

Di Anthos Service Mesh, nama domain yang sepenuhnya memenuhi syarat (FQDN) digunakan untuk mengidentifikasi semua layanan. FQDN adalah bagian terpenting dalam konstruksi ini karena sertifikat didasarkan pada nama host. Meskipun FQDN dapat diubah, Anda juga harus membuat ulang semua sertifikat yang diperlukan.

Untuk mengaktifkan komunikasi, Anda harus mengonfigurasi mesh layanan untuk memproses panggilan ke layanan eksternal agar dapat merutekan traffic dengan benar. Mesh memungkinkan Anda menentukan entri layanan yang mengarah ke layanan eksternal tersebut.

Konstruksi ini disebut MESH_EXTERNAL dan cocok untuk kasus penggunaan ini. Anda mungkin juga ingin menentukan apa yang Anda cari. Karena ini adalah kasus penggunaan L4 dan Anda hanya dapat mengontrol alamat IP dan port, Anda perlu memberi tahu protokol dan port tertentu ke mesh. Dalam hal ini, beri tahu TCP dan port 3306 (port protokol MySQL standar). Selain itu, pasangan sisi server (seperti yang ditunjukkan pada diagram sebelumnya) memproses port 13306 (gateway keluar dari cluster server). Terakhir, Anda harus memberi tahu entri layanan untuk merekam traffic dengan tag port ini.

Contoh entri layanan YAML berikut mengilustrasikan konfigurasi ini:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
 name: mysql-external
spec:
 hosts:
   - mysql.fqdn.example
 location: MESH_EXTERNAL
 ports:
   - number: 3306
     name: tcp
     protocol: TCP
   - number: 13306
     name: tls
     protocol: TLS
 resolution: DNS
 endpoints:
   - address: mysql.fqdn.example
     ports:
       tls: 13306

Dengan kolom hosts, Anda dapat menetapkan FQDN layanan eksternal, atau menentukan kolom location menjadi MESH_EXTERNAL. Anda juga harus menentukan nilai ports yang digunakan oleh layanan eksternal. Dalam hal ini, 13306 dan 3306. 13306 akan menjadi port yang diekspos dari gateway masuk sisi server. Penting untuk menentukan keduanya dalam entri layanan ini. Untuk protokol, Anda harus menentukan TLS, karena koneksi ini menyediakan komunikasi TLS berbasis L4.

Jika Anda telah menentukan entri layanan, mesh dapat memproses panggilan dan mengubah perutean berdasarkan aturan ini.

Entri layanan harus didasarkan pada entri alamat DNS atau IP yang ada, yang berarti nama DNS seharusnya sudah dapat diselesaikan oleh server DNS. Misalnya, Anda dapat menggunakan layanan DNS inti di dalam Kubernetes dan menambahkan entri ke layanan tersebut yang belum ada di kube-dns. Anda tidak dapat menggunakan entri layanan untuk membuat entri DNS.

Layanan virtual

Layanan virtual adalah definisi yang digunakan untuk memengaruhi pola perutean traffic. Gunakan layanan virtual untuk memastikan bahwa panggilan dari klien MySQL ke entri layanan dirutekan ke gateway keluar. Dengan demikian, Anda dapat menyiapkan layanan virtual untuk merutekan traffic berdasarkan faktor yang sangat berbeda. Dalam kasus penggunaan L7, faktor-faktor berikut ini melampaui routing traffic. Misalnya, Anda dapat memberi tahu layanan virtual tindakan apa yang diambil jika target tidak dapat dijangkau. Contoh ini menggunakan subset fungsi ini untuk merutekan traffic yang cocok hanya ke gateway keluar untuk pemrosesan lebih lanjut.

Diagram sebelumnya menunjukkan cara Anda menggunakan layanan virtual untuk merutekan traffic dari Pod melalui proxy ke gateway keluar dan dari gateway keluar ke layanan eksternal.

Anda juga harus menentukan port gateway keluar Anda (terbuka untuk eksternal), yaitu 15443 secara default. Port ini ditetapkan pada gateway keluar setelah Anda membuatnya. Anda dapat memilih port bebas lainnya, tetapi Anda harus mem-patch gateway untuk membuka port yang dipilih.

Cuplikan kode berikut menunjukkan seperti apa tampilan definisi layanan virtual tersebut:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: direct-mysql-through-egress-gateway
spec:
 hosts:
   - mysql.fqdn.example
 gateways:
   - istio-egressgateway-mysql
   - mesh
 tcp:
   - match:
       - gateways:
           - mesh
         port: 3306
     route:
       - destination:
           host: istio-egressgateway.istio-system.svc.cluster.local
           subset: mysql
           port:
             number: 15443
         weight: 100
   - match:
       - gateways:
           - istio-egressgateway-mysql
         port: 15443
     route:
       - destination:
           host: mysql.fqdn.example
           port:
             number: 13306
         weight: 100

Kolom hosts yang menyimpan URL FQDN digunakan untuk menerapkan aturan pencocokan secara khusus pada URL tertentu. Klausa match pertama ditentukan pada mesh, yang merupakan kata kunci tersimpan dan berlaku untuk semua gateway dalam mesh. Blok route pertama ditentukan untuk memberi tahu mesh tindakan yang harus dilakukan jika memang cocok. Dalam hal ini, Anda mengirim traffic yang cocok ke gateway keluar. Di sinilah port keluar didefinisikan sebagai tambahan untuk pembobotan untuk rute. Blok tersebut juga menyebutkan nilai subset, yang Anda tentukan nanti.

Klausa match kedua diterapkan ke gateway keluar. Blok route kedua yang ditambahkan ke klausa match kedua mengonfigurasi mesh untuk mengirim traffic ke traffic masuk cluster server menggunakan kolom host dengan FQDN traffic masuk dan dengan menentukan port 13306.

Untuk langkah berikutnya, Anda harus memprogram injeksi sertifikat ke dalam gateway agar komunikasi mTLS berfungsi.

Aturan tujuan

Setelah traffic teridentifikasi dengan benar (entri layanan) dan dirutekan dari Pod melalui proxy ke gateway (layanan virtual), langkah berikutnya adalah mengenkripsi traffic. Gunakan aturan tujuan untuk mengenkripsi traffic. Aturan tersebut dalam mesh layanan diterapkan pada traffic setelah perutean dan digunakan untuk memperkenalkan load balancing dan fungsi pengelolaan traffic lainnya.

Dalam hal ini, Anda perlu menggunakan aturan tujuan untuk menentukan pola load balancing standar dan menambahkan sertifikat guna mengaktifkan endpoint menggunakan komunikasi mTLS. Langkah ini dilakukan dengan mencocokkan FQDN server MySQL, yang diekspos melalui gateway masuk cluster server, dan menentukan aturan mTLS.

Definisi berikut adalah contoh aturan tujuan tersebut:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-mysql
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
    - name: mysql
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
        portLevelSettings:
          - port:
              number: 15443
            tls:
              mode: ISTIO_MUTUAL
              sni: mysql.fqdn.example

Kolom host disetel ke FQDN cluster untuk gateway keluar. Aturan tujuan pertama menjalankan enkripsi mesh bagian dalam untuk traffic menggunakan mode ISTIO_MUTUAL (menggunakan FQDN gateway keluar). Dalam cuplikan kode, Anda menentukan subset, yang digunakan untuk membuat load balancing round robin dan menetapkan (menimpa) port ke 15443. Gateway keluar menggunakan port ini untuk mengirim traffic.

Anda harus menetapkan kolom tls dengan benar karena kolom tersebut menentukan kebijakan mesh bagian dalam (ISTIO_MUTUAL). Di kolom sni (Indikasi Nama Layanan), tambahkan FQDN gateway masuk dari cluster server Anda.

Aturan tujuan kedua mengenkripsi traffic dengan sertifikat CA root khusus yang disediakan, sebelum mengirimkannya melalui gateway keluar:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: originate-mtls-for-mysql
spec:
 host: mysql.fqdn.example
 trafficPolicy:
   loadBalancer:
     simple: ROUND_ROBIN
   portLevelSettings:
   - port:
       number: 13306
     tls:
       mode: MUTUAL
       credentialName: client-credential
       sni: mysql.fqdn.example

Kolom host ditetapkan lagi ke FQDN eksternal. Kolom trafficPolicy menetapkan mode load balancer ke ROUND_ROBIN. Tindakan ini juga menyetel port ke 13306 dan mode tls ke MUTUAL, karena sekarang Anda menggunakan sertifikat root CA kustom dan pasangannya. Gateway masuk juga menggunakan tls MUTUAL, harus mengidentifikasi dirinya sendiri menggunakan sertifikat root CA bertanda tangan yang sama. Dengan menggunakan port ini, traffic dapat mengalir melalui cluster server melalui gateway masuknya untuk mencapai database MySQL.

Enkripsi yang menggunakan sertifikat root CA kustom biasanya dilakukan melalui Envoy Secret Discovery Service (SDS) dengan menggunakan secret di Kubernetes yang menyimpan sertifikat tersebut. Tambahkan nama rahasia ke aturan tujuan menggunakan kolom credentialName.

Singkatnya, traffic kini melakukan hal berikut:

• Dikeluarkan oleh MySQL secara transparan terhadap FQDN eksternal. FQDN ini ada di pendaftaran mesh.
• Data dienkripsi menggunakan aturan tujuan menggunakan sertifikat mesh internal.
• Dirutekan ke gateway oleh layanan virtual.
• CA ini dienkripsi menggunakan root CA kustom dengan aturan tujuan (ini berbeda dengan CA mesh yang digunakan untuk sertifikat mesh).
• Pesan ini diteruskan melalui gateway keluar dalam mode mTLS.

Sisi server

Dalam skenario ini, sisi server lebih mudah dikonfigurasi daripada sisi klien. Yang diperlukan hanyalah gateway masuk dan entri layanan virtual untuk merutekan traffic ke server MySQL DB, seperti yang ditunjukkan pada diagram berikut ini.

Gateway masuk cluster server

Gateway masuk mengekspos port 13306. Port ini dapat berupa port apa pun, tetapi dalam hal ini, penambahan "1" di depan port MySQL standar untuk identifikasi yang lebih mudah. Untuk alasan keamanan, sebaiknya jangan mengekspos port MySQL standar (3306) langsung ke internet.

Karena gateway masuk Istio default tidak memproses port 13306, Anda perlu menambahkan fungsi ini. Contoh cuplikan kode berikut mem-patch port 13306 ke gateway:

[{
  "op": "add",
  "path": "/spec/ports/0",
  "value": {
    "name": "tls-mysql",
    "protocol": "TCP",
    "targetPort": 13306,
    "port": 13306
  }
}]

Anda dapat menyimpan kode ini dalam file JSON dan menggunakannya dengan perintah patch kubectl untuk menerapkannya ke layanan gateway masuk.

Untuk memproses traffic dengan benar, gateway masuk harus disiapkan dalam mode MUTUAL.

Pada tahap ini, gateway masuk mendekripsi traffic masuk menggunakan sertifikat dari penyimpanan kredensialnya dan mengirimkan traffic ke mesh, tempat sertifikat internal mesh digunakan untuk mengenkripsi ulang traffic. Contoh cuplikan kode berikut menunjukkan cara mengonfigurasinya:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: gateway-mysql
spec:
 selector:
   istio: ingressgateway # Istio default gateway implementation
 servers:
 - port:
     number: 13306
     name: tls-mysql
     protocol: TLS
   tls:
     mode: MUTUAL
     credentialName: mysql-credential
   hosts:
   - "mysql.fqdn.example"

Dalam contoh ini, gateway masuk Istio standar digunakan di bawah kolom selector. Dengan menggunakan kolom servers, Anda dapat menetapkan nilai port number (13306) dan protocol (TLS) yang diperkirakan oleh traffic masuk. Sebaiknya beri nama port yang unik.

Tentukan tls dan berikan rahasia berisi sertifikat yang ditandatangani oleh root CA yang sama seperti yang digunakan dengan gateway keluar yang menggunakan kolom credentialName. Sertifikat harus disimpan dalam rahasia Kubernetes.

Terakhir, cocokkan traffic yang mengarahkan DB FQDN MySQL. Resolusi nama untuk FQDN ini yang ditetapkan pada hosts harus ditetapkan ke alamat IP publik gateway masuk.

Layanan virtual cluster server

Setelah traffic masuk ke mesh melalui port 13306, yang berasal dari gateway keluar cluster klien (sumber), Anda harus mengidentifikasi traffic ini dan memastikan traffic tersebut menjangkau server DB MySQL. Lakukan hal ini dengan menentukan layanan virtual:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: mysql-virtual-service
spec:
 hosts:
   - "mysql.fqdn.example"
 gateways:
   - gateway-mysql
 tcp:
   - route:
     - destination:
         port:
           number: 3306
         host: mysql.default.svc.cluster.local

Untuk mengirim traffic ke layanan MySQL DB, Anda harus memeriksa host FQDN lagi menggunakan kolom hosts. Selain itu, Anda harus menggunakan kolom gateways untuk mengonfigurasi tempat untuk menerapkan definisi layanan virtual ini. Ini adalah objek gateway yang Anda tentukan dalam file YAML sebelumnya. Tetapkan kolom tcp, karena ini adalah traffic L4, dan tetapkan kolom route untuk mengarah ke layanan Kubernetes DB MySQL. Anda harus menentukan nama layanan pada kolom host menggunakan FQDN internal cluster Kubernetes.

DB MySQL dapat memperoleh permintaan dari klien pada port 3306. Traffic melintasi proxy sidecar server DB MySQL. Untuk server DB MySQL, terlihat seperti permintaan lokal yang tidak terenkripsi untuk mengakses database.

Setelah server menjawab panggilan, traffic akan mengalir kembali ke klien menggunakan rute yang sama dan untuk klien, hal ini akan terlihat seolah-olah DB lokal baru saja menjawab panggilannya.

Traffic dienkripsi tiga kali menggunakan sertifikat berbeda yang melintas dari klien ke server, yang membantu mengamankan komunikasi klien-server.

Saat pertama kali traffic dienkripsi atau didekripsi, berada di dalam mesh di sisi klien dengan sertifikat menggunakan CA mesh.

Kedua kalinya traffic dienkripsi saat meninggalkan mesh di gateway keluar menggunakan sertifikat dari root CA kustom. Kemudian, traffic akan diautentikasi dan didekripsi pada gateway masuk menggunakan sertifikat yang ditandatangani oleh root CA kustom yang sama.

Terakhir (ketiga) kalinya traffic dienkripsi atau didekripsi di dalam mesh di sisi server saat traffic dari gateway masuk ke server MySQL. Sekali lagi di sini (karena mesh internal), sertifikat CA mesh digunakan.

Dalam skenario ini - komunikasi antara dua cluster harus dienkripsi menggunakan root CA yang disebutkan. Dengan menerapkan konfigurasi ini, bagian ini dapat ditangani secara terpisah dan mandiri dari sertifikat internal mesh dan dari aplikasi itu sendiri.

Dengan melakukan langkah tambahan ini, konfigurasi ini juga memudahkan Anda merotasi sertifikat ini secara rutin tanpa mengubah CA mesh dari masing-masing cluster Kubernetes.

Langkah selanjutnya

• Coba tutorial pendamping.
• Baca panduan hardening GKE.
• Pelajari cara mengelola konfigurasi dan kebijakan di seluruh infrastruktur Anda dengan Pengelolaan Konfigurasi.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.