**Bantu meningkatkan halaman ini ** Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. Untuk berkontribusi pada panduan pengguna ini, pilih GitHub ** tautan ** Edit halaman ini di yang terletak di panel kanan setiap halaman. Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes ## Gambaran umum Secara default, tidak ada batasan di Kubernetes untuk alamat IP, port, atau koneksi antara Pod apa pun di cluster Anda atau antara Pod Anda dan sumber daya di jaringan lain mana pun. Anda dapat menggunakan kebijakan * jaringan Kubernetes * untuk membatasi lalu lintas jaringan ke dan dari Pod Anda. Untuk informasi selengkapnya, lihat [ Kebijakan Jaringan ](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dalam dokumentasi Kubernetes. ## Kebijakan jaringan standar Anda dapat menggunakan standar `NetworkPolicy` untuk mengelompokkan lalu lintas pod-to-pod di cluster. Kebijakan jaringan ini beroperasi pada lapisan 3 dan 4 model jaringan OSI, memungkinkan Anda untuk mengontrol aliran lalu lintas pada alamat IP atau tingkat port dalam cluster Amazon EKS Anda. Kebijakan jaringan standar dicakup ke tingkat namespace. ### Kasus penggunaan + Segmentasikan lalu lintas jaringan di antara beban kerja untuk memastikan bahwa hanya aplikasi terkait yang dapat berbicara satu sama lain. + Isolasi penyewa di tingkat namespace menggunakan kebijakan untuk menerapkan pemisahan jaringan. ### Contoh Dalam kebijakan di bawah ini, lalu lintas keluar dari pod * webapp * di * namespace * sun dibatasi. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: webapp-egress-policy namespace: sun spec: podSelector: matchLabels: role: webapp policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: moon podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: name: stars podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 ``` Kebijakan ini berlaku untuk pod dengan label `role: webapp` di `sun` namespace. + Lalu lintas yang diizinkan: Pod dengan label `role: frontend` di `moon` namespace pada port TCP `8080` + Lalu lintas yang diizinkan: Pod dengan label `role: frontend` di `stars` namespace pada port TCP `8080` + Lalu lintas yang diblokir: Semua lalu lintas keluar lainnya dari pod secara `webapp` implisit ditolak ## Kebijakan jaringan admin (atau cluster) ![Ilustrasi urutan evaluasi untuk kebijakan jaringan di EKS](https://docs.aws.amazon.com/id_id/eks/latest/userguide/images/evaluation-order.png) Anda dapat menggunakan `ClusterNetworkPolicy` untuk menerapkan standar keamanan jaringan yang berlaku untuk seluruh cluster. Alih-alih secara berulang-ulang mendefinisikan dan mempertahankan kebijakan yang berbeda untuk setiap namespace, Anda dapat menggunakan kebijakan tunggal untuk mengelola kontrol akses jaringan secara terpusat untuk beban kerja yang berbeda di cluster, terlepas dari namespace mereka. ### Kasus penggunaan + Kelola kontrol akses jaringan secara terpusat untuk semua (atau sebagian dari) beban kerja di cluster EKS Anda. + Tentukan postur keamanan jaringan default di seluruh cluster. + Memperluas standar keamanan organisasi ke ruang lingkup cluster dengan cara yang lebih efisien secara operasional. ### Contoh Dalam kebijakan di bawah ini, Anda dapat secara eksplisit memblokir lalu lintas cluster dari ruang nama lain untuk mencegah akses jaringan ke namespace beban kerja yang sensitif. ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: protect-sensitive-workload spec: tier: Admin priority: 10 subject: namespaces: matchLabels: kubernetes.io/metadata.name: earth ingress: - action: Deny from: - namespaces: matchLabels: {} # Match all namespaces. name: select-all-deny-all ``` ## Catatan penting Kebijakan jaringan di plugin Amazon VPC CNI untuk Kubernetes didukung dalam konfigurasi yang tercantum di bawah ini. + Versi 1.21.0 (atau yang lebih baru) plugin Amazon VPC CNI untuk kebijakan jaringan standar dan admin. + Cluster dikonfigurasi untuk `IPv6` alamat `IPv4` atau. + Anda dapat menggunakan kebijakan jaringan dengan [ grup keamanan untuk Pod](security-groups-for-pods.md). Dengan kebijakan jaringan, Anda dapat mengontrol semua komunikasi dalam cluster. Dengan grup keamanan untuk Pod, Anda dapat mengontrol akses ke AWS layanan dari aplikasi dalam Pod. + Anda dapat menggunakan kebijakan jaringan dengan pendeleg * asian jaringan * dan * awalan khusus*. ## Pertimbangan-pertimbangan **Arsitektur ** + Saat menerapkan plugin Amazon VPC CNI untuk kebijakan jaringan Kubernetes ke cluster Anda dengan plugin Amazon VPC CNI untuk Kubernetes, Anda dapat menerapkan kebijakan ke node Amazon EC2 Linux saja. Anda tidak dapat menerapkan kebijakan ke node Fargate atau Windows. + Kebijakan jaringan hanya berlaku untuk salah satu `IPv4` atau `IPv6` alamat, tetapi tidak keduanya. Dalam sebuah `IPv4` cluster, VPC CNI menetapkan `IPv4` alamat ke pod dan menerapkan kebijakan. `IPv4` Dalam sebuah `IPv6` cluster, VPC CNI menetapkan `IPv6` alamat ke pod dan menerapkan kebijakan. `IPv6` Setiap aturan kebijakan `IPv4` jaringan yang diterapkan pada `IPv6` cluster diabaikan. Setiap aturan kebijakan `IPv6` jaringan yang diterapkan pada `IPv4` cluster diabaikan. **Kebijakan Jaringan ** + Amazon EKS mengoptimalkan penegakan kebijakan jaringan untuk Pod yang memiliki set `metadata.ownerReferences` bidang. Ini termasuk Pod yang dikelola oleh pengontrol seperti Deployments,, StatefulSets, Jobs DaemonSets, dan. CronJobs Pod Mandiri yang dibuat secara langsung tanpa pengontrol tidak dis `metadata.ownerReferences` etel, dan penegakan kebijakan jaringan mungkin tidak berfungsi dengan andal untuk Pod ini. + Anda dapat menerapkan beberapa kebijakan jaringan ke Pod yang sama. Ketika dua atau lebih kebijakan yang memilih Pod yang sama dikonfigurasi, semua kebijakan diterapkan ke Pod. + Jumlah maksimum kombinasi port dan protokol untuk satu rentang alamat IP (CIDR) adalah 24 di semua kebijakan jaringan Anda. Selektor seperti memutuskan `namespaceSelector` untuk satu atau lebih CIDR. Jika beberapa pemilih menyelesaikan ke satu CIDR atau Anda menentukan CIDR langsung yang sama beberapa kali dalam kebijakan jaringan yang sama atau berbeda, semua ini diperhitungkan dalam batas ini. + Untuk salah satu layanan Kubernetes Anda, port layanan harus sama dengan port kontainer. Jika Anda menggunakan port bernama, gunakan nama yang sama di spesifikasi layanan juga. **Kebijakan Jaringan Admin ** 1. **Kebijakan tingkat admin (dievaluasi terlebih dahulu)**: Semua tingkat Admin ClusterNetworkPolicies dievaluasi sebelum kebijakan lainnya. Dalam tingkat Admin, kebijakan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Jenis tindakan menentukan apa yang terjadi selanjutnya. + **Tindakan tolak (prioritas tertinggi)**: Ketika kebijakan Admin dengan tindakan Tolak cocok dengan lalu lintas, lalu lintas tersebut segera diblokir terlepas dari kebijakan lainnya. Tidak ada lebih lanjut ClusterNetworkPolicy atau NetworkPolicy aturan yang diproses. Ini memastikan bahwa kontrol keamanan di seluruh organisasi tidak dapat diganti oleh kebijakan tingkat ruang nama. + **Izinkan tindakan**: Setelah aturan Tolak dievaluasi, kebijakan Admin dengan tindakan Izinkan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Ketika tindakan Izinkan cocok, lalu lintas diterima dan tidak ada evaluasi kebijakan lebih lanjut yang terjadi. Kebijakan ini dapat memberikan akses di beberapa ruang nama berdasarkan pemilih label, memberikan kontrol terpusat atas beban kerja mana yang dapat mengakses sumber daya tertentu. + **Tindakan lulus**: Tindakan lulus dalam kebijakan tingkat Admin mendelegasikan pengambilan keputusan ke tingkat yang lebih rendah. Saat lalu lintas cocok dengan aturan Pass, evaluasi akan melewatkan semua aturan tingkat Admin yang tersisa untuk lalu lintas tersebut dan melanjutkan langsung ke NetworkPolicy tingkat tersebut. Hal ini memungkinkan administrator untuk secara eksplisit mendelegasikan kontrol untuk pola lalu lintas tertentu ke tim aplikasi. Misalnya, Anda dapat menggunakan aturan Pass untuk mendelegasikan manajemen lalu lintas intra-namespace ke administrator namespace sambil mempertahankan kontrol ketat atas akses eksternal. 1. **Tingkat kebijakan jaringan**: Jika tidak ada kebijakan tingkat Admin yang cocok dengan Tolak atau Izinkan, atau jika tindakan Lulus dicocokkan, sumber daya dengan ruang nama akan dievaluasi selanjutnya NetworkPolicy . Kebijakan ini memberikan kontrol halus dalam ruang nama individual dan dikelola oleh tim aplikasi. Namespace-scoped kebijakan hanya bisa lebih ketat daripada kebijakan Admin. Mereka tidak dapat mengganti keputusan Tolak kebijakan Admin, tetapi mereka dapat membatasi lalu lintas lebih lanjut yang diizinkan atau dilewatkan oleh kebijakan Admin. 1. **Kebijakan Admin tingkat dasar**: Jika tidak ada kebijakan Admin atau lingkup ruang nama yang cocok dengan lalu lintas, tingkat Baseline dievaluasi. ClusterNetworkPolicies Ini memberikan postur keamanan default yang dapat diganti oleh kebijakan ruang nama, memungkinkan administrator untuk menetapkan default di seluruh organisasi sambil memberikan fleksibilitas tim untuk menyesuaikan sesuai kebutuhan. Kebijakan dasar dievaluasi dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). 1. **Penolakan default (jika tidak ada kebijakan yang cocok)**: Perilaku menolak secara default ini memastikan bahwa hanya koneksi yang diizinkan secara eksplisit yang diizinkan, mempertahankan postur keamanan yang kuat. **Migrasi ** + Jika cluster Anda saat ini menggunakan solusi pihak ketiga untuk mengelola kebijakan jaringan Kubernetes, Anda dapat menggunakan kebijakan yang sama dengan plugin Amazon VPC CNI untuk Kubernetes. Namun Anda harus menghapus solusi yang ada sehingga tidak mengelola kebijakan yang sama. **Awas** Sebaiknya setelah Anda menghapus solusi kebijakan jaringan, Anda mengganti semua node yang menerapkan solusi kebijakan jaringan. Ini karena peraturan lalu lintas mungkin tertinggal oleh pod solusi jika keluar tiba-tiba. **Instalasi ** + Fitur kebijakan jaringan membuat dan memerlukan C `PolicyEndpoint` ustom Resource Definition (CRD) yang dipanggil`policyendpoints.networking.k8s.aws`. `PolicyEndpoint`objek dari Sumber Daya Kustom dikelola oleh Amazon EKS. Anda tidak boleh memodifikasi atau menghapus sumber daya ini. + Jika Anda menjalankan pod yang menggunakan kredentif IAM peran instans atau terhubung ke EC2 IMDS, berhati-hatilah untuk memeriksa kebijakan jaringan yang akan memblokir akses ke EC2 IMDS. Anda mungkin perlu menambahkan kebijakan jaringan untuk mengizinkan akses ke EC2 IMDS. Untuk informasi selengkapnya, lihat [Metadata instans dan data pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dalam Panduan Pengguna Amazon EC2. Pod yang menggunakan peran * IAM untuk akun layanan * atau * EKS Pod Identity * tidak mengakses EC2 IMDS. + Plugin Amazon VPC CNI untuk Kubernetes tidak menerapkan kebijakan jaringan ke antarmuka jaringan tambahan untuk setiap pod, hanya antarmuka utama untuk setiap pod (). `eth0` Ini mempengaruhi arsitektur berikut: + `IPv6`pod dengan `ENABLE_V4_EGRESS` variabel disetel ke`true`. Variabel ini memungkinkan `IPv4` fitur keluar untuk menghubungkan pod IPv6 ke `IPv4` titik akhir seperti yang berada di luar cluster. Fitur `IPv4` keluar bekerja dengan membuat antarmuka jaringan tambahan dengan alamat IPv4 loopback lokal. + Saat menggunakan plugin jaringan beraneka seperti Multus. Karena plugin ini menambahkan antarmuka jaringan ke setiap pod, kebijakan jaringan tidak diterapkan pada plugin jaringan yang dirantai.