Praktik Terbaik untuk menggunakan gateway keluar Cloud Service Mesh di cluster GKE

Dokumen ini menjelaskan cara menggunakan gateway keluar Cloud Service Mesh dan kontrol Google Cloud lainnya untuk mengamankan traffic keluar (keluar) dari workload yang di-deploy di cluster Google Kubernetes Engine (GKE). Kontrol ini dapat membatasi koneksi ke layanan eksternal berdasarkan identitas aplikasi sumber, namespace tim, domain tujuan, dan properti lain dari permintaan keluar.

Ada tutorial pendamping yang dapat Anda gunakan sebagai cetak biru untuk mengonfigurasi kontrol keluar di cluster Anda sendiri.

Audiens yang diinginkan untuk dokumen ini meliputi engineer jaringan, platform, dan keamanan yang mengelola cluster GKE yang digunakan oleh satu atau beberapa tim pengiriman software. Kontrol yang dijelaskan di sini dapat sangat berguna untuk organisasi yang harus menunjukkan kepatuhan terhadap peraturan (misalnya GDPR dan PCI).

Pengantar

Pendekatan tradisional untuk keamanan jaringan adalah menentukan perimeter keamanan di sekitar sekelompok aplikasi. Firewall digunakan pada perimeter ini untuk mengizinkan atau menolak traffic berdasarkan alamat IP sumber dan tujuan, sekaligus memercayai aplikasi dan traffic yang terdapat dalam perimeter tersebut. Namun, kepercayaan ini melibatkan risiko. Orang dalam yang berbahaya, atau siapa pun yang menyusupi perimeter dapat bergerak bebas di dalam jaringan, mengakses dan memindahkan data secara tidak sah, menyerang sistem pihak ketiga, dan mengganggu sistem administrasi.

Saat workload yang berjalan di cluster Kubernetes membuat koneksi keluar ke host di internet, penerapan kontrol keamanan berbasis IP tradisional dapat menjadi rumit karena:

  • Alamat IP pod tidak cukup mewakili identitas workload yang membuat koneksi. Di lingkungan Kubernetes, alamat IP Pod ditetapkan secara sementara dan sering didaur ulang saat Pod masuk dan hilang.

  • Sering kali tidak mungkin mengidentifikasi kumpulan alamat IP yang kecil dan tetap untuk host tujuan tertentu. Alamat IP sering berubah, bervariasi menurut wilayah, dan dapat diambil dari rentang yang besar atau mewakili cache, proxy, atau CDN.

  • Beberapa tim yang berbagi cluster multi-tenant yang sama dengan rentang IP sumber bersama mungkin memiliki persyaratan konektivitas eksternal yang berbeda.

Cloud Service Mesh adalah distribusi jaringan layanan Istio open source yang didukung penuh Google. Mesh layanan menyediakan cara yang seragam untuk menghubungkan, mengelola, dan mengamankan komunikasi aplikasi. Mesh layanan mengambil pendekatan yang berfokus pada aplikasi dan menggunakan identitas aplikasi tepercaya, bukan pendekatan yang berfokus pada IP jaringan.

Anda dapat men-deploy mesh layanan secara transparan tanpa perlu mengubah kode aplikasi yang ada. Penggunaan mesh layanan membantu memisahkan tugas tim pengembangan yang bertanggung jawab untuk mengirimkan dan merilis fitur aplikasi, dari tanggung jawab administrator jaringan dengan menyediakan kontrol deklaratif atas perilaku jaringan.

Cloud Service Mesh menyediakan opsi untuk men-deploy proxy maju mandiri,yang dikenal sebagai gateway keluar, di tepi mesh. Panduan ini menjelaskan cara menggabungkan fitur proxy gateway keluar dengan fitur Google Cloud untuk mengontrol, memberi otorisasi, dan mengamati traffic keluar dari workload yang di-deploy ke cluster GKE.

komponen konseptual

Arsitektur defense-in-depth

Diagram di bawah menunjukkan arsitektur yang menggunakan pendekatan defense in depth terhadap kontrol terperinci traffic keluar untuk cluster yang digunakan oleh beberapa tim. Kontrol ini didasarkan pada kontrol jaringan Lapisan 4 (transpor) dan Lapisan 7 (aplikasi).

