Gunakan Kebijakan Jaringan dengan Mode Otomatis EKS - Amazon EKS
IkhtisarMulai menggunakanBagaimana cara kerjanya?Pertimbangan-pertimbangan

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 secara manual dan mengizinkan daftar alamat IP tertentu. 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 klaster)

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.

Mulai menggunakan

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"

  2. 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 denganBintang demo kebijakan jaringan untuk Amazon EKS.

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

  2. Menerapkan konfigurasi Node Class ke cluster Anda:

    kubectl apply -f nodeclass-network-policy.yaml

  3. Verifikasi bahwa Kelas Node telah dibuat:

    kubectl get nodeclass network-policy-config

  4. Perbarui Node Pool Anda untuk menggunakan Kelas Node ini. Untuk informasi selengkapnya, lihat Buat Node Pool untuk Mode Otomatis EKS.

Bagaimana cara kerjanya?

Kebijakan jaringan berbasis DNS

Ilustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto
llustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto

  1. Tim platform menerapkan kebijakan berbasis DNS ke cluster EKS.

  2. 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.

  3. 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.

  4. Setelah permintaan DNS melewati daftar izinkan filter DNS, itu diproksi ke CoreDNS,

  5. CoreDNS pada gilirannya mengirimkan permintaan ke Resolver DNS Eksternal (Amazon Route 53 Resolver) untuk mendapatkan daftar alamat IP di belakang nama domain.

  6. 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.

  7. 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

ApplicationNetworkPolicyIni 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.

  2. Mendefinisikan aturan yang beroperasi pada lapisan 7 dari tumpukan jaringan dan memungkinkan Anda memfilter lalu lintas berdasarkan FQDNs.

Catatan penting: Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja ApplicationNetworkPolicy yang berjalan di instans yang diluncurkan Mode EC2 Otomatis EKS.

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

Kebijakan jaringan admin (atau cluster)

llustrasi urutan evaluasi untuk kebijakan jaringan di EKS

Menggunakan Kebijakan Jaringan Cluster

Saat menggunakanClusterNetworkPolicy, 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 atauNetworkPolicy. 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.

  2. 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.

  3. 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).

  4. 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. Kapan pun 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 yang diluncurkan Mode EC2 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 (instance EC2 terkelola).

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 pod 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.