**Bantu tingkatkan 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 **Edit halaman ini pada GitHub** tautan 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. # Gunakan Kebijakan Jaringan dengan Mode Otomatis EKS ## Ikhtisar Ketika pelanggan menskalakan lingkungan aplikasi mereka menggunakan EKS, isolasi lalu lintas jaringan menjadi semakin mendasar untuk mencegah akses tidak sah ke sumber daya di dalam dan di luar cluster. Ini sangat penting dalam lingkungan multi-penyewa dengan beberapa beban kerja yang tidak terkait berjalan berdampingan di cluster. Kebijakan jaringan Kubernetes memungkinkan Anda untuk meningkatkan postur keamanan jaringan untuk beban kerja Kubernetes Anda, dan integrasinya dengan endpoint cluster-eksternal. Mode Otomatis EKS mendukung berbagai jenis kebijakan jaringan. ### Isolasi lapisan 3 dan 4 Kebijakan jaringan Kubernetes standar beroperasi pada lapisan 3 dan 4 dari model jaringan OSI dan memungkinkan Anda untuk mengontrol arus lalu lintas di alamat IP atau tingkat port dalam cluster Amazon EKS Anda. #### Kasus penggunaan + Segmentasikan lalu lintas jaringan antar beban kerja untuk memastikan bahwa hanya aplikasi terkait yang dapat berbicara satu sama lain. + Mengisolasi penyewa di tingkat namespace menggunakan kebijakan untuk menegakkan pemisahan jaringan. ### Penegakan berbasis DNS Pelanggan biasanya menyebarkan beban kerja di EKS yang merupakan bagian dari lingkungan terdistribusi yang lebih luas, beberapa di antaranya harus berkomunikasi dengan sistem dan layanan di luar cluster (lalu lintas utara). Sistem dan layanan ini dapat berada di AWS cloud atau di luar AWS sama sekali. Kebijakan berbasis Domain Name System (DNS) memungkinkan Anda untuk memperkuat postur keamanan Anda dengan mengadopsi pendekatan yang lebih stabil dan dapat diprediksi untuk mencegah akses tidak sah dari Pod ke sumber daya eksternal cluster atau endpoint. Mekanisme ini menghilangkan kebutuhan untuk melacak dan mengizinkan daftar alamat IP tertentu secara manual. Dengan mengamankan sumber daya dengan pendekatan berbasis DNS, Anda juga memiliki lebih banyak fleksibilitas untuk memperbarui infrastruktur eksternal tanpa harus melonggarkan postur keamanan Anda atau memodifikasi kebijakan jaringan di tengah perubahan pada server dan host hulu. Anda dapat memfilter lalu lintas keluar ke titik akhir eksternal menggunakan Nama Domain Berkualitas Penuh (FQDN), atau pola yang cocok untuk nama domain DNS. Ini memberi Anda fleksibilitas tambahan untuk memperluas akses ke beberapa subdomain yang terkait dengan titik akhir cluster-eksternal tertentu. #### Kasus penggunaan + Standarisasi pada pendekatan berbasis DNS untuk memfilter akses dari lingkungan Kubernetes ke endpoint cluster-eksternal. + Akses aman ke AWS layanan di lingkungan multi-penyewa. + Kelola akses jaringan dari pod ke beban kerja on-prem di lingkungan cloud Hybrid Anda. ### Aturan admin (atau cakupan cluster) Dalam beberapa kasus, seperti skenario multi-tenant, pelanggan mungkin memiliki persyaratan untuk menegakkan standar keamanan jaringan yang berlaku untuk seluruh cluster. Alih-alih mendefinisikan dan mempertahankan kebijakan yang berbeda secara berulang untuk setiap namespace, Anda dapat menggunakan satu kebijakan untuk mengelola kontrol akses jaringan secara terpusat untuk beban kerja yang berbeda di klaster, terlepas dari namespace mereka. Jenis kebijakan ini memungkinkan Anda memperluas cakupan penegakan aturan pemfilteran jaringan yang diterapkan pada lapisan 3, lapisan 4, dan saat menggunakan aturan DNS. #### Kasus penggunaan + Kelola kontrol akses jaringan secara terpusat untuk semua (atau sebagian dari) beban kerja di kluster 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. ## Memulai ### Prasyarat + Cluster Amazon EKS dengan Mode Otomatis EKS diaktifkan + kubectl dikonfigurasi untuk terhubung ke klaster Anda ### Langkah 1: Aktifkan Pengontrol Kebijakan Jaringan Untuk menggunakan kebijakan jaringan dengan Mode Otomatis EKS, pertama-tama Anda harus mengaktifkan Network Policy Controller dengan menerapkan a ConfigMap ke cluster Anda. 1. Buat file bernama `enable-network-policy.yaml` dengan konten berikut: ``` apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true" ``` 1. Terapkan ConfigMap ke cluster Anda: ``` kubectl apply -f enable-network-policy.yaml ``` ### Langkah 2: Buat dan uji kebijakan jaringan Kluster Mode Otomatis EKS Anda sekarang dikonfigurasi untuk mendukung kebijakan jaringan Kubernetes. Anda dapat menguji ini dengan[Bintang demo kebijakan jaringan untuk Amazon EKS](network-policy-stars-demo.md). ### Langkah 3: Sesuaikan konfigurasi Agen Kebijakan Jaringan di Kelas Node (Opsional) Anda dapat membuat Kelas Node baru secara opsional untuk mengubah perilaku default Agen Kebijakan Jaringan pada node atau mengaktifkan pencatatan peristiwa Kebijakan Jaringan. Untuk melakukannya, ikuti langkah-langkah berikut: 1. Membuat atau mengedit file YAMM Kelas Node (misalnya,`nodeclass-network-policy.yaml`) dengan konten berikut: ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: network-policy-config spec: # Optional: Changes default network policy behavior networkPolicy: DefaultAllow # Optional: Enables logging for network policy events networkPolicyEventLogs: Enabled # Include other Node Class configurations as needed ``` 1. Terapkan konfigurasi Node Class ke cluster Anda: ``` kubectl apply -f nodeclass-network-policy.yaml ``` 1. Verifikasi bahwa Kelas Node telah dibuat: ``` kubectl get nodeclass network-policy-config ``` 1. Perbarui Node Pool Anda untuk menggunakan Kelas Node ini. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md). ## Bagaimana cara kerjanya? ### Kebijakan jaringan berbasis DNS ![\[Ilustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-1.png) ![\[llustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-2.png) 1. Tim platform menerapkan kebijakan berbasis DNS ke cluster EKS. 1. Network Policy Controller bertanggung jawab untuk memantau pembuatan kebijakan dalam klaster dan kemudian merekonsiliasi titik akhir kebijakan. Dalam kasus penggunaan ini, pengontrol kebijakan jaringan menginstruksikan agen node untuk memfilter permintaan DNS berdasarkan domain yang terdaftar izinkan dalam kebijakan yang dibuat. Nama domain diijinkan menggunakan FQDN atau nama domain yang cocok dengan pola yang ditentukan dalam konfigurasi sumber daya Kubernetes. 1. Workload Sebuah upaya untuk menyelesaikan IP untuk titik akhir cluster-eksternal. Permintaan DNS pertama kali melalui proxy yang memfilter permintaan tersebut berdasarkan daftar izinkan yang diterapkan melalui kebijakan jaringan. 1. Setelah permintaan DNS melewati daftar izinkan filter DNS, itu diproksi ke CoreDNS, 1. CoreDNS pada gilirannya mengirimkan permintaan ke Resolver DNS Eksternal (Amazon Route 53 Resolver) untuk mendapatkan daftar alamat IP di belakang nama domain. 1. Yang diselesaikan IPs dengan TTL dikembalikan sebagai respons terhadap permintaan DNS. Ini kemudian IPs ditulis dalam peta eBPF yang digunakan pada langkah berikutnya untuk penegakan lapisan IP. 1. Probe eBPF yang terpasang pada antarmuka Pod veth kemudian akan memfilter lalu lintas keluar dari Workload A ke endpoint cluster-eksternal berdasarkan aturan yang berlaku. Ini memastikan pod hanya dapat mengirim lalu lintas cluster-eksternal ke domain yang diizinkan IPs yang terdaftar. Validitas ini IPs didasarkan pada TTL yang diambil dari Resolver DNS Eksternal (Amazon Route 53 Resolver). #### Menggunakan Kebijakan Jaringan Aplikasi `ApplicationNetworkPolicy`Ini menggabungkan kemampuan kebijakan jaringan Kubernetes standar dengan pemfilteran berbasis DNS pada tingkat namespace menggunakan Custom Resource Definition (CRD) tunggal. Oleh karena itu, `ApplicationNetworkPolicy` dapat digunakan untuk: 1. Mendefinisikan pembatasan pada lapisan 3 dan 4 dari tumpukan jaringan menggunakan blok IP dan nomor port. 1. Mendefinisikan aturan yang beroperasi pada lapisan 7 dari tumpukan jaringan dan memungkinkan Anda memfilter lalu lintas berdasarkan FQDNs. **penting** Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. `ApplicationNetworkPolicy`mendukung semua bidang Kubernetes standar`NetworkPolicy`, dengan filter FQDN tambahan untuk aturan jalan keluar. **Awas** Jangan gunakan nama yang sama untuk `ApplicationNetworkPolicy` dan a `NetworkPolicy` dalam namespace yang sama. Jika nama bertabrakan, `PolicyEndpoints` objek yang dihasilkan mungkin tidak mencerminkan salah satu kebijakan dengan benar. Kedua sumber daya diterima tanpa kesalahan, membuat masalah ini sulit didiagnosis. Untuk mengatasi konflik penamaan, ganti nama `ApplicationNetworkPolicy` atau `NetworkPolicy` jadi mereka unik dalam namespace, lalu verifikasi bahwa `PolicyEndpoints` objek yang sesuai diperbarui dengan benar. #### Contoh Anda memiliki beban kerja di kluster Mode Otomatis EKS Anda yang perlu berkomunikasi dengan aplikasi on-prem yang berada di belakang penyeimbang beban dengan nama DNS. Anda dapat mencapai ini menggunakan kebijakan jaringan berikut: ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ApplicationNetworkPolicy metadata: name: my-onprem-app-egress namespace: galaxy spec: podSelector: matchLabels: role: backend policyTypes: - Egress egress: - to: - domainNames: - "myapp.mydomain.com" ports: - protocol: TCP port: 8080 ``` **Pada tingkat jaringan Kubernetes, ini akan memungkinkan jalan keluar dari setiap pod di namespace “galaksi” yang diberi label `role: backend` untuk terhubung ke nama domain myapp.mydomain.com pada port TCP 8080.** Selain itu, Anda perlu mengatur konektivitas jaringan untuk lalu lintas keluar dari VPC Anda ke pusat data perusahaan Anda. ![\[llustrasi beban kerja di EKS Auto berkomunikasi dengan aplikasi di prem\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/eks-auto-to-on-prem.png) ### Kebijakan jaringan admin (atau cluster) ![\[llustrasi urutan evaluasi untuk kebijakan jaringan di EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/evaluation-order.png) #### Menggunakan Kebijakan Jaringan Cluster Saat menggunakan`ClusterNetworkPolicy`, kebijakan tingkat Admin dievaluasi terlebih dahulu dan tidak dapat diganti. Ketika kebijakan tingkat Admin telah dievaluasi, kebijakan cakupan namespace standar digunakan untuk menjalankan aturan segmentasi jaringan yang diterapkan. Hal ini dapat dicapai dengan menggunakan salah satu `ApplicationNetworkPolicy` atau`NetworkPolicy`. Terakhir, aturan tingkat dasar yang menentukan batasan jaringan default untuk beban kerja klaster akan diberlakukan. Aturan tingkat dasar ini **dapat** diganti dengan kebijakan cakupan namespace jika diperlukan. #### Contoh Anda memiliki aplikasi di cluster Anda yang ingin Anda isolasi dari beban kerja penyewa lainnya. Anda dapat secara eksplisit memblokir lalu lintas klaster 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 ``` ## Pertimbangan-pertimbangan ### Memahami urutan evaluasi kebijakan Kemampuan kebijakan jaringan yang didukung di EKS dievaluasi dalam urutan tertentu untuk memastikan manajemen lalu lintas yang dapat diprediksi dan aman. Oleh karena itu, penting untuk memahami alur evaluasi untuk merancang postur keamanan jaringan yang efektif untuk lingkungan Anda. 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. + **Lulus tindakan**: Melewati tindakan dalam kebijakan tingkat Admin mendelegasikan pengambilan keputusan ke tingkat yang lebih rendah. Ketika lalu lintas cocok dengan aturan Pass, evaluasi melewatkan semua aturan tingkat Admin yang tersisa untuk lalu lintas tersebut dan melanjutkan langsung ke tingkat. NetworkPolicy 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 Pass dicocokkan, sumber daya cakupan nama dan sumber daya tradisional akan dievaluasi berikutnya ApplicationNetworkPolicy . NetworkPolicy Kebijakan ini memberikan kontrol halus dalam ruang nama individu dan dikelola oleh tim aplikasi. Kebijakan dengan cakupan ruang nama hanya bisa lebih ketat daripada kebijakan Admin. Mereka tidak dapat mengesampingkan keputusan Tolak kebijakan Admin, tetapi mereka dapat membatasi lalu lintas yang diizinkan atau disahkan oleh kebijakan Admin. 1. **Kebijakan Admin tingkat dasar: Jika tidak ada kebijakan** dengan cakupan Admin atau ruang nama yang cocok dengan lalu lintas, tingkat dasar akan dievaluasi. ClusterNetworkPolicies Ini memberikan postur keamanan default yang dapat diganti dengan kebijakan cakupan ruang nama, memungkinkan administrator untuk menetapkan default di seluruh organisasi sambil memberi tim fleksibilitas untuk menyesuaikan sesuai kebutuhan. Kebijakan dasar dievaluasi dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). 1. **Penyangkalan default (jika tidak ada kebijakan yang cocok)**: deny-by-default Perilaku ini memastikan bahwa hanya koneksi yang diizinkan secara eksplisit yang diizinkan, mempertahankan postur keamanan yang kuat. ### Menerapkan prinsip hak istimewa paling sedikit + **Mulailah dengan kebijakan restriktif dan tambahkan izin secara bertahap sesuai kebutuhan** - Mulailah dengan menerapkan deny-by-default kebijakan di tingkat klaster, lalu tambahkan aturan izin secara bertahap saat Anda memvalidasi persyaratan konektivitas yang sah. Pendekatan ini memaksa tim untuk secara eksplisit membenarkan setiap koneksi eksternal, menciptakan lingkungan yang lebih aman dan dapat diaudit. + **Secara teratur mengaudit dan menghapus aturan kebijakan yang tidak digunakan** - Kebijakan jaringan dapat terakumulasi dari waktu ke waktu seiring berkembangnya aplikasi, meninggalkan aturan usang yang tidak perlu memperluas permukaan serangan Anda. Terapkan proses peninjauan rutin untuk mengidentifikasi dan menghapus aturan kebijakan yang tidak lagi diperlukan, memastikan postur keamanan Anda tetap ketat dan dapat dipelihara. + **Gunakan nama domain tertentu daripada pola luas bila memungkinkan** - Meskipun pola wildcard seperti `*.amazonaws.com` memberikan kenyamanan, mereka juga memberikan akses ke berbagai layanan. Bila memungkinkan, tentukan nama domain yang tepat seperti `s3.us-west-2.amazonaws.com` membatasi akses hanya ke layanan spesifik yang dibutuhkan aplikasi Anda, mengurangi risiko pergerakan lateral jika beban kerja terganggu. ### Menggunakan kebijakan berbasis DNS di EKS + Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. Jika Anda menjalankan cluster mode campuran (terdiri dari node pekerja EKS Auto dan non EKS Auto), aturan berbasis DNS Anda hanya efektif di node pekerja mode EKS Auto (instans terkelola EC2). ### Memvalidasi kebijakan DNS Anda + **Gunakan klaster pementasan yang mencerminkan topologi jaringan produksi untuk pengujian** - Lingkungan pementasan Anda harus mereplikasi arsitektur jaringan, dependensi eksternal, dan pola konektivitas produksi untuk memastikan pengujian kebijakan yang akurat. Ini termasuk pencocokan konfigurasi VPC, perilaku resolusi DNS, dan akses ke layanan eksternal yang sama yang dibutuhkan oleh beban kerja produksi Anda. + **Terapkan pengujian otomatis untuk jalur jaringan kritis** - Buat pengujian otomatis yang memvalidasi konektivitas ke layanan eksternal penting sebagai bagian dari CI/CD pipeline Anda. Tes ini harus memverifikasi bahwa arus lalu lintas yang sah diizinkan sementara koneksi yang tidak sah diblokir, memberikan validasi berkelanjutan bahwa kebijakan jaringan Anda mempertahankan postur keamanan yang benar saat infrastruktur Anda berkembang. + **Pantau perilaku aplikasi setelah perubahan kebijakan** - Setelah menerapkan kebijakan jaringan baru atau yang dimodifikasi ke produksi, pantau log aplikasi, tingkat kesalahan, dan metrik kinerja dengan cermat untuk mengidentifikasi masalah konektivitas apa pun dengan cepat. Tetapkan prosedur rollback yang jelas sehingga Anda dapat dengan cepat mengembalikan perubahan kebijakan jika menyebabkan perilaku aplikasi atau gangguan layanan yang tidak terduga. ### Interaksi dengan Amazon Route 53 DNS firewall Kebijakan Admin dan Jaringan EKS dievaluasi terlebih dahulu pada tingkat pod saat lalu lintas dimulai. Jika kebijakan jaringan EKS mengizinkan jalan keluar ke domain tertentu, pod akan melakukan query DNS yang mencapai Route 53 Resolver. Pada titik ini, aturan Route 53 DNS Firewall dievaluasi. Jika DNS Firewall memblokir kueri domain, resolusi DNS gagal dan koneksi tidak dapat dibuat, meskipun kebijakan jaringan EKS mengizinkannya. Ini menciptakan lapisan keamanan yang saling melengkapi: Kebijakan jaringan berbasis DNS EKS memberikan kontrol jalan keluar tingkat pop untuk persyaratan akses khusus aplikasi dan batas keamanan multi-penyewa, sementara DNS Firewall memberikan perlindungan luas VPC terhadap domain berbahaya yang diketahui dan memberlakukan blokir di seluruh organisasi.