arsitektur secara keseluruhan

Arsitektur ini menggunakan resource dan kontrol berikut:

  • Cluster GKE pribadi: Node di cluster GKE pribadi hanya memiliki alamat IP internal dan tidak terhubung ke internet secara default.

  • Cloud NAT: Cloud NAT memungkinkan akses internet keluar dari cluster pribadi.

  • Aturan firewall Virtual Private Cloud (VPC): Anda mengonfigurasi aturan firewall VPC untuk menerapkan kontrol Lapisan 4 (Transport) ke koneksi ke dan dari node di cluster GKE. Anda dapat menerapkan aturan firewall VPC ke VM berdasarkan akun layanan atau tag jaringan.

  • Node pool dengan akun layanan yang berbeda: Hal ini memungkinkan Anda mengonfigurasi aturan firewall yang berbeda untuk diterapkan, bergantung pada kumpulan node yang mencakup node.

  • Namespace Kubernetes: Anda membuat namespace untuk setiap tim guna menyediakan isolasi dan kontrol administratif yang didelegasikan. Administrator jaringan menggunakan namespace khusus untuk men-deploy gateway keluar dan mengonfigurasi perutean ke host eksternal.

  • Kebijakan jaringan Kubernetes: Kebijakan jaringan memungkinkan Anda menerapkan kontrol Lapisan 4 ke Pod. Setiap kebijakan jaringan dibatasi untuk namespace dan dapat dicakup secara lebih terperinci ke Pod tertentu dalam namespace.

  • Gateway keluar: Traffic yang keluar dari Pod dalam mesh diarahkan melalui proxy gateway keluar khusus yang berjalan di node khusus. Anda men-deploy gateway keluar dengan autoscaler Pod horizontal sehingga jumlah replika naik dan turun seiring dengan traffic.

  • Kebijakan otorisasi: Anda menggunakan kebijakan otorisasi mesh untuk menerapkan kontrol Lapisan 7 (aplikasi) ke traffic antara Pod dalam mesh dan ke traffic yang keluar dari mesh.

  • Resource file bantuan: Anda menggunakan resource file bantuan untuk mengontrol cakupan konfigurasi proxy file bantuan yang berjalan di setiap Pod workload. Anda dapat menggunakan resource Sidecar untuk mengonfigurasi namespace, Pod, dan layanan eksternal yang terlihat oleh beban kerja.

  • Akses Google Pribadi: Opsi ini memungkinkan node dan Pod di cluster pribadi mengakses Google API dan mengambil image Docker dari Container Registry.

  • GKE Workload Identity: Dengan Workload Identity, Anda dapat menggunakan Identity and Access Management (IAM) untuk memberikan izin API ke beban kerja tertentu dengan mengikuti prinsip hak istimewa terendah, tanpa perlu menangani secret.

Mengonfigurasi kontrol keluar

Jika Anda menggunakan gateway keluar untuk mengamankan traffic keluar dari mesh, sebaiknya konfigurasi kontrol defense in depth yang dijelaskan di bagian ini.

Menggunakan Private GKE dengan Cloud NAT

Jika keamanan penting, persyaratan pertama banyak organisasi adalah menghindari penetapan alamat IP publik ke workload mereka. Cluster GKE pribadi memenuhi persyaratan ini. Anda dapat mengonfigurasi mode VPC Native di cluster pribadi sehingga Pod dan layanan diberi alamat IP dari rentang sekunder di VPC. Alamat IP Pod Native VPC dapat dirutekan secara native dalam jaringan VPC.

Beberapa workload mungkin memerlukan akses ke layanan di luar jaringan VPC dan ke internet. Agar workload dapat terhubung ke host eksternal tanpa mengharuskannya memiliki alamat IP publik, konfigurasikan Cloud NAT untuk menyediakan penafsiran alamat jaringan (NAT).

