View a markdown version of this page

Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes - Amazon EKS
Gambaran umumKebijakan jaringan standarKebijakan jaringan admin (atau cluster)Catatan pentingPertimbangan-pertimbangan

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

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

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

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

  4. 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 dipanggilpolicyendpoints.networking.k8s.aws. PolicyEndpointobjek 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 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:

    • IPv6pod dengan ENABLE_V4_EGRESS variabel disetel ketrue. 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.