Ringkasan

Halaman ini memberikan ringkasan kebijakan jaringan project di Google Distributed Cloud (GDC) dengan air gap.

Kebijakan jaringan project menentukan aturan ingress atau egress. Tidak seperti kebijakan jaringan Kubernetes, Anda hanya dapat menentukan satu jenis kebijakan untuk sebuah kebijakan. Setiap aturan dalam kebijakan dapat dikonfigurasi dengan tindakan Izinkan (default) atau Tolak.

Untuk traffic dalam project, GDC menerapkan kebijakan jaringan project yang telah ditetapkan, yaitu kebijakan intra-project default, ke setiap project.

Layanan dan workload dalam sebuah project diisolasi dari layanan dan workload eksternal secara default. Namun, layanan dan workload dari namespace project yang berbeda dan dalam organisasi yang sama dapat berkomunikasi satu sama lain dengan menerapkan kebijakan jaringan traffic lintas project.

Demikian pula, menghubungkan layanan dan workload ke tujuan di luar project Anda di organisasi yang berbeda memerlukan persetujuan eksplisit. Anda harus menonaktifkan perlindungan pemindahan data yang tidak sah untuk mengizinkan traffic eksternal organisasi.

Aturan firewall ingress dan egress adalah komponen utama kebijakan jaringan project dan menentukan jenis traffic yang diizinkan atau ditolak masuk dan keluar dari jaringan Anda. Untuk menetapkan aturan firewall bagi namespace project Anda di GDC, gunakan konsol GDC.

Keamanan dan konektivitas

Secara default, layanan dan workload dalam sebuah project diisolasi dalam project tersebut. Pod tidak dapat berkomunikasi dengan layanan dan workload eksternal tanpa mengonfigurasi kebijakan jaringan.

Untuk menetapkan kebijakan jaringan untuk namespace project Anda di GDC, gunakan resource ProjectNetworkPolicy. Resource ini memungkinkan Anda menentukan kebijakan, yang mengizinkan komunikasi dalam project, antar-project, ke alamat IP eksternal, dan dari alamat IP eksternal. Selain itu, Anda hanya dapat mentransfer workload keluar dari project jika Anda menonaktifkan perlindungan pemindahan data yang tidak sah untuk project tersebut.

Kebijakan jaringan project GDC bersifat kumulatif. Penerapan yang dihasilkan untuk workload adalah kecocokan apa pun untuk aliran traffic terhadap gabungan semua kebijakan yang diterapkan ke workload tersebut. Jika ada beberapa kebijakan, aturan untuk setiap kebijakan akan digabungkan secara aditif, sehingga mengizinkan traffic jika cocok dengan setidaknya salah satu aturan.

Aturan Deny eksplisit lebih diutamakan daripada aturan Allow. Jika aliran traffic cocok dengan aturan Deny, aliran traffic tersebut akan dihapus, meskipun diizinkan oleh aturan lain atau kebijakan platform default.

Selain itu, setelah Anda menerapkan satu kebijakan yang memilih workload, semua traffic yang tidak Anda tentukan akan ditolak (mode tolak default). Oleh karena itu, saat Anda menerapkan satu atau beberapa kebijakan yang memilih workload sebagai subjek, hanya traffic yang diizinkan secara eksplisit (dan tidak ditolak secara eksplisit) yang diizinkan.

Saat Anda menggunakan alamat IP terkenal yang Anda alokasikan untuk project, alamat IP tersebut akan melakukan penafsiran alamat jaringan (NAT) sumber pada traffic keluar dari organisasi.

Kebijakan intra-project default

Saat Anda membuat project, GDC akan otomatis membuat kebijakan jaringan project global bernama base-policy-allow-intra-project-traffic di namespace project. Kebijakan default ini melakukan hal berikut:

• Memilih semua workload pengguna dalam project sebagai subjeknya.
• Mengizinkan traffic masuk ke workload tersebut dari semua workload dalam project yang sama, di semua port.
• Tidak mengizinkan traffic masuk dari project lain atau dari luar organisasi.

GDC membuat kebijakan default hanya sekali, saat membuat project. Jika Anda mengubah atau menghapus kebijakan, GDC tidak akan memulihkannya. GDC menyebarkan kebijakan ke setiap cluster dalam project sebagai kebijakan jaringan bernama g-base-policy-allow-intra-project-traffic. Kolom status.zones[].replicaStatus.propagatedName kebijakan menampilkan nama ini.

Untuk melihat kebijakan default, jalankan perintah berikut:

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

Ganti kode berikut:

• GLOBAL_API_SERVER: jalur kubeconfig server API global. Untuk mengetahui informasi selengkapnya, lihat Server API global dan zona.
• PROJECT: nama project Anda.

Jika perintah menampilkan error NotFound, kebijakan default telah dihapus. Untuk menambahkannya kembali, lihat Membuat kebijakan intra-project ingress.

Kebijakan default digabungkan dengan kebijakan yang Anda buat sebagai berikut:

• Ingress: Workload diisolasi dari project lain dan dari luar organisasi secara default, terlepas dari apakah kebijakan default ada atau tidak. Kebijakan ingress yang Anda buat akan menambahkan sumber yang diizinkan, seperti project lain atau blok CIDR eksternal. Meskipun kebijakan default ada, Anda tidak perlu mengulangi aturan intra-project dalam kebijakan ingress Anda sendiri.
• Ingress intra-project level workload: Meskipun kebijakan default ada, semua workload dalam project dapat saling menjangkau di semua port. Kebijakan ingress intra-project tingkat workload yang menggunakan tindakan Allow tidak membatasi traffic ini hingga Anda menghapus atau mengubah kebijakan default. Untuk menghindari gangguan, terapkan kebijakan tingkat workload dan pastikan kebijakan tersebut sudah siap sebelum Anda menghapus kebijakan default. Untuk memblokir traffic intra-project tertentu sembari mempertahankan kebijakan default, Anda dapat menggunakan aturan penolakan eksplisit, yang merupakan fitur Pratinjau. Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan intra-project tingkat workload ingress.
• Egress: Project tidak memiliki kebijakan egress secara default. Traffic keluar tidak dibatasi dalam organisasi, tetapi perlindungan pemindahan data yang tidak sah (diaktifkan secara default) memblokir traffic yang keluar dari organisasi. Kebijakan egress hanya berlaku setelah Anda menonaktifkan perlindungan pemindahan data yang tidak sah untuk project. Saat perlindungan pemindahan data yang tidak sah diaktifkan, server API zona akan menolak kebijakan egress, dan kebijakan egress global tidak akan siap.

Perhatian: Jika kebijakan egress diterapkan, workload yang dipilih dapat mengirim traffic hanya ke tujuan yang secara eksplisit diizinkan oleh kebijakan egress Anda (DNS dikecualikan). Tindakan ini akan memblokir traffic keluar ke workload lain dan Layanan ClusterIP dalam project yang sama. Untuk menghindari pemadaman layanan yang tidak terduga, selalu terapkan kebijakan egress intra-project sebelum Anda menonaktifkan perlindungan pemindahan data yang tidak sah atau menerapkan kebijakan egress yang ketat.

Kebijakan jaringan project global

Anda dapat membuat kebijakan jaringan project global. Cakupan kebijakan jaringan project global mencakup seluruh universe GDC. Setiap universe GDC dapat terdiri dari beberapa zona GDC yang diatur ke dalam region yang saling terhubung dan berbagi bidang kontrol. Misalnya, universe yang terdiri dari dua region dengan masing-masing tiga zona mungkin terlihat seperti: us-virginia1-a, us-virginia1-b, us-virginia1-c dan eu-ams1-a, eu-ams1-b, eu-ams1-c.

Cakupan kebijakan jaringan project zona terbatas pada zona yang ditentukan pada saat pembuatan. Setiap zona adalah domain bencana yang independen. Zona mengelola infrastruktur, layanan, API, dan alat yang menggunakan bidang kontrol lokal.

Untuk mengetahui informasi selengkapnya tentang resource global di universe GDC, lihat Ringkasan multi-zona.

Anda dapat membuat kebijakan jaringan project global menggunakan Networking Kubernetes Resource Model (KRM) API. Gunakan API versi networking.global.gdc.goog untuk membuat resource global.

Anda dapat membuat kebijakan jaringan project zona menggunakan KRM API atau konsol GDC. Gunakan API versi networking.gdc.goog untuk membuat resource zona.

Kebijakan jaringan izinkan semua

Anda dapat membuat kebijakan jaringan izinkan semua untuk menetapkan aturan akses default yang luas untuk sebuah project.

Anda dapat mengonfigurasi jenis kebijakan jaringan izinkan semua berikut:

• Kebijakan Jaringan Izinkan Semua: Mengizinkan traffic ke dan dari sumber mana pun, yang mencakup project lain dan IP eksternal.
• Kebijakan Jaringan Allow-all-external: Mengizinkan traffic ke dan dari alamat IP di luar organisasi.
• Kebijakan Jaringan Izinkan-semua-project: Mengizinkan traffic ke dan dari semua project dalam organisasi.

Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan jaringan traffic izinkan semua.