Pastikan Cloud NAT terkonfigurasi agar gateway keluar dapat membuat jumlah koneksi simultan yang cukup ke tujuan eksternal. Anda dapat menghindari kehabisan port dan masalah penundaan penggunaan ulang koneksi dengan menetapkan jumlah minimum port per VM secara tepat. Baca ringkasan alamat dan port Cloud NAT untuk mengetahui detail selengkapnya. Peningkatan jumlah replika gateway keluar dapat membantu mengurangi kemungkinan konflik pemetaan independen endpoint.

Mengonfigurasi Akses Google Pribadi untuk Google API dan layanan Google

Sepertinya workload Anda perlu memiliki akses ke Google API dan layanan Google. Gunakan Akses Google Pribadi dengan Zona DNS kustom untuk mengizinkan konektivitas dari subnet VPC pribadi ke Google API menggunakan kumpulan empat alamat IP. Saat menggunakan alamat IP ini, Pod tidak perlu memiliki alamat IP eksternal dan traffic tidak pernah keluar dari jaringan Google. Anda dapat menggunakan private.googleapis.com (199.36.153.8/30) atau restricted.googleapis.com (199.36.153.4/30), bergantung pada apakah Anda menggunakan Kontrol Layanan VPC atau tidak.

Menggunakan Workload Identity dan IAM untuk meningkatkan keamanan Google API dan layanan Google

Penggunaan Workload Identity adalah cara yang direkomendasikan untuk mengizinkan workload GKE melakukan autentikasi dengan Google API dan bagi administrator untuk menerapkan kontrol otorisasi "hak istimewa terendah" menggunakan IAM.

Saat menggunakan Akses Google Pribadi, Workload Identity, dan IAM, Anda dapat mengizinkan Pod workload dengan aman untuk melewati gateway keluar dan terhubung langsung ke Google API dan layanan Google.

Menggunakan namespace Kubernetes untuk kontrol administratif

Namespace adalah resource organisasi yang sangat membantu di lingkungan yang memiliki banyak pengguna, tim, atau tenant. Mereka dapat dianggap sebagai cluster virtual, dan memungkinkan tanggung jawab administratif untuk grup resource Kubernetes didelegasikan ke administrator yang berbeda.

Namespace adalah fitur penting untuk mengisolasi kontrol administratif. Namun, secara default keduanya tidak menyediakan isolasi node, isolasi bidang data, atau isolasi jaringan.

Cloud Service Mesh dibuat berdasarkan namespace Kubernetes dengan menggunakannya sebagai unit tenancy dalam mesh layanan. Kebijakan otorisasi mesh dan resource file bantuan dapat membatasi visibilitas dan akses berdasarkan atribut namespace, identitas, dan Lapisan 7 (aplikasi) dari traffic jaringan.

Demikian pula, Anda dapat menggunakan kebijakan jaringan Kubernetes untuk mengizinkan atau menolak koneksi jaringan di Lapisan 4 (transpor).

Menjalankan gateway keluar pada node gateway khusus

Menjalankan gateway keluar pada node dalam kumpulan node gateway khusus memberikan beberapa keuntungan. Node yang berinteraksi secara eksternal dapat menggunakan konfigurasi yang di-hardening, dan Anda dapat mengonfigurasi aturan firewall VPC untuk mencegah workload menjangkau host eksternal secara langsung. Kumpulan node dapat diskalakan secara otomatis secara independen menggunakan skala otomatis cluster.

Untuk mengizinkan kontrol administratif terpisah dari gateway keluar, deploy gateway tersebut ke namespace istio-egress khusus. Namun, namespace adalah resource seluruh cluster dan tidak dapat menggunakannya untuk mengontrol node mana yang digunakan untuk menjalankan deployment. Untuk kontrol deployment, gunakan pemilih node untuk deployment gateway keluar sehingga berjalan pada node yang diberi label sebagai anggota kumpulan node gateway.

Memastikan bahwa hanya Pod gateway yang dapat berjalan pada node gateway. Pod lainnya harus ditolak dari node gateway. Jika tidak, kontrol keluar dapat diabaikan. Workload dapat dicegah agar tidak dijalankan pada node tertentu dengan menggunakan taint dan toleransi. Anda harus mencemari node di kumpulan node gateway dan menambahkan toleransi yang sesuai ke penerapan gateway egress.

