Tentang isolasi jaringan di GKE

Anda dapat menyesuaikan akses jaringan untuk bidang kontrol dan node cluster Google Kubernetes Engine (GKE) guna meningkatkan keamanan jaringan untuk cluster dan workload-nya. Dokumen ini menjelaskan berbagai jenis isolasi yang dapat Anda konfigurasi untuk cluster, manfaat mengisolasi jaringan, dan batasan yang harus Anda pertimbangkan sebelum mengisolasi cluster.

Untuk mengonfigurasi tingkat isolasi tertentu untuk cluster Anda, lihat dokumen berikut:

Praktik terbaik:

Rencanakan dan desain konfigurasi isolasi jaringan Anda dengan Arsitek jaringan, Engineer jaringan, atau Administrator jaringan organisasi Anda, atau tim lain yang bertanggung jawab atas definisi, penerapan, dan pemeliharaan arsitektur jaringan.

Jenis akses jaringan

Komponen di cluster Anda—seperti bidang kontrol, server API, dan node—mengirim dan menerima traffic jaringan untuk berbagai tujuan. Anda dapat menyesuaikan isolasi cluster dengan mengontrol satu atau beberapa jenis akses jaringan berikut:

  • Akses ke bidang kontrol dari sumber eksternal: sesuaikan siapa yang dapat mengakses bidang kontrol Anda untuk melakukan tugas seperti menjalankan perintah kubectl di cluster.
  • Akses ke webhook eksternal dari server API: sesuaikan apakah server API Kubernetes dapat mengirim traffic secara langsung ke server webhook eksternal melalui bidang kontrol.
  • Akses ke node dari sumber eksternal: sesuaikan apakah klien eksternal di internet publik dapat mengakses node Anda.

Akses ke bidang kontrol dari sumber eksternal

Di bagian ini, Anda akan mempertimbangkan siapa yang dapat mengakses bidang kontrol Anda.

Setiap cluster GKE memiliki bidang kontrol yang menangani permintaan Kubernetes API. Bidang kontrol berjalan di virtual machine (VM) yang berada di jaringan VPC dalam project yang dikelola Google. Cluster regional memiliki beberapa replika bidang kontrol, yang masing-masing berjalan di VM-nya sendiri. Principal seperti administrator cluster menggunakan endpoint bidang kontrol untuk mengakses cluster untuk tugas seperti menjalankan perintah kubectl atau men-deploy workload. Endpoint bidang kontrol digunakan oleh klien eksternal untuk mengakses cluster, dan tidak digunakan untuk komunikasi langsung dengan instance VM Compute Engine yang menghosting replika bidang kontrol. Bidang kontrol memiliki jenis endpoint berikut untuk akses ke cluster:

Bidang kontrol memiliki dua jenis endpoint untuk akses cluster:

  • Endpoint berbasis DNS
  • Endpoint berbasis IP
Praktik terbaik:

Gunakan hanya endpoint berbasis DNS untuk mengakses bidang kontrol Anda guna menyederhanakan konfigurasi dan lapisan keamanan berbasis kebijakan yang fleksibel.

Endpoint berbasis DNS

Endpoint berbasis DNS memberikan DNS atau nama domain yang sepenuhnya memenuhi syarat (FQDN) yang unik dan tidak dapat diubah untuk setiap bidang kontrol cluster. Nama DNS ini dapat digunakan untuk mengakses bidang kontrol selama seluruh siklus prosesnya. Nama DNS di-resolve ke endpoint yang dapat diakses dari jaringan mana pun yang dapat dijangkau oleh API, termasuk jaringan lokal atau jaringan cloud lainnya. Google Cloud Dengan mengaktifkan endpoint berbasis DNS, Anda tidak memerlukan bastion host atau node proxy untuk mengakses bidang kontrol dari jaringan VPC lain atau lokasi eksternal.

Untuk mengakses endpoint bidang kontrol, Anda perlu mengonfigurasi peran dan kebijakan IAM, serta token autentikasi. Untuk mengetahui detail selengkapnya tentang izin yang diperlukan, lihat Menyesuaikan isolasi jaringan.