Kebijakan jaringan penolakan eksplisit

Pratinjau: Mengonfigurasi kebijakan jaringan project penolakan eksplisit adalah fitur Pratinjau yang tersedia apa adanya dan tidak direkomendasikan untuk lingkungan produksi. Google tidak memberikan Perjanjian Tingkat Layanan (SLA) atau komitmen dukungan teknis untuk fitur Pratinjau. Untuk mengetahui informasi selengkapnya, lihat tahapan fitur.

Anda dapat mengonfigurasi aturan penolakan eksplisit dalam kebijakan jaringan project untuk membatasi konektivitas antara project atau blok CIDR yang ditentukan.

Fitur dan batasan utama aturan penolakan:

• Prioritas: Aturan penolakan lebih diutamakan daripada aturan izin (termasuk kebijakan platform dasar).
• Aturan keamanan egress: Untuk mencegah pemblokiran traffic infrastruktur penting secara tidak sengaja, aturan penolakan egress secara otomatis mengecualikan namespace sistem dan non-project.
• Batasan peer: Untuk memastikan konfigurasi yang aman, aturan penolakan ingress harus secara eksplisit menentukan peer sumber di kolom from, dan aturan penolakan egress harus secara eksplisit menentukan peer tujuan di kolom to. Anda tidak dapat memilih semua sumber atau tujuan dengan mengosongkan kolom peer. Membiarkan kolom peer kosong tidak diizinkan, dan kebijakan akan ditolak.
• Tidak ada penolakan egress dengan DEP: Anda tidak dapat mengonfigurasi aturan penolakan egress jika perlindungan pemindahan data yang tidak sah (DEP) diaktifkan untuk project.

Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan jaringan penolakan eksplisit.

Kebijakan jaringan tingkat workload

Anda dapat membuat kebijakan jaringan tingkat workload untuk menentukan kontrol akses terperinci bagi setiap VM dan pod dalam sebuah project. Kebijakan ini berfungsi seperti firewall untuk workload Anda, yang mengontrol aliran traffic berdasarkan label untuk meningkatkan keamanan dan mengisolasi aplikasi. Perincian ini memungkinkan kontrol yang lebih ketat atas workload mana yang dapat berkomunikasi satu sama lain di dalam dan di seluruh project.

Kebijakan jaringan tingkat workload juga memberikan kemampuan untuk menerapkan PNP di satu zona.

Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan intra-project tingkat workload dan Membuat kebijakan lintas project tingkat workload.

Struktur dan validasi kebijakan

Dalam resource ProjectNetworkPolicy, pemilih label workload disusun bertingkat beberapa level. Kebijakan ingress berikut menunjukkan lokasi yang benar untuk setiap pemilih:

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

Ganti kode berikut:

• PROJECT: nama project Anda.
• PEER_PROJECT: nama project yang berisi workload klien.

Kebijakan ini memungkinkan workload berlabel app: frontend di PEER_PROJECT terhubung ke workload berlabel app: backend di project Anda pada port TCP 8080.

Saat Anda menulis kebijakan, ikuti aturan berikut:

• Selalu tetapkan spec.policyType secara eksplisit ke Ingress atau Egress. Kebijakan Ingress hanya dapat berisi aturan ingress dengan peer from, dan kebijakan Egress hanya dapat berisi aturan egress dengan peer to. Jika Anda menghapus policyType, kebijakan akan ditetapkan secara default ke Ingress, dan server API akan menolak kebijakan yang hanya berisi aturan egress.
• Untuk memilih workload subjek berdasarkan label, gunakan spec.subject.userWorkloadSelector.labelSelector.workloads. Jika Anda menghapus userWorkloadSelector, kebijakan akan berlaku untuk semua workload pengguna dalam project.
• Jangan menempatkan pemilih label langsung di bawah spec.subject. Secara default, kubectl menolak kolom seperti spec.subject.matchLabels dengan pesan strict decoding error: unknown field.
• Untuk memilih workload peer berdasarkan label, gunakan projectSelector.workloadSelector.labelSelector.workloads dalam entri from atau to.
• Jika workload subjek atau peer adalah VM, awali kunci labelnya dengan user-label.gpc.gke.io/. Misalnya, gunakan user-label.gpc.gke.io/app: backend.
• Kebijakan intra-project default yang dibuat secara otomatis dan beberapa kebijakan yang ada menggunakan kolom spec.subject.workloadSelector yang tidak digunakan lagi, yang mengambil pemilih label secara langsung. Gunakan userWorkloadSelector dalam kebijakan baru.