Menerapkan aturan firewall VPC ke node tertentu

Anda mengonfigurasi pemilihan rute mesh layanan untuk mengarahkan traffic keluar dari workload yang berjalan di kumpulan node default melalui gateway keluar yang berjalan di kumpulan node gateway. Namun, konfigurasi perutean mesh tidak boleh dipercaya sebagai batasan keamanan karena ada berbagai cara yang dapat membuat beban kerja mengabaikan proxy mesh.

Untuk mencegah workload aplikasi terhubung langsung ke host eksternal, terapkan aturan firewall keluar terbatas ke node dalam kumpulan node default. Terapkan aturan firewall terpisah ke node gateway sehingga Pod gateway keluar yang berjalan di pod tersebut dapat terhubung ke host eksternal.

Saat membuat aturan firewall VPC, Anda menentukan port dan protokol yang diizinkan atau ditolak oleh aturan firewall, serta arah traffic yang memberlakukannya. Aturan traffic keluar berlaku untuk traffic keluar, sedangkan aturan masuk berlaku untuk traffic masuk. Default untuk traffic keluar adalah allow dan default untuk traffic masuk adalah deny.

Aturan firewall diterapkan secara berurutan berdasarkan nomor prioritas yang dapat Anda tentukan. Aturan firewall bersifat stateful, yang berarti jika traffic tertentu dari VM diizinkan, traffic yang ditampilkan menggunakan koneksi yang sama juga akan diizinkan.

Diagram berikut menunjukkan cara penerapan aturan firewall terpisah ke node dalam dua kumpulan node yang berbeda berdasarkan akun layanan yang ditetapkan ke sebuah node. Dalam hal ini, aturan firewall deny all default menolak akses keluar untuk seluruh VPC. Agar tidak mengganti aturan firewall default yang penting bagi cluster Anda untuk beroperasi, aturan deny all harus menggunakan prioritas rendah, seperti 65535. Aturan firewall keluar dengan prioritas yang lebih tinggi dan tambahan diterapkan ke node gateway untuk memungkinkan terhubung langsung ke host eksternal pada port 80 dan 443. Kumpulan node default tidak memiliki akses ke host eksternal.

kumpulan node firewall

Menggunakan kebijakan Jaringan Kubernetes sebagai firewall untuk Pod dan namespace

Gunakan kebijakan jaringan Kubernetes untuk menerapkan lapisan keamanan ekstra sebagai bagian dari strategi defense in depth. Kebijakan jaringan mencakup namespace dan beroperasi di Lapisan 4 (transportasi). Dengan kebijakan jaringan, Anda dapat membatasi traffic masuk dan keluar:

  • Di antara namespace
  • Ke Pod dalam namespace
  • Ke porta dan blok IP tertentu.

Setelah kebijakan jaringan memilih Pod di namespace, koneksi apa pun yang tidak diizinkan secara eksplisit akan ditolak. Jika beberapa kebijakan jaringan diterapkan, hasilnya adalah tambahan dan merupakan gabungan dari kebijakan. Urutan kebijakan yang diterapkan tidak menjadi masalah.

Tutorial pendamping menyertakan contoh kebijakan jaringan berikut:

  • Izinkan koneksi keluar dari namespace workload ke namespace istio-system dan istio-egress. Pod harus dapat terhubung ke istiod dan gateway keluar.
  • Izinkan workload membuat kueri DNS dari namespace workload ke port 53 di namespace kube-system.
  • Atau, izinkan beban kerja di namespace yang sama untuk saling terhubung.
  • Secara opsional, izinkan koneksi keluar antara namespace yang digunakan oleh tim aplikasi yang berbeda.
  • Izinkan koneksi keluar dari namespace workload ke VIP untuk Google API (ditampilkan dengan menggunakan Akses Google Pribadi). Cloud Service Mesh menyediakan CA terkelola dan menampilkannya sebagai API, sehingga proxy file bantuan harus dapat terhubung ke CA tersebut. Beberapa workload juga mungkin memerlukan akses ke Google API.
  • Izinkan koneksi keluar dari namespace workload ke server metadata GKE sehingga proxy file bantuan dan workload dapat membuat kueri metadata dan melakukan autentikasi ke Google API.