Selain kebijakan dan token IAM, Anda juga dapat mengonfigurasi atribut akses berikut:

  • Kontrol berbasis jaringan atau alamat IP dengan Kontrol Layanan VPC: untuk meningkatkan keamanan untuk control plane cluster GKE Anda, Kontrol Layanan VPC menambahkan lapisan keamanan akses lainnya. Aplikasi ini menggunakan akses kontekstual berdasarkan atribut seperti asal jaringan.

    Kontrol Layanan VPC tidak secara langsung mendukung cluster dengan alamat IP publik untuk bidang kontrolnya. Namun, cluster GKE, termasuk cluster pribadi dan publik, mendapatkan perlindungan dari Kontrol Layanan VPC saat Anda mengaksesnya menggunakan endpoint berbasis DNS.

    Anda mengonfigurasi Kontrol Layanan VPC untuk melindungi endpoint berbasis DNS cluster GKE dengan menyertakan container.googleapis.com dan kubernetesmetadata.googleapis.com dalam daftar layanan yang dibatasi di perimeter layanan Anda. Menambahkan API ini ke perimeter layanan akan mengaktifkan VPC-SC untuk semua operasi GKE API. Konfigurasi ini membantu memastikan bahwa perimeter keamanan yang Anda tentukan mengatur akses ke panel kontrol.

    Dengan menggunakan kebijakan IAM dan Kontrol Layanan VPC untuk mengamankan akses ke endpoint berbasis DNS, Anda membuat model keamanan multi-layer untuk bidang kontrol cluster Anda. Kontrol Layanan VPC terintegrasi dengan layanan Google Cloud yang didukung. Hal ini menyelaraskan konfigurasi keamanan cluster Anda dengan data yang Anda hosting di layanan Google Cloud lainnya.

  • Private Service Connect atau Cloud NAT: untuk mengakses endpoint berbasis DNS dari klien yang tidak memiliki akses internet publik. Secara default, endpoint berbasis DNS dapat diakses melalui Google Cloud API yang tersedia di internet publik. Untuk mempelajari lebih lanjut, lihat Endpoint berbasis DNS di halaman Menyesuaikan isolasi jaringan.

  • Kredensial autentikasi Kubernetes: untuk mengautentikasi ke endpoint berbasis DNS menggunakan token pembawa ServiceAccount Kubernetes atau sertifikat klien X.509. Metode autentikasi ini dinonaktifkan secara default di cluster GKE. Anda dapat mengaktifkan metode ini saat mengonfigurasi endpoint berbasis DNS untuk cluster.

Endpoint berbasis IP

Secara opsional, Anda juga dapat mengonfigurasi akses ke bidang kontrol menggunakan endpoint berbasis IP.

Terminologi yang terkait dengan cluster dan alamat IP

  • Google Cloud Alamat IP eksternal:

    • Alamat IP eksternal yang ditetapkan ke VM mana pun yang digunakan oleh pelanggan mana pun yang dihosting diGoogle Cloud. Google Cloud memiliki alamat IP ini. Untuk mempelajari lebih lanjut, lihat Di mana saya dapat menemukan rentang IP Compute Engine?

    • Alamat IP eksternal yang digunakan oleh produk seperti Cloud Run atau Cloud Run Functions. Google Cloud Klien apa pun yang dihosting di Google Cloud dapat membuat instance alamat IP ini. Google Cloud adalah pemilik alamat IP ini.

  • Alamat IP yang dicadangkan Google: Alamat IP eksternal untuk tujuan pengelolaan cluster GKE. Alamat IP ini mencakup proses yang dikelola GKE dan layanan produksi Google lainnya. Google adalah pemilik alamat IP ini.

  • Rentang alamat IP cluster GKE: Alamat IP internal yang ditetapkan ke cluster yang digunakan GKE untuk node, Pod, dan Layanan cluster.

  • Alamat IP internal: Alamat IP dari jaringan VPC cluster Anda. Alamat IP ini dapat mencakup alamat IP cluster Anda, jaringan lokal, rentang RFC 1918, atau alamat IP publik (PUPI) yang digunakan secara pribadi, yang mencakup rentang non-RFC 1918.

  • Endpoint cluster berbasis IP eksternal: Alamat IP endpoint eksternal, yang ditetapkan GKE ke bidang kontrol.

  • Alamat IP VM bidang kontrol eksternal: Alamat IP eksternal yang ditetapkan ke setiap instance VM yang menjalankan bidang kontrol dan hanya digunakan untuk traffic keluar dari server API.

  • Endpoint internal: Alamat IP internal yang ditetapkan GKE ke bidang kontrol.

  • Jaringan VPC: Jaringan virtual tempat Anda membuat subnet dengan rentang alamat IP khusus untuk node dan Pod cluster.

