Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Keamanan jaringan **Tip** [Jelajahi](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) praktik terbaik melalui lokakarya Amazon EKS. Keamanan jaringan memiliki beberapa aspek. Yang pertama melibatkan penerapan aturan yang membatasi arus lalu lintas jaringan antar layanan. Yang kedua melibatkan enkripsi lalu lintas saat sedang dalam perjalanan. Mekanisme untuk menerapkan langkah-langkah keamanan ini pada EKS bervariasi tetapi sering kali mencakup item-item berikut: ## Kontrol lalu lintas + Kebijakan Jaringan + Grup Keamanan ## Enkripsi jaringan + Layanan Mesh + Antarmuka Jaringan Kontainer () CNIs + Pengontrol Ingress dan Load Balancer + Contoh Nitro + ACM Private CA dengan manajer sertifikat ## Kebijakan jaringan Dalam klaster Kubernetes, semua komunikasi Pod ke Pod diperbolehkan secara default. Meskipun fleksibilitas ini dapat membantu mempromosikan eksperimen, itu tidak dianggap aman. Kebijakan jaringan Kubernetes memberi Anda mekanisme untuk membatasi lalu lintas jaringan antar Pod (sering disebut sebagai lalu lintas Timur/Barat) serta antara Pod dan layanan eksternal. Kebijakan jaringan Kubernetes beroperasi pada lapisan 3 dan 4 dari model OSI. Kebijakan jaringan menggunakan pod, pemilih namespace, dan label untuk mengidentifikasi pod sumber dan tujuan, tetapi juga dapat menyertakan alamat IP, nomor port, protokol, atau kombinasi keduanya. Kebijakan Jaringan dapat diterapkan pada koneksi Inbound atau Outbound ke pod, sering disebut aturan Ingress dan Egress. Dengan dukungan kebijakan jaringan native dari Amazon VPC CNI Plugin, Anda dapat menerapkan kebijakan jaringan untuk mengamankan lalu lintas jaringan di klaster kubernetes. Ini terintegrasi dengan API Kebijakan Jaringan Kubernetes hulu, memastikan kompatibilitas dan kepatuhan terhadap standar Kubernetes. Anda dapat menentukan kebijakan menggunakan [pengidentifikasi](https://kubernetes.io/docs/concepts/services-networking/network-policies/) berbeda yang didukung oleh API upstream. Secara default, semua lalu lintas masuk dan keluar diizinkan ke pod. Ketika kebijakan jaringan dengan PolicyType Ingress ditentukan, hanya koneksi yang diizinkan ke dalam pod adalah yang berasal dari node pod dan yang diizinkan oleh aturan ingress. Hal yang sama berlaku untuk aturan jalan keluar. Jika beberapa aturan didefinisikan, maka penyatuan semua aturan diperhitungkan saat membuat keputusan. Dengan demikian, urutan evaluasi tidak mempengaruhi hasil kebijakan. **penting** Saat pertama kali menyediakan kluster EKS, fungsionalitas Kebijakan Jaringan VPC CNI tidak diaktifkan secara default. Pastikan Anda menerapkan versi Add-on VPC CNI yang didukung dan `ENABLE_NETWORK_POLICY` setel flag `true` ke add-on vpc-cni untuk mengaktifkannya. Lihat [Panduan Pengguna Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html) untuk petunjuk terperinci. ## Rekomendasi ### Memulai dengan Kebijakan Jaringan - Ikuti Prinsip Hak Istimewa Terkecil #### Buat kebijakan penolakan default Seperti halnya kebijakan RBAC, disarankan untuk mengikuti prinsip akses yang paling tidak memiliki hak istimewa dengan kebijakan jaringan. Mulailah dengan membuat kebijakan tolak semua yang membatasi semua lalu lintas masuk dan keluar dengan namespace. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: default spec: podSelector: {} policyTypes: - Ingress - Egress ``` **default-menyangkal** ![\[default-menyangkal\]](http://docs.aws.amazon.com/id_id/eks/latest/best-practices/images/security/default-deny.jpg) **catatan** Gambar di atas dibuat oleh penampil kebijakan jaringan dari [Tufin](https://orca.tufin.io/netpol/). #### Buat aturan untuk mengizinkan kueri DNS Setelah Anda memiliki aturan penolakan semua default, Anda dapat mulai membuat layering pada aturan tambahan, seperti aturan yang memungkinkan pod untuk menanyakan CoreDNS untuk resolusi nama. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns-access namespace: default spec: podSelector: matchLabels: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 ``` **allow-dns-access** ![\[allow-dns-access\]](http://docs.aws.amazon.com/id_id/eks/latest/best-practices/images/security/allow-dns-access.jpg) #### Tambahkan aturan secara bertahap untuk memungkinkan aliran lalu lintas antar namespace/pod secara selektif Memahami persyaratan aplikasi dan membuat aturan masuk dan keluar berbutir halus sesuai kebutuhan. Contoh di bawah ini menunjukkan cara membatasi lalu lintas masuk pada port 80 ke `app-one` dari. `client-one` Ini membantu meminimalkan permukaan serangan dan mengurangi risiko akses yang tidak sah. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-ingress-app-one namespace: default spec: podSelector: matchLabels: k8s-app: app-one policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: k8s-app: client-one ports: - protocol: TCP port: 80 ``` **allow-ingress-app-one** ![\[allow-ingress-app-one\]](http://docs.aws.amazon.com/id_id/eks/latest/best-practices/images/security/allow-ingress-app-one.png) ### Pemantauan penegakan kebijakan jaringan + **Gunakan editor Kebijakan Jaringan** + [Editor kebijakan jaringan](https://networkpolicy.io/) membantu visualisasi, skor keamanan, pembuatan otomatis dari log aliran jaringan + Membangun kebijakan jaringan dengan cara yang interaktif + **Log Audit** + Tinjau log audit cluster EKS Anda secara teratur + Log audit menyediakan banyak informasi tentang tindakan apa yang telah dilakukan pada klaster Anda termasuk perubahan kebijakan jaringan + Gunakan informasi ini untuk melacak perubahan pada kebijakan jaringan Anda dari waktu ke waktu dan mendeteksi perubahan yang tidak sah atau tidak terduga + **Pengujian otomatis** + Terapkan pengujian otomatis dengan membuat lingkungan pengujian yang mencerminkan lingkungan produksi Anda dan menerapkan beban kerja secara berkala yang mencoba melanggar kebijakan jaringan Anda. + **Metrik pemantauan** + Konfigurasikan agen observabilitas Anda untuk mengikis metrik prometheus dari agen node VPC CNI, yang memungkinkan untuk memantau kesehatan agen, dan kesalahan sdk. + **Kebijakan Jaringan Audit secara teratur** + Audit Kebijakan Jaringan Anda secara berkala untuk memastikan bahwa mereka memenuhi persyaratan aplikasi Anda saat ini. Saat aplikasi Anda berkembang, audit memberi Anda kesempatan untuk menghapus aturan masuk, keluar yang berlebihan dan memastikan bahwa aplikasi Anda tidak memiliki izin yang berlebihan. + **Pastikan Kebijakan Jaringan ada menggunakan Open Policy Agent (OPA)** + Gunakan Kebijakan OPA seperti yang ditunjukkan di bawah ini untuk memastikan Kebijakan Jaringan selalu ada sebelum melakukan orientasi pada pod aplikasi. Kebijakan ini menolak orientasi pod k8s dengan label `k8s-app: sample-app` jika kebijakan jaringan terkait tidak ada. ``` package kubernetes.admission import data.kubernetes.networkpolicies deny[msg] { input.request.kind.kind == "Pod" pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels} contains_label(pod_label_value, "sample-app") np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels} not contains_label(np_label_value, "sample-app") msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name]) } contains_label(arr, val) { arr[_] == val } ``` ### Pemecahan masalah #### Pantau log vpc-network-policy-controller agen simpul Aktifkan log manajer pengontrol bidang Kontrol EKS untuk mendiagnosis fungsionalitas kebijakan jaringan. Anda dapat mengalirkan log bidang kontrol ke grup CloudWatch log dan menggunakan [wawasan CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) untuk melakukan kueri lanjutan. Dari log, Anda dapat melihat objek titik akhir pod yang diselesaikan menjadi Kebijakan Jaringan, status rekonsiliasi kebijakan, dan debug jika kebijakan berfungsi seperti yang diharapkan. Selain itu, Amazon VPC CNI memungkinkan Anda mengaktifkan pengumpulan dan ekspor log penegakan kebijakan ke [Amazon Cloudwatch](https://aws.amazon.com/cloudwatch/) dari node pekerja EKS. Setelah diaktifkan, Anda dapat memanfaatkan [CloudWatchWawasan Kontainer](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) untuk memberikan wawasan tentang penggunaan yang terkait dengan Kebijakan Jaringan. Amazon VPC CNI juga mengirimkan SDK yang menyediakan antarmuka untuk berinteraksi dengan program eBPF pada node. SDK diinstal saat `aws-node` dikerahkan ke node. Anda dapat menemukan biner SDK yang diinstal di bawah `/opt/cni/bin` direktori pada node. Saat diluncurkan, SDK menyediakan dukungan untuk fungsionalitas mendasar seperti memeriksa program dan peta eBPF. ``` sudo /opt/cni/bin/aws-eks-na-cli ebpf progs ``` #### Log metadata lalu lintas jaringan [AWS VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) menangkap metadata tentang lalu lintas yang mengalir melalui VPC, seperti alamat IP sumber dan tujuan serta port bersama dengan paket yang diterima/dijatuhkan. Informasi ini dapat dianalisis untuk mencari aktivitas yang mencurigakan atau tidak biasa antara sumber daya dalam VPC, termasuk Pod. Namun, karena alamat IP pod sering berubah saat diganti, Flow Logs mungkin tidak cukup dengan sendirinya. Calico Enterprise memperluas Flow Logs dengan label pod dan metadata lainnya, sehingga lebih mudah untuk menguraikan arus lalu lintas antar pod. ## Grup keamanan [EKS menggunakan AWS VPC Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) (SGs) untuk mengontrol lalu lintas antara bidang kontrol Kubernetes dan node pekerja klaster. Grup keamanan juga digunakan untuk mengontrol lalu lintas antara node pekerja, dan sumber daya VPC lainnya, dan alamat IP eksternal. Saat Anda menyediakan kluster EKS (dengan Kubernetes versi 1.14-eks.3 atau lebih tinggi), grup keamanan klaster akan dibuat secara otomatis untuk Anda. Grup keamanan ini memungkinkan komunikasi yang tidak terkekang antara bidang kontrol EKS dan node dari grup node terkelola. Untuk mempermudah, Anda disarankan untuk menambahkan cluster SG ke semua grup node, termasuk grup node yang tidak dikelola. Sebelum Kubernetes versi 1.14 dan EKS versi eks.3, ada grup keamanan terpisah yang dikonfigurasi untuk bidang kontrol EKS dan grup node. Aturan minimum dan yang disarankan untuk control plane dan grup keamanan grup node dapat ditemukan di https://docs.aws.amazon.com/eks/ latest/userguide/sec -group-reqs.html. Aturan minimum untuk *grup keamanan bidang kontrol* memungkinkan port 443 masuk dari node pekerja SG. Aturan inilah yang memungkinkan kubelet berkomunikasi dengan server API Kubernetes. Ini juga mencakup port 10250 untuk lalu lintas keluar ke node pekerja SG; 10250 adalah port yang didengarkan kubelet. Demikian pula, aturan *grup node* minimum memungkinkan port 10250 masuk dari bidang kontrol SG dan 443 keluar ke bidang kontrol SG. Akhirnya ada aturan yang memungkinkan komunikasi tak terkekang antara node dalam grup node. Jika Anda perlu mengontrol komunikasi antara layanan yang berjalan di dalam klaster dan layanan yang dijalankan di luar klaster seperti database RDS, pertimbangkan [grup keamanan untuk Pod](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html). Dengan grup keamanan untuk Pod, Anda dapat menetapkan grup keamanan yang **ada** ke kumpulan pod. **Awas** Jika Anda mereferensikan grup keamanan yang tidak ada sebelum pembuatan pod, pod tidak akan dijadwalkan. Anda dapat mengontrol Pod mana yang ditetapkan ke grup keamanan dengan membuat `SecurityGroupPolicy` objek dan menentukan sebuah `PodSelector` atau sebuah`ServiceAccountSelector`. Menyetel selector ke `{}` akan menetapkan SGs referensi `SecurityGroupPolicy` ke semua pod di namespace atau semua Account Layanan di namespace. Pastikan Anda telah membiasakan diri dengan semua [pertimbangan](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html#security-groups-pods-considerations) sebelum menerapkan grup keamanan untuk pod. **penting** Jika Anda menggunakan SGs Pod, Anda **harus** membuat SGs yang memungkinkan port 53 keluar ke grup keamanan klaster. Demikian pula, Anda **harus** memperbarui grup keamanan klaster untuk menerima lalu lintas masuk port 53 dari grup keamanan pod. **penting** [Batasan untuk grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups) masih berlaku saat menggunakan grup keamanan untuk pod, jadi gunakan dengan bijaksana. **penting** Anda **harus** membuat aturan untuk lalu lintas masuk dari grup keamanan klaster (kubelet) untuk semua probe yang dikonfigurasi untuk pod. **penting** Grup keamanan untuk pod bergantung pada fitur yang dikenal sebagai [trunking ENI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html) yang dibuat untuk meningkatkan kepadatan ENI dari instans EC2. Ketika sebuah pod ditugaskan ke SG, pengontrol VPC mengaitkan ENI cabang dari grup node dengan pod. Jika tidak ada cukup cabang yang ENIs tersedia di grup node pada saat pod dijadwalkan, pod akan tetap dalam status tertunda. Jumlah cabang yang dapat didukung oleh ENIs instance bervariasi menurut instance type/family. See https://docs.aws.amazon.com/eks/latest/userguide/security - groups-for-pods .html\$1 supported-instance-types untuk detail lebih lanjut. Meskipun grup keamanan untuk pod menawarkan cara asli AWS untuk mengontrol lalu lintas jaringan di dalam dan di luar klaster Anda tanpa overhead daemon kebijakan, opsi lain tersedia. Misalnya, mesin kebijakan Cilium memungkinkan Anda untuk mereferensikan nama DNS dalam kebijakan jaringan. Calico Enterprise menyertakan opsi untuk memetakan kebijakan jaringan ke grup keamanan AWS. Jika Anda telah menerapkan mesh layanan seperti Istio, Anda dapat menggunakan gateway keluar untuk membatasi jalan keluar jaringan ke domain atau alamat IP tertentu yang sepenuhnya memenuhi syarat. Untuk informasi lebih lanjut tentang opsi ini, baca seri tiga bagian tentang [kontrol lalu lintas jalan keluar di](https://istio.io/blog/2019/egress-traffic-control-in-istio-part-1/) Istio. ## Kapan menggunakan Kebijakan Jaringan vs Grup Keamanan untuk Pod? ### Kapan menggunakan kebijakan jaringan Kubernetes + **Mengontrol pod-to-pod lalu lintas** + Cococok untuk mengontrol lalu lintas jaringan antar pod di dalam cluster (lalu lintas timur-barat) + **Kontrol lalu lintas di alamat IP atau tingkat port (lapisan OSI 3 atau 4)** ### Kapan menggunakan grup AWS Security untuk pod (SGP) + **Manfaatkan konfigurasi AWS yang ada** + Jika Anda sudah memiliki kumpulan grup keamanan EC2 kompleks yang mengelola akses ke layanan AWS dan Anda memigrasikan aplikasi dari instans EC2 ke EKS, SGPs dapat menjadi pilihan yang sangat baik yang memungkinkan Anda untuk menggunakan kembali sumber daya grup keamanan dan menerapkannya ke pod Anda. + **Kontrol akses ke layanan AWS** + Aplikasi Anda yang berjalan dalam kluster EKS ingin berkomunikasi dengan layanan AWS lainnya (database RDS), digunakan SGPs sebagai mekanisme yang efisien untuk mengontrol lalu lintas dari pod ke layanan AWS. + **Isolasi lalu lintas Pod & Node** + Jika Anda ingin benar-benar memisahkan lalu lintas pod dari lalu lintas node lainnya, gunakan SGP dalam `POD_SECURITY_GROUP_ENFORCING_MODE=strict` mode. ### Praktik terbaik menggunakan grup Keamanan untuk Pod dan Kebijakan Jaringan + **Keamanan berlapis** + Gunakan kombinasi kebijakan jaringan SGP dan kubernetes untuk pendekatan keamanan berlapis + Gunakan SGPs untuk membatasi akses tingkat jaringan ke layanan AWS yang bukan bagian dari klaster, sementara kebijakan jaringan kubernetes dapat membatasi lalu lintas jaringan antar pod di dalam klaster + **Prinsip hak istimewa yang paling kecil** + Hanya izinkan lalu lintas yang diperlukan antara pod atau ruang nama + **Segmentasikan aplikasi Anda** + Jika memungkinkan, segmentasikan aplikasi berdasarkan kebijakan jaringan untuk mengurangi radius ledakan jika aplikasi dikompromikan + **Jaga kebijakan tetap sederhana dan jelas** + Kebijakan jaringan Kubernetes bisa sangat terperinci dan kompleks, yang terbaik adalah membuatnya sesederhana mungkin untuk mengurangi risiko kesalahan konfigurasi dan memudahkan overhead manajemen + **Kurangi permukaan serangan** + Minimalkan permukaan serangan dengan membatasi eksposur aplikasi Anda **penting** Grup Keamanan untuk Pod menyediakan dua mode penegakan: `strict` dan`standard`. Anda harus menggunakan `standard` mode saat menggunakan Kebijakan Jaringan dan Grup Keamanan untuk fitur pod di klaster EKS. Ketika datang ke keamanan jaringan, pendekatan berlapis seringkali merupakan solusi yang paling efektif. Menggunakan kebijakan jaringan kubernetes dan SGP dalam kombinasi dapat memberikan defense-in-depth strategi yang kuat untuk aplikasi Anda yang berjalan di EKS. ## Penegakan Kebijakan Service Mesh atau kebijakan jaringan Kubernetes A `service mesh` adalah lapisan infrastruktur khusus yang dapat Anda tambahkan ke aplikasi Anda. Ini memungkinkan Anda untuk secara transparan menambahkan kemampuan seperti observabilitas, manajemen lalu lintas, dan keamanan, tanpa menambahkannya ke kode Anda sendiri. Service mesh memberlakukan kebijakan pada Layer 7 (aplikasi) model OSI sedangkan kebijakan jaringan kubernetes beroperasi pada Layer 3 (network) dan Layer 4 (transport). Ada banyak penawaran di ruang ini seperti AWSAppMesh, Istio, Linkerd, dll., ### Kapan menggunakan Service mesh untuk penegakan kebijakan + Memiliki investasi yang ada di service mesh + Membutuhkan kemampuan yang lebih canggih seperti manajemen lalu lintas, observabilitas & keamanan + Kontrol lalu lintas, penyeimbangan beban, pemutusan sirkuit, pembatasan laju, batas waktu, dll. + Wawasan terperinci tentang kinerja layanan Anda (latensi, tingkat kesalahan, permintaan per detik, volume permintaan, dll.) + Anda ingin menerapkan dan memanfaatkan mesh layanan untuk fitur keamanan seperti mTL ### Pilih kebijakan jaringan Kubernetes untuk kasus penggunaan yang lebih sederhana + Batasi pod mana yang dapat berkomunikasi satu sama lain + Kebijakan jaringan membutuhkan sumber daya yang lebih sedikit daripada mesh layanan sehingga cocok untuk kasus penggunaan yang lebih sederhana atau untuk cluster yang lebih kecil di mana overhead menjalankan dan mengelola mesh layanan mungkin tidak dapat dibenarkan **catatan** Kebijakan jaringan dan Service mesh juga dapat digunakan bersama. Gunakan kebijakan jaringan untuk memberikan tingkat keamanan dan isolasi dasar antara pod Anda dan kemudian gunakan mesh layanan untuk menambahkan kemampuan tambahan seperti manajemen lalu lintas, observabilitas, dan keamanan. ## ThirdParty Mesin Kebijakan Jaringan Pertimbangkan Mesin Kebijakan Jaringan Pihak Ketiga ketika Anda memiliki persyaratan kebijakan lanjutan seperti Kebijakan Jaringan Global, dukungan untuk aturan berbasis DNS Hostname, aturan Layer 7, aturan ServiceAccount berbasis, dan deny/log tindakan eksplisit, dll., [Calico](https://docs.projectcalico.org/introduction/), adalah mesin kebijakan open source dari [Tigera](https://tigera.io) yang bekerja dengan baik dengan EKS. Selain menerapkan set lengkap fitur kebijakan jaringan Kubernetes, Calico mendukung kebijakan jaringan yang diperluas dengan serangkaian fitur yang lebih kaya, termasuk dukungan untuk aturan lapisan 7, misalnya HTTP, ketika terintegrasi dengan Istio. Kebijakan Calico dapat dicakup ke Namespace, Pod, akun layanan, atau secara global. Ketika kebijakan dicakup ke akun layanan, kebijakan tersebut mengaitkan seperangkat ingress/egress aturan dengan akun layanan tersebut. Dengan aturan RBAC yang tepat, Anda dapat mencegah tim mengesampingkan aturan ini, memungkinkan profesional keamanan TI untuk mendelegasikan administrasi ruang nama dengan aman. Isovalent, pengelola [Cilium](https://cilium.readthedocs.io/en/stable/intro/), juga telah memperluas kebijakan jaringan untuk menyertakan dukungan sebagian untuk aturan lapisan 7, misalnya HTTP. Cilium juga memiliki dukungan untuk nama host DNS yang dapat berguna untuk membatasi lalu lintas antara Kubernetes Services/Pods dan sumber daya yang berjalan di dalam atau di luar VPC Anda. Sebaliknya, Calico Enterprise menyertakan fitur yang memungkinkan Anda memetakan kebijakan jaringan Kubernetes ke grup keamanan AWS, serta nama host DNS. Anda dapat menemukan daftar kebijakan jaringan Kubernetes yang umum di. https://github.com/ahmetb/ kubernetes-network-policy-recipes Seperangkat aturan serupa untuk Calico tersedia di https://docs.projectcalico. org/security/calico-kebijakan jaringan. ### Migrasi ke Mesin Kebijakan Jaringan Amazon VPC CNI Untuk menjaga konsistensi dan menghindari perilaku komunikasi pod yang tidak terduga, disarankan untuk menggunakan hanya satu Network Policy Engine di klaster Anda. Jika Anda ingin bermigrasi dari 3P ke VPC CNI Network Policy Engine, sebaiknya Anda mengonversi 3P NetworkPolicy CRDs yang ada menjadi resource Kubernetes sebelum mengaktifkan dukungan kebijakan jaringan VPC CNI. NetworkPolicy Dan, uji kebijakan yang dimigrasi dalam klaster pengujian terpisah sebelum menerapkannya di lingkungan produksi Anda. Ini memungkinkan Anda untuk mengidentifikasi dan mengatasi potensi masalah atau ketidakkonsistenan dalam perilaku komunikasi pod. #### Alat Migrasi Untuk membantu proses migrasi Anda, kami telah mengembangkan alat bernama [K8s Network Policy Migrator yang mengubah kebijakan jaringan](https://github.com/awslabs/k8s-network-policy-migrator) Anda yang ada menjadi kebijakan Calico/Cilium jaringan asli CRDs Kubernetes. Setelah konversi, Anda dapat langsung menguji kebijakan jaringan yang dikonversi pada cluster baru Anda yang menjalankan pengontrol kebijakan jaringan VPC CNI. Alat ini dirancang untuk membantu Anda merampingkan proses migrasi dan memastikan transisi yang lancar. **penting** Alat migrasi hanya akan mengonversi kebijakan 3P yang kompatibel dengan api kebijakan jaringan kubernetes asli. Jika Anda menggunakan fitur kebijakan jaringan lanjutan yang ditawarkan oleh plugin 3P, alat Migrasi akan melewati dan melaporkannya. Harap dicatat bahwa alat migrasi saat ini tidak didukung oleh tim rekayasa kebijakan AWS VPC CNI Network, alat ini tersedia untuk pelanggan dengan upaya terbaik. Kami mendorong Anda untuk menggunakan alat ini untuk memfasilitasi proses migrasi Anda. Jika Anda mengalami masalah atau bug dengan alat ini, kami mohon Anda membuat [GitHubmasalah](https://github.com/awslabs/k8s-network-policy-migrator/issues). Umpan balik Anda sangat berharga bagi kami dan akan membantu dalam peningkatan berkelanjutan dari layanan kami. ### Sumber Daya Tambahan + [Kubernetes & Tigera: Kebijakan Jaringan, Keamanan, dan Audit](https://youtu.be/lEY2WnRHYpg) + [Perusahaan Calico](https://www.tigera.io/tigera-products/calico-enterprise/) + [silia](https://cilium.readthedocs.io/en/stable/intro/) + [NetworkPolicyEditor editor](https://cilium.io/blog/2021/02/10/network-policy-editor) kebijakan interaktif dari Cilium + [Inspektor Gadget menyarankan gadget kebijakan](https://www.inspektor-gadget.io/docs/latest/gadgets/advise/network-policy/) jaringan Menyarankan kebijakan jaringan berdasarkan analisis lalu lintas jaringan ## Enkripsi saat bergerak Aplikasi yang perlu mematuhi PCI, HIPAA, atau peraturan lain mungkin perlu mengenkripsi data saat sedang dalam perjalanan. Saat ini TLS adalah pilihan de facto untuk mengenkripsi lalu lintas di kawat. TLS, seperti pendahulunya SSL, menyediakan komunikasi yang aman melalui jaringan menggunakan protokol kriptografi. TLS menggunakan enkripsi simetris di mana kunci untuk mengenkripsi data dihasilkan berdasarkan rahasia bersama yang dinegosiasikan pada awal sesi. Berikut ini adalah beberapa cara untuk mengenkripsi data di lingkungan Kubernetes. ### Contoh Nitro Lalu lintas yang dipertukarkan antara jenis instans Nitro berikut, misalnya C5n, G4, I3en, M5dn, M5n, P3dn, R5dn, dan R5n, secara otomatis dienkripsi secara default. Ketika ada hop perantara, seperti gateway transit atau penyeimbang beban, lalu lintas tidak dienkripsi. Lihat [Enkripsi dalam perjalanan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) untuk detail lebih lanjut tentang enkripsi dalam perjalanan serta daftar lengkap jenis instance yang mendukung enkripsi jaringan secara default. ### Antarmuka Jaringan Kontainer () CNIs [WeaveNet](https://www.weave.works/oss/net/)dapat dikonfigurasi untuk secara otomatis mengenkripsi semua lalu lintas menggunakan NaCl enkripsi untuk lalu lintas lengan, dan IPsec ESP untuk lalu lintas datapath cepat. ### Layanan Mesh Enkripsi dalam perjalanan juga dapat diimplementasikan dengan mesh layanan seperti App Mesh, Linkerd v2, dan Istio. AppMesh mendukung [mTL](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) dengan sertifikat X.509 atau Envoy's Secret Discovery Service (SDS). Linkerd dan Istio keduanya memiliki dukungan untuk mTL. [aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples)GitHub Repositori menyediakan panduan untuk mengonfigurasi mTL menggunakan sertifikat X.509 dan SPIRE sebagai penyedia SDS dengan wadah Utusan Anda: + [Mengkonfigurasi mTL menggunakan sertifikat X.509](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-mtls-file-based) + [Mengkonfigurasi TLS menggunakan SPIRE (SDS)](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-mtls-sds-based) App Mesh juga mendukung [enkripsi TLS](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual-node-tls.html) dengan sertifikat pribadi yang dikeluarkan oleh [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) (ACM) atau sertifikat yang disimpan di sistem file lokal node virtual. [aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples)GitHub Repositori menyediakan panduan untuk mengonfigurasi TLS menggunakan sertifikat yang dikeluarkan oleh ACM dan sertifikat yang dikemas dengan wadah Utusan Anda: + [Mengkonfigurasi TLS dengan Sertifikat TLS yang Disediakan File](https://github.com/aws/aws-app-mesh-examples/tree/master/walkthroughs/howto-tls-file-provided) + [Mengkonfigurasi TLS dengan AWS Certificate Manager](https://github.com/aws/aws-app-mesh-examples/tree/master/walkthroughs/tls-with-acm) ### Pengontrol Ingress dan Load Balancer Pengontrol Ingress adalah cara bagi Anda untuk secara cerdas merutekan HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS pemrosesan yang sangat intensif CPU. Akibatnya, jika Anda memiliki fleksibilitas, coba lakukan pembongkaran SSL di Ingress atau penyeimbang beban. #### Gunakan enkripsi dengan penyeimbang beban AWS Elastic [AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) (ALB) dan [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) (NLB) keduanya memiliki dukungan untuk enkripsi transport (SSL dan TLS). `alb.ingress.kubernetes.io/certificate-arn`Anotasi untuk ALB memungkinkan Anda menentukan sertifikat mana yang akan ditambahkan ke ALB. Jika Anda menghilangkan anotasi, pengontrol akan mencoba menambahkan sertifikat ke pendengar yang memerlukannya dengan mencocokkan [sertifikat AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) yang tersedia menggunakan bidang host. Dimulai dengan EKS v1.15 Anda dapat menggunakan `service.beta.kubernetes.io/aws-load-balancer-ssl-cert` anotasi dengan NLB seperti yang ditunjukkan pada contoh di bawah ini. ``` apiVersion: v1 kind: Service metadata: name: demo-app namespace: default labels: app: demo-app annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "" service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http" spec: type: LoadBalancer ports: - port: 443 targetPort: 80 protocol: TCP selector: app: demo-app //--- kind: Deployment apiVersion: apps/v1 metadata: name: nginx namespace: default labels: app: demo-app spec: replicas: 1 selector: matchLabels: app: demo-app template: metadata: labels: app: demo-app spec: containers: - name: nginx image: nginx ports: - containerPort: 443 protocol: TCP - containerPort: 80 protocol: TCP ``` Berikut ini adalah contoh tambahan untuk SSL/TLS penghentian. + [Mengamankan Ingress EKS Dengan Kontur Dan Mari Enkripsi Jalan GitOps ](https://aws.amazon.com/blogs/containers/securing-eks-ingress-contour-lets-encrypt-gitops/) + [Bagaimana cara menghentikan lalu lintas HTTPS di beban kerja Amazon EKS dengan ACM?](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-https-traffic-eks-acm/) **penting** Beberapa Ingress, seperti pengontrol AWS LB, mengimplementasikan SSL/TLS penggunaan Anotasi alih-alih sebagai bagian dari Spesifikasi Ingress. ### ACM Private CA dengan manajer sertifikat Anda dapat mengaktifkan TLS dan mTL untuk mengamankan beban kerja aplikasi EKS Anda di ingress, di pod, dan di antara pod menggunakan ACM Private Certificate Authority (CA) dan [cert-manager](https://cert-manager.io/), add-on Kubernetes populer untuk mendistribusikan, memperbarui, dan mencabut sertifikat. ACM Private CA adalah CA yang sangat tersedia, aman, terkelola tanpa biaya dimuka dan pemeliharaan untuk mengelola CA Anda sendiri. Jika Anda menggunakan otoritas sertifikat Kubernetes default, ada kesempatan untuk meningkatkan keamanan Anda dan memenuhi persyaratan kepatuhan dengan ACM Private CA. ACM Private CA mengamankan kunci pribadi dalam modul keamanan perangkat keras FIPS 140-2 Level 3 (sangat aman), dibandingkan dengan kunci penyimpanan CA default yang dikodekan dalam memori (kurang aman). CA terpusat juga memberi Anda lebih banyak kontrol dan peningkatan auditabilitas untuk sertifikat pribadi baik di dalam maupun di luar lingkungan Kubernetes. #### Mode CA Berumur Pendek untuk TLS Bersama Antar Beban Kerja Saat menggunakan ACM Private CA untuk mTL di EKS, disarankan agar Anda menggunakan sertifikat berumur pendek dengan mode CA *berumur pendek*. Meskipun dimungkinkan untuk mengeluarkan sertifikat berumur pendek dalam mode CA tujuan umum, menggunakan mode CA berumur pendek menghasilkan lebih hemat biaya (\$1 75% lebih murah daripada mode umum) untuk kasus penggunaan di mana sertifikat baru perlu sering dikeluarkan. Selain itu, Anda harus mencoba menyelaraskan masa berlaku sertifikat privat dengan masa pakai pod di klaster EKS Anda. [Pelajari lebih lanjut tentang ACM Private CA dan manfaatnya di sini](https://aws.amazon.com/certificate-manager/private-certificate-authority/). #### Petunjuk Pengaturan ACM Mulailah dengan membuat CA Pribadi dengan mengikuti prosedur yang disediakan dalam [dokumen teknologi ACM Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html). Setelah Anda memiliki CA Pribadi, instal cert-manager menggunakan instruksi [instalasi reguler](https://cert-manager.io/docs/installation/). [Setelah menginstal cert-manager, instal plugin Cert-Manager Private CA Kubernetes dengan mengikuti petunjuk penyiapan di. GitHub](https://github.com/cert-manager/aws-privateca-issuer#setup) Plugin ini memungkinkan manajer sertifikat meminta sertifikat pribadi dari ACM Private CA. Sekarang setelah Anda memiliki Private CA dan kluster EKS dengan cert-manager dan plugin yang diinstal, saatnya untuk mengatur izin dan membuat penerbit. Perbarui izin IAM dari peran node EKS untuk memungkinkan akses ke ACM Private CA. Ganti `` dengan nilai dari CA Pribadi Anda: ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "awspcaissuer", "Action": [ "acm-pca:DescribeCertificateAuthority", "acm-pca:GetCertificate", "acm-pca:IssueCertificate" ], "Effect": "Allow", "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012" } ] } ``` [Peran Layanan untuk Akun IAM, atau IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) juga dapat digunakan. Silakan lihat bagian Sumber Daya Tambahan di bawah ini untuk contoh lengkapnya. Buat Penerbit di Amazon EKS dengan membuat file Definisi Sumber Daya Kustom bernama cluster-issuer.yaml dengan teks berikut di dalamnya, ganti dan informasikan dengan CA Pribadi Anda. `` `` ``` apiVersion: awspca.cert-manager.io/v1beta1 kind: AWSPCAClusterIssuer metadata: name: demo-test-root-ca spec: arn: region: ``` Terapkan Penerbit yang Anda buat. ``` kubectl apply -f cluster-issuer.yaml ``` Kluster EKS Anda dikonfigurasi untuk meminta sertifikat dari Private CA. Sekarang Anda dapat menggunakan `Certificate` sumber daya cert-manager untuk menerbitkan sertifikat dengan mengubah nilai `issuerRef` bidang menjadi Penerbit CA Pribadi yang Anda buat di atas. Untuk detail selengkapnya tentang cara menentukan dan meminta sumber daya Sertifikat, silakan periksa panduan Sumber [Daya Sertifikat manajer sertifikat](https://cert-manager.io/docs/usage/certificate/). [Lihat contoh di sini](https://github.com/cert-manager/aws-privateca-issuer/tree/main/config/samples/). ### ACM Private CA dengan Istio dan manajer sertifikat Jika Anda menjalankan Istio di cluster EKS Anda, Anda dapat menonaktifkan bidang kontrol Istio (khususnya`istiod`) agar tidak berfungsi sebagai root Certificate Authority (CA), dan mengonfigurasi ACM Private CA sebagai root CA untuk mTL di antara beban kerja. Jika Anda menggunakan pendekatan ini, pertimbangkan untuk menggunakan *mode CA berumur pendek* di ACM Private CA. Lihat [bagian sebelumnya](#iam-ca-mode) dan [posting blog](https://aws.amazon.com/blogs/security/how-to-use-aws-private-certificate-authority-short-lived-certificate-mode) ini untuk lebih jelasnya. #### Cara Kerja Penandatanganan Sertifikat di Istio (Default) Beban kerja di Kubernetes diidentifikasi menggunakan akun layanan. Jika Anda tidak menentukan akun layanan, Kubernetes akan secara otomatis menetapkan satu ke beban kerja Anda. Selain itu, akun layanan secara otomatis memasang token terkait. Token ini digunakan oleh akun layanan untuk beban kerja untuk mengautentikasi terhadap Kubernetes API. Akun layanan mungkin cukup sebagai identitas untuk Kubernetes tetapi Istio memiliki sistem manajemen identitas dan CA sendiri. Ketika beban kerja dimulai dengan proxy sespan utusannya, ia membutuhkan identitas yang ditetapkan dari Istio agar dapat dianggap dapat dipercaya dan diizinkan untuk berkomunikasi dengan layanan lain di mesh. Untuk mendapatkan identitas ini dari Istio, `istio-agent` mengirimkan permintaan yang dikenal sebagai permintaan penandatanganan sertifikat (atau CSR) ke pesawat kontrol Istio. CSR ini berisi token akun layanan sehingga identitas beban kerja dapat diverifikasi sebelum diproses. Proses verifikasi ini ditangani oleh`istiod`, yang bertindak sebagai Otoritas Registrasi (atau RA) dan CA. RA berfungsi sebagai penjaga gerbang yang memastikan hanya CSR terverifikasi yang berhasil lolos ke CA. Setelah CSR diverifikasi, CSR akan diteruskan ke CA yang kemudian akan mengeluarkan sertifikat yang berisi identitas [SPIFFE](https://spiffe.io/) dengan akun layanan. Sertifikat ini disebut dokumen identitas yang dapat diverifikasi SPIFFE (atau SVID). SVID ditugaskan ke layanan yang meminta untuk tujuan identifikasi dan untuk mengenkripsi lalu lintas dalam perjalanan antara layanan yang berkomunikasi. Alur default untuk Permintaan Penandatanganan Sertifikat Istio: ![\[Alur default untuk Permintaan Penandatanganan Sertifikat Istio\]](http://docs.aws.amazon.com/id_id/eks/latest/best-practices/images/security/default-istio-csr-flow.png) #### Cara Kerja Penandatanganan Sertifikat di Istio dengan ACM Private CA Anda dapat menggunakan add-on cert-manager yang disebut agen Permintaan Penandatanganan Sertifikat Istio ([istio-csr) untuk mengintegrasikan Istio](https://cert-manager.io/docs/projects/istio-csr/) dengan ACM Private CA. Agen ini memungkinkan beban kerja Istio dan komponen bidang kontrol diamankan dengan emiten manajer sertifikat, dalam hal ini ACM Private CA. Agen *istio-csr* mengekspos layanan yang sama dengan yang disajikan *istiod* dalam konfigurasi default untuk memvalidasi masuk. CSRs Kecuali, setelah verifikasi, itu akan mengubah permintaan menjadi sumber daya yang didukung manajer sertifikat (yaitu integrasi dengan penerbit CA eksternal). Setiap kali ada CSR dari beban kerja, itu akan diteruskan ke *istio-csr, yang akan meminta sertifikat* dari ACM Private CA. Komunikasi antara *istio-csr* dan ACM Private CA ini diaktifkan oleh plugin penerbit [AWS Private](https://github.com/cert-manager/aws-privateca-issuer) CA. Manajer sertifikat menggunakan plugin ini untuk meminta sertifikat TLS dari ACM Private CA. Plugin penerbit akan berkomunikasi dengan layanan ACM Private CA untuk meminta sertifikat yang ditandatangani untuk beban kerja. Setelah sertifikat ditandatangani, sertifikat akan dikembalikan ke *istio-csr*, yang akan membaca permintaan yang ditandatangani, dan mengembalikannya ke beban kerja yang memulai CSR. **Alur untuk Permintaan Penandatanganan Sertifikat Istio dengan istio-csr** image:: istio-csr-with-acm -private-ca.png [Alur untuk Permintaan Penandatanganan Sertifikat Istio dengan istio-csr] #### Istio dengan Petunjuk Pengaturan CA Pribadi 1. Mulailah dengan mengikuti [petunjuk pengaturan yang sama di bagian ini](#iam-cert-manager) untuk menyelesaikan yang berikut: 1. Buat CA Pribadi 1. Instal cert-manager 1. Instal plugin penerbit 1. Tetapkan izin dan buat penerbit. Penerbit mewakili CA dan digunakan untuk menandatangani `istiod` dan menyaring sertifikat beban kerja. Ini akan berkomunikasi dengan ACM Private CA. 1. Buat `istio-system` namespace. Di sinilah sumber daya Istio `istiod certificate` dan lainnya akan digunakan. 1. Instal Istio CSR yang dikonfigurasi dengan AWS Private CA Issuer Plugin. Anda dapat mempertahankan permintaan penandatanganan sertifikat untuk beban kerja guna memverifikasi bahwa permintaan tersebut disetujui dan ditandatangani (`preserveCertificateRequests=true`). ``` helm install -n cert-manager cert-manager-istio-csr jetstack/cert-manager-istio-csr \ --set "app.certmanager.issuer.group=awspca.cert-manager.io" \ --set "app.certmanager.issuer.kind=AWSPCAClusterIssuer" \ --set "app.certmanager.issuer.name=" \ --set "app.certmanager.preserveCertificateRequests=true" \ --set "app.server.maxCertificateDuration=48h" \ --set "app.tls.certificateDuration=24h" \ --set "app.tls.istiodCertificateDuration=24h" \ --set "app.tls.rootCAFile=/var/run/secrets/istio-csr/ca.pem" \ --set "volumeMounts[0].name=root-ca" \ --set "volumeMounts[0].mountPath=/var/run/secrets/istio-csr" \ --set "volumes[0].name=root-ca" \ --set "volumes[0].secret.secretName=istio-root-ca" ``` 1. Instal Istio dengan konfigurasi khusus untuk diganti `istiod` dengan `cert-manager istio-csr` sebagai penyedia sertifikat untuk mesh. Proses ini dapat dilakukan dengan menggunakan [Operator Istio](https://tetrate.io/blog/what-is-istio-operator/). ``` apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: name: istio namespace: istio-system spec: profile: "demo" hub: gcr.io/istio-release values: global: # Change certificate provider to cert-manager istio agent for istio agent caAddress: cert-manager-istio-csr.cert-manager.svc:443 components: pilot: k8s: env: # Disable istiod CA Sever functionality - name: ENABLE_CA_SERVER value: "false" overlays: - apiVersion: apps/v1 kind: Deployment name: istiod patches: # Mount istiod serving and webhook certificate from Secret mount - path: spec.template.spec.containers.[name:discovery].args[7] value: "--tlsCertFile=/etc/cert-manager/tls/tls.crt" - path: spec.template.spec.containers.[name:discovery].args[8] value: "--tlsKeyFile=/etc/cert-manager/tls/tls.key" - path: spec.template.spec.containers.[name:discovery].args[9] value: "--caCertFile=/etc/cert-manager/ca/root-cert.pem" - path: spec.template.spec.containers.[name:discovery].volumeMounts[6] value: name: cert-manager mountPath: "/etc/cert-manager/tls" readOnly: true - path: spec.template.spec.containers.[name:discovery].volumeMounts[7] value: name: ca-root-cert mountPath: "/etc/cert-manager/ca" readOnly: true - path: spec.template.spec.volumes[6] value: name: cert-manager secret: secretName: istiod-tls - path: spec.template.spec.volumes[7] value: name: ca-root-cert configMap: defaultMode: 420 name: istio-ca-root-cert ``` 1. Terapkan sumber daya kustom di atas yang Anda buat. ``` istioctl operator init kubectl apply -f istio-custom-config.yaml ``` 1. Sekarang Anda dapat menerapkan beban kerja ke mesh di kluster EKS Anda dan [menerapkan mTL](https://istio.io/latest/docs/reference/config/security/peer_authentication/). **Permintaan penandatanganan sertifikat Istio** image:: istio-csr-requests .png [Permintaan penandatanganan sertifikat Istio] ## Alat dan sumber daya + [Lokakarya Perendaman Keamanan Amazon EKS - Keamanan jaringan](https://catalog.workshops.aws/eks-security-immersionday/en-US/6-network-security) + [Bagaimana menerapkan cert-manager dan plugin ACM Private CA untuk mengaktifkan TLS](https://aws.amazon.com/blogs/security/tls-enabled-kubernetes-clusters-with-acm-private-ca-and-amazon-eks-2/) di EKS. + [Menyiapkan enkripsi end-to-end TLS di Amazon EKS dengan AWS Load Balancer Controller baru dan ACM](https://aws.amazon.com/blogs/containers/setting-up-end-to-end-tls-encryption-on-amazon-eks-with-the-new-aws-load-balancer-controller/) Private CA. + Plugin pengelola [sertifikat CA Kubernetes pribadi](https://github.com/cert-manager/aws-privateca-issuer) aktif. GitHub + Panduan pengguna plugin pengelola [sertifikat CA Kubernetes pribadi](https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaKubernetes.html). + [Cara menggunakan mode sertifikat berumur pendek AWS Private Certificate Authority](https://aws.amazon.com/blogs/security/how-to-use-aws-private-certificate-authority-short-lived-certificate-mode) + [egress-operator Operator](https://github.com/monzo/egress-operator) dan plugin DNS untuk mengontrol lalu lintas keluar dari cluster Anda tanpa inspeksi protokol + [NeuVector oleh SUSE](https://www.suse.com/neuvector/) open source, platform keamanan wadah zero-trust, menyediakan aturan jaringan kebijakan, pencegahan kehilangan data (DLP), firewall aplikasi web (WAF) dan tanda tangan ancaman jaringan.