Secara default, saat proxy file bantuan dimasukkan ke dalam Pod workload, aturan iptables akan diprogram sehingga proxy tersebut menangkap semua traffic TCP masuk dan keluar. Namun, seperti yang disebutkan sebelumnya, ada cara bagi workload untuk mengabaikan proxy. Aturan firewall VPC mencegah akses keluar langsung dari node default yang menjalankan workload. Anda dapat menggunakan kebijakan jaringan Kubernetes untuk memastikan tidak ada traffic keluar eksternal langsung yang dapat terjadi dari namespace workload dan bahwa traffic keluar dapat ke namespace istio-egress.

Jika Anda juga mengontrol traffic masuk dengan kebijakan jaringan, Anda perlu membuat kebijakan traffic masuk agar sesuai dengan kebijakan traffic keluar Anda.

Konfigurasi dan keamanan Anthos Service Mesh

Workload yang berjalan di mesh layanan tidak diidentifikasi berdasarkan alamat IP-nya. Cloud Service Mesh menetapkan identitas yang kuat dan dapat diverifikasi dalam bentuk sertifikat dan kunci X.509 untuk setiap workload. Komunikasi tepercaya antar-beban kerja dibuat menggunakan koneksi mutual TLS (mTLS) yang diautentikasi dan dienkripsi.

Penggunaan autentikasi mTLS dengan identitas yang jelas untuk setiap aplikasi memungkinkan Anda menggunakan kebijakan otorisasi mesh untuk kontrol mendetail atas cara beban kerja dapat berkomunikasi dengan layanan eksternal.

Meskipun traffic dapat meninggalkan mesh langsung dari proxy file bantuan, jika Anda memerlukan kontrol tambahan, sebaiknya arahkan traffic melalui gateway keluar seperti yang dijelaskan dalam panduan ini.

Mengelola konfigurasi untuk kontrol keluar dalam namespace khusus

Izinkan administrator jaringan mengelola kontrol secara terpusat menggunakan namespace istio-egress khusus untuk konfigurasi mesh terkait keluar. Seperti yang direkomendasikan sebelumnya, Anda men-deploy gateway keluar ke namespace istio-egress. Anda dapat membuat dan mengelola entri layanan, gateway, dan kebijakan otorisasi dalam namespace ini.

Mewajibkan konfigurasi eksplisit tujuan eksternal

Pastikan proxy mesh hanya diprogram dengan rute ke host eksternal yang ditentukan secara eksplisit dalam registry mesh layanan. Tetapkan mode kebijakan traffic keluar ke REGISTRY_ONLY di resource bantuan default untuk setiap namespace. Menetapkan kebijakan traffic keluar untuk mesh tidak boleh, secara mandiri, dianggap sebagai kontrol perimeter yang aman.

Menentukan tujuan eksternal dengan Entri Layanan

Konfigurasikan Service Entries untuk mendaftarkan host eksternal secara eksplisit di registry layanan mesh. Secara default, entri layanan dapat dilihat oleh semua namespace. Gunakan atribut eksporTo untuk mengontrol namespace tempat entri layanan dapat dilihat. Entri Layanan menentukan rute keluar yang dikonfigurasi di proxy mesh, tetapi tidak boleh dianggap sebagai kontrol yang aman untuk menentukan workload host eksternal mana yang dapat terhubung.

Mengonfigurasi perilaku gateway keluar dengan resource Gateway

Konfigurasikan perilaku load balancing gateway keluar menggunakan resource Gateway. Load balancer dapat dikonfigurasi untuk sekumpulan host, protokol, dan port tertentu, serta dikaitkan dengan deployment gateway keluar. Misalnya, gateway dapat dikonfigurasi untuk traffic keluar ke port 80 dan 443 untuk host eksternal apa pun.

Di Cloud Service Mesh 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy file bantuan klien akan otomatis mendeteksi apakah server memiliki file bantuan. File bantuan klien mengirimkan mTLS ke workload dengan file bantuan dan mengirimkan traffic teks biasa ke workload tanpa file bantuan. Meskipun dengan mTLS otomatis, traffic yang dikirim ke gateway keluar dari proxy file bantuan tidak otomatis menggunakan mTLS. Untuk menunjukkan cara mengamankan koneksi ke gateway keluar, Anda harus menyetel mode TLS di resource Gateway. Jika memungkinkan, gunakan mTLS untuk koneksi dari proxy file bantuan ke gateway keluar.