Saat menggunakan endpoint berbasis IP, Anda memiliki dua opsi:

  • Mengekspos bidang kontrol di endpoint eksternal dan internal. Artinya, endpoint eksternal bidang kontrol dapat diakses dari alamat IP eksternal, dan endpoint internal dapat diakses dari jaringan VPC cluster Anda. Node hanya akan berkomunikasi dengan bidang kontrol di endpoint internal.

  • Ekspos bidang kontrol hanya di endpoint internal. Artinya, klien di internet tidak dapat terhubung ke cluster dan bidang kontrol dapat diakses dari alamat IP mana pun dari jaringan VPC cluster Anda. Node hanya akan berkomunikasi dengan bidang kontrol di endpoint internal.

    Ini adalah opsi yang paling aman saat menggunakan endpoint berbasis IP karena mencegah semua akses internet ke bidang kontrol. Opsi ini tepat jika Anda memiliki workload yang—misalnya—memerlukan kontrol akses karena peraturan privasi dan keamanan data.

Pada kedua opsi sebelumnya, Anda dapat membatasi alamat IP yang mencapai endpoint dengan mengonfigurasi jaringan yang diizinkan. Jika Anda menggunakan endpoint berbasis IP, sebaiknya tambahkan setidaknya satu jaringan yang diizinkan. Jaringan yang diizinkan memberikan akses bidang kontrol ke sekumpulan alamat IPv4 tepercaya tertentu, serta memberikan perlindungan dan manfaat keamanan tambahan untuk cluster GKE Anda.

Praktik terbaik:

Aktifkan jaringan yang diizinkan saat menggunakan endpoint berbasis IP untuk mengamankan cluster GKE Anda.

Cara kerja jaringan yang diizinkan

Jaringan yang diizinkan menyediakan firewall berbasis IP yang mengontrol akses ke bidang kontrol GKE. Akses ke bidang kontrol bergantung pada alamat IP sumber. Saat mengaktifkan jaringan yang diizinkan, Anda mengonfigurasi alamat IP yang ingin Anda izinkan untuk mengakses endpoint bidang kontrol cluster GKE sebagai daftar blok CIDR.

Tabel berikut menunjukkan:

  • Alamat IP preset yang selalu dapat mengakses bidang kontrol GKE, terlepas dari apakah Anda mengaktifkan jaringan yang diizinkan atau tidak.
  • Alamat IP yang dapat dikonfigurasi yang dapat mengakses bidang kontrol jika Anda mengizinkannya dengan mengaktifkan jaringan yang diizinkan.
Endpoint bidang kontrol Alamat IP preset yang dapat selalu mengakses endpoint Alamat IP yang dapat dikonfigurasi yang dapat mengakses endpoint setelah mengaktifkan jaringan yang diizinkan
Endpoint eksternal dan internal diaktifkan
  • Alamat IP yang dicadangkan Google
  • Rentang alamat IP cluster GKE
  • Alamat IP eksternal yang diizinkan
  • Alamat IP internal yang diizinkan
  • Google Cloud alamat IP eksternal
Hanya endpoint internal yang diaktifkan
  • Alamat IP yang dicadangkan Google
  • Rentang alamat IP cluster GKE
  • Alamat IP internal yang diizinkan.