Peringatan: Jangan terapkan kebijakan dengan --validate=false, --validate=ignore, atau --validate=warn. Dengan setelan ini, server API akan menghapus kolom yang tidak diketahui, bukan menolaknya. Setelan warn hanya mencetak peringatan. Pemilih subjek yang salah tempat kemudian membuat kebijakan berlaku untuk semua workload pengguna dalam project, yang dapat mengizinkan lebih banyak traffic daripada yang Anda inginkan.

Untuk memvalidasi kebijakan terhadap server API global tanpa menerapkannya, jalankan uji coba sisi server:

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

Uji coba melaporkan skema dan error validasi yang sama dengan perintah kubectl apply yang sebenarnya, seperti kolom yang tidak diketahui atau aturan egress dalam kebijakan Ingress, tetapi tidak membuat atau mengubah kebijakan. Uji coba memerlukan izin yang sama seperti penerapan kebijakan. Uji coba yang berhasil tidak mengonfirmasi bahwa kebijakan diterapkan. Setelah Anda menerapkan kebijakan, pastikan kebijakan tersebut sudah siap.

Untuk menampilkan daftar kolom yang diterima server API global, jalankan perintah berikut:

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

Ganti kode berikut:

• GLOBAL_API_SERVER: jalur kubeconfig server API global.
• POLICY_FILE: jalur ke manifes ProjectNetworkPolicy Anda.

Menyiapkan peran dan akses yang telah ditetapkan

Untuk mengonfigurasi kebijakan jaringan project, Anda harus memiliki peran identitas dan akses yang diperlukan:

• Project Network Policy Admin: memiliki izin tulis pada semua resource PNP multi-zona di namespace project global. Minta Admin Organisasi IAM Anda untuk memberi Anda peran global-project-networkpolicy-admin. Untuk mengetahui informasi selengkapnya, lihat Deskripsi peran yang telah ditetapkan.

Menargetkan node cluster menggunakan blok IP

Pratinjau: Menargetkan node cluster tertentu menggunakan kolom ipBlocks adalah fitur Pratinjau yang tersedia apa adanya dan tidak direkomendasikan untuk lingkungan produksi. Google tidak memberikan Perjanjian Tingkat Layanan (SLA) atau komitmen dukungan teknis untuk fitur Pratinjau. Untuk mengetahui informasi selengkapnya, lihat tahapan fitur.

Anda dapat menggunakan kolom ipBlocks dalam resource ProjectNetworkPolicy untuk menentukan alamat IP node individual atau rentang CIDR node dan mengontrol traffic antara pod dan node cluster tertentu (misalnya, mengizinkan traffic masuk dari node bidang kontrol ke pod webhook kustom, atau membatasi traffic keluar pod ke node bidang kontrol). Untuk mengetahui petunjuknya, lihat Membuat kebijakan intra-project untuk cluster standar.

Pertimbangan skala

Saat mengonfigurasi kebijakan jaringan project untuk menargetkan node tertentu atau menggunakan rentang CIDR yang luas, pilihan konfigurasi kebijakan Anda dapat memengaruhi skalabilitas dan performa:

• Perilaku 0.0.0.0/0: Menggunakan rentang CIDR yang luas seperti 0.0.0.0/0 dalam aturan ipBlocks akan mencocokkan semua node dalam cluster, selain alamat IP eksternal.
• Skala: Setiap node dalam cluster diberi identitas CIDR yang unik. Setiap endpoint workload (VM atau pod) memiliki tabel kebijakan internal yang menyimpan aturan jaringannya. Dalam cluster besar, aturan ipBlocks yang luas seperti 0.0.0.0/0 meningkatkan penggunaan tabel kebijakan sebanding dengan jumlah node karena sistem harus membuat entri untuk setiap identitas CIDR node yang unik.
• Peringatan: Hindari penggunaan rentang CIDR yang terlalu luas dalam aturan ipBlocks jika Anda memiliki jumlah node yang tinggi atau banyak kebijakan yang kompleks, karena Anda berisiko mencapai batas tabel kebijakan untuk endpoint. Jika endpoint mencapai batas ini, kebijakan jaringan baru akan gagal diterapkan, yang dapat mengganggu konektivitas jaringan atau mencegah penerapan kebijakan untuk workload tersebut.

Langkah berikutnya

• Membuat kebijakan jaringan intra-project
• Membuat kebijakan jaringan lintas project
• Membuat kebijakan jaringan eksternal organisasi
• Membuat kebijakan jaringan izinkan semua
• Membuat kebijakan jaringan penolakan eksplisit
• Membuat kebijakan jaringan untuk layanan terkelola