Anda dapat mengizinkan workload memulai koneksi TLS (HTTPS) sendiri. Jika workload berasal dari koneksi TLS, biasanya di port 443, Anda harus mengonfigurasi gateway agar menggunakan mode passthrough untuk koneksi pada port tersebut. Namun, penggunaan mode passthrough berarti gateway tidak dapat menerapkan kebijakan otorisasi berdasarkan identitas workload atau properti permintaan yang dienkripsi. Selain itu, saat ini, Anda tidak dapat menggunakan mTLS dan passthrough secara bersamaan.

{i>tls pass through<i}

Mengonfigurasi Layanan Virtual dan Aturan Tujuan untuk mengarahkan traffic melalui gateway

Gunakan Layanan Virtual dan Aturan Tujuan untuk mengonfigurasi perutean traffic dari proxy file bantuan melalui gateway keluar ke tujuan eksternal. Layanan virtual menentukan aturan untuk mencocokkan traffic tertentu. Traffic yang cocok kemudian dikirim ke tujuan. Aturan tujuan dapat menentukan subset (misalnya, gateway keluar atau host eksternal) dan cara penanganan traffic saat dirutekan ke tujuan.

Gunakan aturan tujuan tunggal untuk beberapa host tujuan untuk secara eksplisit menentukan cara pengamanan traffic dari proxy file bantuan ke gateway. Seperti yang dijelaskan sebelumnya, metode yang direkomendasikan adalah agar workload mengirim permintaan teks biasa dan proxy file bantuan untuk memulai koneksi mTLS ke gateway.

Gunakan aturan tujuan untuk setiap host eksternal guna mengonfigurasi gateway keluar ke 'upgrade' permintaan HTTP biasa agar menggunakan koneksi TLS (HTTPS) saat meneruskan ke tujuan. Mengupgrade koneksi teks biasa ke TLS sering disebut sebagai asal TLS.

Mengontrol cakupan konfigurasi proxy dengan Resource Sidecar

Konfigurasikan resource file bantuan default untuk setiap namespace guna mengontrol perilaku proxy file bantuan. Gunakan properti keluar dari resource Sidecar untuk mengontrol dan meminimalkan host tujuan yang dikonfigurasi di pemroses keluar proxy. Konfigurasi minimal standar dapat menyertakan tujuan berikut untuk setiap namespace:

  • Pod dalam namespace yang sama
  • Google API dan Layanan Google
  • Server metadata GKE
  • Host eksternal tertentu yang telah dikonfigurasi menggunakan entri layanan

Konfigurasi pemroses keluar di proxy file bantuan tidak boleh dianggap sebagai kontrol keamanan secara mandiri.

Praktik terbaiknya adalah menggunakan resource file bantuan untuk membatasi ukuran konfigurasi proxy. Secara default, setiap proxy file bantuan dalam mesh dikonfigurasi untuk memungkinkannya mengirimkan traffic ke setiap proxy lainnya. Konsumsi memori proxy file bantuan dan bidang kontrol dapat dikurangi secara signifikan dengan membatasi konfigurasi proxy hanya kepada host yang perlu berkomunikasi dengannya.

Menggunakan Kebijakan Otorisasi untuk mengizinkan atau menolak traffic di gateway keluar

AuthorizationPolicy adalah resource yang memungkinkan Anda mengonfigurasi kebijakan kontrol akses terperinci untuk traffic mesh. Anda dapat membuat kebijakan untuk mengizinkan atau menolak traffic berdasarkan properti sumber, tujuan, atau traffic itu sendiri (misalnya, host atau header permintaan HTTP).

Untuk mengizinkan atau menolak koneksi berdasarkan namespace atau identitas workload sumber, koneksi ke gateway keluar harus diautentikasi dengan mTLS. Koneksi dari file bantuan ke gateway keluar tidak otomatis menggunakan mTLS, sehingga aturan tujuan untuk koneksi ke gateway harus secara eksplisit menentukan mode TLS ISTIO_MUTUAL.