Dengan jaringan yang diizinkan, Anda juga dapat mengonfigurasi region tempat alamat IP internal dapat menjangkau endpoint internal bidang kontrol Anda. Anda dapat memilih untuk mengizinkan akses hanya dari jaringan VPC cluster, atau dari region mana pun di VPC atau lingkungan lokal. Google Cloud

Batasan penggunaan endpoint berbasis IP

  • Jika memperluas subnet yang digunakan oleh cluster dengan jaringan yang diizinkan, Anda harus memperbarui konfigurasi jaringan yang diizinkan untuk menyertakan rentang alamat IP yang diperluas.
  • Jika Anda memiliki klien yang terhubung dari jaringan dengan alamat IP dinamis, seperti karyawan di jaringan rumah, Anda harus sering memperbarui daftar jaringan yang diizinkan untuk mempertahankan akses ke cluster.
  • Menonaktifkan akses ke endpoint eksternal bidang kontrol akan mencegah Anda berinteraksi dengan cluster dari jarak jauh. Jika Anda perlu mengakses cluster dari jarak jauh, Anda harus menggunakan bastion host yang meneruskan traffic klien ke cluster. Sebaliknya, penggunaan endpoint berbasis DNS hanya memerlukan penyiapan izin IAM.
  • Endpoint berbasis IP tidak terintegrasi langsung dengan Kontrol Layanan VPC. Kontrol Layanan VPC beroperasi di tingkat perimeter layanan untuk mengontrol akses dan pergerakan data dalam Google Cloud. Sebaiknya gunakan endpoint berbasis DNS dengan Kontrol Layanan VPC untuk pertahanan keamanan yang kuat.
  • Anda dapat menentukan hingga 100 rentang alamat IP yang diizinkan (termasuk alamat IP eksternal dan internal).

Akses ke sumber eksternal dari server API

Bidang kontrol cluster GKE menjalankan komponen bidang kontrol Kubernetes seperti server API, penjadwal, dan pengontrol. Bidang kontrol berjalan di instance VM Compute Engine yang dimiliki oleh GKE dalam project terkelola. Cluster regional dan cluster Autopilot memiliki beberapa replika bidang kontrol, yang masing-masing berjalan di instance VM-nya sendiri.

Secara default, setiap instance VM Compute Engine ini memiliki alamat IP eksternal yang ditetapkan langsung ke VM. Alamat IP ini hanya digunakan untuk mengirim permintaan penerimaan dari server Kubernetes API pada instance ke server webhook penerimaan yang berjalan di luar cluster, misalnya di layanan cloud yang berbeda atau di lokal. Alamat IP ini hanya digunakan jika webhook penerimaan langsung menghubungi server webhook menggunakan URL server atau alamat IP server.

Untuk meningkatkan postur keamanan bidang kontrol, Anda dapat menonaktifkan alamat IP eksternal pada instance VM bidang kontrol. Jika terjadi peretasan, calon penyerang tidak dapat menggunakan alamat IP eksternal ini untuk berkomunikasi. Anda dapat menyesuaikan traffic keluar dari server API dengan cara berikut:

  • Tidak ada traffic keluar (NONE): nonaktifkan alamat IP eksternal setiap instance control plane dan arahkan traffic keluar server API ke black hole. Semua traffic keluar non-kritis dari server API ke tujuan eksternal diblokir, termasuk traffic ke Google Cloud layanan di luar cluster. Opsi ini tidak memengaruhi traffic sistem penting atau traffic dari node Anda.
  • Semua traffic keluar (VIA_CONTROL_PLANE): mempertahankan alamat IP eksternal setiap instance bidang kontrol dan memungkinkan server API menggunakan alamat IP untuk traffic keluar. Opsi ini adalah opsi default di GKE.

Untuk mempelajari cara menyesuaikan cluster Anda untuk salah satu opsi ini, lihat Membatasi traffic keluar dari server API.

Konfigurasi webhook eksternal