Untuk mengizinkan atau menolak permintaan di gateway menggunakan kebijakan otorisasi, workload harus mengirim permintaan HTTP biasa ke tujuan di luar mesh. Proxy file bantuan kemudian dapat meneruskan permintaan ke gateway menggunakan mTLS dan gateway dapat memulai koneksi TLS yang aman ke host eksternal.

Untuk mendukung persyaratan traffic keluar bagi berbagai tim dan aplikasi, konfigurasikan kebijakan otorisasi "hak istimewa terendah" yang terpisah per namespace atau beban kerja. Misalnya, berbagai kebijakan dapat diterapkan di gateway keluar dengan menentukan aturan berdasarkan namespace workload sumber dan atribut permintaan sebagai berikut:

  • Jika namespace sumber adalah team-x DAN host tujuan adalah example.com, maka allow traffic.

    contoh kebijakan otorisasi

  • Jika namespace sumber adalah team-y DAN host tujuan adalah httpbin.org DAN jalurnya adalah /status/418, berarti allow traffic.

    kebijakan otorisasi menggunakan httpbin

Semua permintaan lainnya ditolak.

Konfigurasikan gateway keluar untuk memulai koneksi TLS (HTTPS) ke tujuan

Konfigurasikan aturan tujuan agar gateway keluar berasal dari koneksi TLS (HTTPS) ke tujuan eksternal.

Agar asal TLS di gateway keluar dapat berfungsi, workload harus mengirim permintaan HTTP biasa. Jika beban kerja memulai TLS, gateway keluar akan menggabungkan TLS di atas TLS asli, dan permintaan ke layanan eksternal akan gagal.

Karena beban kerja mengirim permintaan HTTP biasa, konfigurasikan proxy sidecar workload untuk membuat koneksi mTLS saat mengirimkannya ke gateway. Gateway keluar kemudian menghentikan koneksi mTLS dan memulai koneksi TLS (HTTPS) reguler ke host tujuan.

Asal TLS di gateway keluar

Pendekatan ini memiliki beberapa manfaat:

  • Anda dapat menggunakan kebijakan otorisasi untuk mengizinkan atau menolak traffic berdasarkan atribut workload sumber dan permintaan.

  • Traffic antara Pod workload dan gateway keluar dienkripsi dan diautentikasi (mTLS) dan traffic antara gateway keluar dan tujuan dienkripsi (TLS/HTTPS).

  • Di dalam mesh, proxy file bantuan dapat mengamati dan bertindak berdasarkan properti permintaan HTTP (misalnya, header), yang memberikan opsi tambahan untuk kemampuan observasi dan kontrol.

  • Kode aplikasi dapat disederhanakan. Developer tidak perlu menangani sertifikat atau library klien HTTPS, dan mesh layanan dapat memastikan komunikasi yang aman dengan cipher standar dan terbaru.

  • Koneksi TLS yang berasal dari gateway keluar ke layanan eksternal dapat digunakan kembali untuk traffic dari banyak Pod. Penggunaan ulang koneksi lebih efisien dan mengurangi risiko tercapainya batas koneksi.

DNS, nama host, dan karakter pengganti

Saat mengarahkan, menolak, atau mengizinkan traffic berdasarkan host tujuan, Anda harus memiliki kepercayaan penuh terhadap integritas sistem DNS untuk me-resolve nama DNS ke alamat IP yang benar. Di cluster Kubernetes Engine, layanan DNS Kubernetes menangani kueri DNS dan kemudian mendelegasikan kueri eksternal ke server metadata GKE dan DNS Internal. Tetapkan atribut resolusi entri layanan ke DNS saat mengarahkan ke host eksternal, sehingga proxy file bantuan bertanggung jawab untuk membuat kueri DNS.

Cloud Service Mesh dapat merutekan traffic berdasarkan host karakter pengganti. Kasus yang paling sederhana adalah karakter pengganti untuk host yang memiliki nama yang sama dan dihosting di kumpulan server umum. Misalnya, jika satu kumpulan server dapat menayangkan domain yang cocok dengan *.example.com, host karakter pengganti dapat digunakan.

Gateway keluar standar tidak dapat diteruskan berdasarkan host karakter pengganti yang lebih umum dan arbitrer (misalnya, *.com) karena ada batasan tertentu pada proxy Envoy yang digunakan oleh Istio. Envoy hanya dapat merutekan traffic ke host yang telah ditetapkan, alamat IP yang telah ditetapkan, atau ke alamat IP tujuan asli dari suatu permintaan. Saat menggunakan gateway keluar, IP tujuan asli permintaan akan hilang karena diganti dengan IP gateway dan host tujuan arbitrer tidak dapat dikonfigurasi sebelumnya.

Penegakan administratif terhadap kebijakan

Menggunakan Role Based Access Control (RBAC) Kubernetes

Hanya administrator yang diotorisasi yang dapat mengonfigurasi kontrol keluar. Konfigurasikan Kubernetes Role Based Access Control (RBAC) untuk menghindari pengelakan kontrol traffic keluar tanpa izin. Terapkan peran RBAC sehingga hanya administrator jaringan yang dapat mengelola namespace istio-egress,istio-system, dan kube-system serta resource berikut:

  • File bantuan
  • ServiceEntry
  • Gateway
  • AuthorizationPolicy
  • NetworkPolicy

Membatasi penggunaan toleransi

Seperti dijelaskan sebelumnya, Anda dapat menggunakan taint dan toleransi untuk mencegah Pod workload di-deploy pada node gateway. Namun, secara default, tidak ada yang bisa mencegah deployment workload dengan toleransi untuk node gateway sehingga memungkinkan mengabaikan kontrol keluar. Jika kontrol administratif terpusat atas pipeline deployment dapat diterapkan, Anda dapat menggunakannya untuk menerapkan batasan pada penggunaan kunci toleransi tertentu.

Pendekatan lainnya adalah menggunakan kontrol penerimaan Kubernetes. Anthos menyertakan komponen bernama Pengontrol Kebijakan yang bertindak sebagai pengontrol penerimaan Kubernetes dan memvalidasi bahwa deployment tersebut memenuhi batasan kebijakan yang Anda tentukan.

Memastikan traffic dicatat

Anda sering kali perlu mencatat semua traffic yang melintasi perimeter jaringan. Logging traffic sangat penting jika Anda harus dapat menunjukkan kepatuhan terhadap peraturan perlindungan data umum. Log traffic dikirim langsung ke Cloud Logging dan dapat diakses dari dasbor Cloud Service Mesh di Konsol Google Cloud. Anda dapat memfilter log berdasarkan berbagai atribut, termasuk sumber/tujuan, identitas, namespace, atribut traffic, dan latensi.

Untuk memudahkan proses debug dengan kubectl, aktifkan logging traffic ke stdout saat menginstal Cloud Service Mesh menggunakan setelan accessLogFile.

Log audit dikirim ke Cloud Logging setiap kali Mesh CA membuat sertifikat untuk beban kerja.

Pertimbangkan untuk menggunakan cluster terpisah untuk gateway keluar dalam mesh multi-cluster

Cloud Service Mesh dapat di-deploy di lebih dari satu cluster GKE. Mesh multi-cluster memperkenalkan kemungkinan baru untuk mengontrol traffic keluar dan juga beberapa batasan.

Daripada men-deploy gateway keluar ke kumpulan node khusus, Anda dapat men-deploy gateway tersebut ke cluster terpisah yang tidak menjalankan workload reguler. Menggunakan cluster terpisah akan memberikan isolasi serupa antara workload dan gateway, sekaligus menghindari kebutuhan akan taint dan toleransi. Gateway keluar dapat berbagi cluster terpisah dengan gateway masuk atau layanan pusat lainnya.

Anda dapat menggunakan kebijakan jaringan Kubernetes dalam deployment multi-cluster, tetapi karena beroperasi pada Lapisan 4 (transpor), kebijakan tersebut tidak dapat membatasi koneksi lintas cluster berdasarkan namespace tujuan atau Pod.

Langkah selanjutnya