Jika Anda menyetel batasan keluar bidang kontrol ke NONE, server API tidak dapat melakukan panggilan langsung ke alamat IP eksternal atau nama domain yang sepenuhnya memenuhi syarat (FQDN). Setelan NONE memiliki efek berikut pada webhook eksternal:

  • Di versi 1.35.1-gke.1396000 dan yang lebih baru, GKE mencegah pembuatan atau update pada ValidatingWebhookConfigurations atau MutatingWebhookConfigurations yang menggunakan kolom clientConfig.url.
  • Konfigurasi webhook yang ada yang menggunakan kolom clientConfig.url untuk menghubungi server eksternal akan berhenti berfungsi.

Untuk membuat dan menggunakan server webhook eksternal, Anda harus melakukan hal berikut:

  1. Perbarui ValidatingWebhookConfigurations atau MutatingWebhookConfigurations Anda untuk menggunakan kolom clientConfig.service. Kolom ini memungkinkan server API mengirim permintaan ke endpoint Layanan, seperti my-webhook.default.svc, di cluster Anda. Permintaan ini tidak diblokir karena traffic berada di dalam cluster. Untuk mengetahui informasi selengkapnya, lihat Referensi layanan.

  2. Konfigurasi Layanan untuk merutekan traffic ke server webhook eksternal Anda. Anda dapat menggunakan salah satu desain pemilihan rute traffic berikut, bergantung pada persyaratan keamanan dan operasional Anda:

    • Proxy Pod: gunakan Deployment atau StatefulSet sebagai backend untuk Layanan Anda. Konfigurasi Pod agar berfungsi sebagai proxy yang mengalihkan permintaan penerimaan yang masuk ke server webhook eksternal Anda. Desain ini memungkinkan Anda melakukan tugas tambahan, seperti memeriksa dan mengubah permintaan penerimaan.
    • EndpointSlices: buat Layanan tanpa pemilih, lalu tambahkan EndpointSlice secara manual yang memetakan Layanan ke alamat IP server webhook eksternal. Desain ini merutekan traffic tanpa mengubah permintaan.

Saat mendesain konfigurasi webhook, pertimbangkan faktor-faktor berikut:

  • Autentikasi dan kredensial: pertimbangkan cara mengautentikasi dengan server webhook eksternal. Alur kerja perutean traffic Anda juga harus mengelola cara kredensial (seperti kunci API, sertifikat mTLS, dan token OAuth) diterapkan ke koneksi.
  • Kontrol keamanan dan jaringan: pertimbangkan area serangan desain perutean Anda dan opsi Anda untuk keamanan dan audit. Desain yang Anda terapkan memengaruhi batasan yang dapat Anda terapkan pada traffic. Misalnya, Anda dapat menggunakan NetworkPolicies dengan Pod proxy.
  • Kemampuan observasi dan keandalan: pertimbangkan cara memantau koneksi. Misalnya, Anda dapat mengonfigurasi Pod proxy untuk memancarkan metrik, atau Anda dapat menerapkan kemampuan pengamatan jaringan untuk EndpointSlice.

Akses ke node dari sumber eksternal

Bagian ini membahas cara mengisolasi node dalam cluster Kubernetes.

Mengaktifkan node pribadi

Mencegah klien eksternal mengakses node dengan menyediakan node tersebut hanya dengan alamat IP internal, sehingga membuat node menjadi pribadi. Workload yang berjalan di node tanpa alamat IP eksternal tidak dapat terhubung ke internet kecuali jika NAT diaktifkan di jaringan cluster. Anda dapat mengubah setelan ini kapan saja.

Anda dapat mengaktifkan node pribadi di tingkat cluster individual atau di tingkat node pool (untuk Standard) atau tingkat workload (untuk Autopilot). Mengaktifkan node pribadi di tingkat node pool atau workload akan menggantikan konfigurasi node di tingkat cluster.

Jika Anda mengupdate node pool publik ke mode pribadi, workload yang memerlukan akses di luar jaringan cluster mungkin akan gagal dalam skenario berikut:

  • Cluster di jaringan VPC Bersama yang tidak mengaktifkan Akses Google Pribadi. Aktifkan Akses Google Pribadi secara manual untuk memastikan GKE mendownload image node yang ditetapkan. Untuk cluster yang tidak berada dalam jaringan VPC Bersama, GKE secara otomatis mengaktifkan Akses Google Pribadi.

  • Workload yang memerlukan akses ke internet tempat Cloud NAT tidak diaktifkan atau solusi NAT kustom tidak ditentukan. Untuk mengizinkan traffic keluar ke internet, aktifkan Cloud NAT atau solusi NAT kustom.

Baik Anda mengaktifkan node pribadi atau tidak, bidang kontrol tetap berkomunikasi dengan semua node hanya melalui alamat IP internal.

Manfaat isolasi jaringan

Berikut adalah manfaat isolasi jaringan:

  • Fleksibilitas:

    • Cluster memiliki konfigurasi yang terpadu dan fleksibel. Cluster dengan atau tanpa endpoint eksternal memiliki arsitektur yang sama dan mendukung fungsi yang sama. Anda dapat mengamankan akses berdasarkan kontrol dan praktik terbaik yang memenuhi kebutuhan Anda. Semua komunikasi antara node di cluster Anda dan bidang kontrol menggunakan alamat IP internal.
    • Anda dapat mengubah setelan akses bidang kontrol dan konfigurasi node cluster kapan saja tanpa harus membuat ulang cluster.
    • Anda dapat memilih untuk mengaktifkan endpoint eksternal bidang kontrol jika Anda perlu mengelola cluster dari lokasi mana pun dengan akses internet, atau dari jaringan atau perangkat yang tidak terhubung langsung dengan VPC Anda. Atau, Anda dapat menonaktifkan endpoint eksternal untuk meningkatkan keamanan jika Anda perlu mempertahankan isolasi jaringan untuk workload sensitif. Dalam kedua kasus tersebut, Anda dapat menggunakan jaringan yang diizinkan untuk membatasi akses ke rentang IP tepercaya.

  • Keamanan:

    • Endpoint berbasis DNS dengan Kontrol Layanan VPC menyediakan model keamanan multi-lapisan yang melindungi cluster Anda dari jaringan yang tidak sah serta identitas yang tidak sah yang mengakses bidang kontrol. Kontrol Layanan VPC terintegrasi dengan Cloud Audit Logs untuk memantau akses ke bidang kontrol.
    • Node pribadi, dan beban kerja yang berjalan di node ini, tidak dapat diakses secara langsung dari internet publik, sehingga secara signifikan mengurangi potensi serangan eksternal pada cluster Anda.
    • Anda dapat memblokir akses bidang kontrol dari Google Cloud alamat IP eksternal atau dari alamat IP eksternal untuk sepenuhnya mengisolasi bidang kontrol cluster dan mengurangi eksposur terhadap potensi ancaman keamanan.
    • Anda dapat menonaktifkan alamat IP eksternal instance VM bidang kontrol untuk mencegah penyerang menggunakan alamat IP tersebut.

  • Kepatuhan: Jika Anda bekerja di industri dengan peraturan ketat untuk akses dan penyimpanan data, node pribadi membantu kepatuhan dengan memastikan bahwa data sensitif tetap berada dalam jaringan pribadi Anda.

  • Kontrol: Node pribadi memberi Anda kontrol terperinci atas cara traffic masuk dan keluar dari cluster Anda. Anda dapat mengonfigurasi aturan firewall dan kebijakan jaringan untuk mengizinkan hanya komunikasi yang sah. Jika Anda beroperasi di lingkungan multi-cloud, node pribadi dapat membantu Anda membangun komunikasi yang aman dan terkontrol antara lingkungan yang berbeda.

  • Biaya: Dengan mengaktifkan node pribadi, Anda dapat mengurangi biaya untuk node yang tidak memerlukan alamat IP eksternal untuk mengakses layanan publik di internet.

Langkah berikutnya