Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Grup Keamanan Per Pod

Grup AWS keamanan bertindak sebagai firewall virtual untuk EC2 instance untuk mengontrol lalu lintas masuk dan keluar. Secara default, Amazon VPC CNI akan menggunakan grup keamanan yang terkait dengan primer ENI pada node. Lebih khusus lagi, setiap ENI yang terkait dengan instance akan memiliki Grup EC2 Keamanan yang sama. Dengan demikian, setiap Pod pada sebuah node berbagi grup keamanan yang sama dengan node yang dijalankannya.

Seperti yang terlihat pada gambar di bawah ini, semua Pod aplikasi yang beroperasi pada node pekerja akan memiliki akses ke layanan RDS database (mengingat RDS inbound memungkinkan grup keamanan node). Kelompok keamanan terlalu kasar karena mereka berlaku untuk semua Pod yang berjalan pada sebuah node. Grup keamanan untuk Pod menyediakan segmentasi jaringan untuk beban kerja yang merupakan bagian penting dari strategi pertahanan mendalam yang baik.

Dengan grup keamanan untuk Pod, Anda dapat meningkatkan efisiensi komputasi dengan menjalankan aplikasi dengan berbagai persyaratan keamanan jaringan pada sumber daya komputasi bersama. Beberapa jenis aturan keamanan, seperti Pod-to-Pod dan Pod-to-External AWS layanan, dapat didefinisikan di satu tempat dengan grup EC2 keamanan dan diterapkan pada beban kerja dengan Kubernetes native. APIs Gambar di bawah ini menunjukkan grup keamanan yang diterapkan pada level Pod dan bagaimana mereka menyederhanakan penerapan aplikasi dan arsitektur node Anda. Pod sekarang dapat mengakses RDS database Amazon.

Anda dapat mengaktifkan grup keamanan untuk Pod dengan ENABLE_POD_ENI=true menyetelnya VPCCNI. Setelah diaktifkan, VPCResource Controller yang berjalan di bidang kontrol (dikelola olehEKS) membuat dan melampirkan antarmuka trunk yang disebut “`aws-k8 s-trunk-eni “`ke node. Antarmuka trunk bertindak sebagai antarmuka jaringan standar yang melekat pada instance. Untuk mengelola antarmuka trunk, Anda harus menambahkan kebijakan AmazonEKSVPCResourceController terkelola ke peran klaster yang menyertai EKS klaster Amazon Anda.

Pengontrol juga membuat antarmuka cabang bernama “aws-k8s-branch-eni" dan mengaitkannya dengan antarmuka trunk. Pod diberi grup keamanan menggunakan sumber daya SecurityGroupPolicykustom dan dikaitkan dengan antarmuka cabang. Karena grup keamanan ditentukan dengan antarmuka jaringan, kita sekarang dapat menjadwalkan Pod yang membutuhkan grup keamanan tertentu pada antarmuka jaringan tambahan ini. Tinjau Bagian Panduan EKS Pengguna pada Grup Keamanan untuk Pod, termasuk prasyarat penerapan.

Kapasitas antarmuka cabang adalah tambahan untuk batas tipe instans yang ada untuk alamat IP sekunder. Pod yang menggunakan grup keamanan tidak diperhitungkan dalam rumus max-pod dan ketika Anda menggunakan grup keamanan untuk pod, Anda perlu mempertimbangkan untuk meningkatkan nilai max-pod atau baik-baik saja dengan menjalankan pod lebih sedikit daripada yang sebenarnya dapat didukung oleh node.

Sebuah m5.large dapat memiliki hingga 9 antarmuka jaringan cabang dan hingga 27 alamat IP sekunder yang ditetapkan ke antarmuka jaringan standarnya. Seperti yang ditunjukkan pada contoh di bawah ini, max-pod default untuk m5.large adalah 29, dan EKS menghitung Pod yang menggunakan grup keamanan terhadap Pod maksimum. Silakan lihat panduan EKS pengguna untuk petunjuk tentang cara mengubah max-pod untuk node.

Ketika grup keamanan untuk Pod digunakan dalam kombinasi dengan jaringan kustom, grup keamanan yang ditentukan dalam grup keamanan untuk Pod digunakan, bukan grup keamanan yang ditentukan dalamENIConfig. Akibatnya, ketika jaringan kustom diaktifkan, hati-hati menilai urutan grup keamanan saat menggunakan grup keamanan per Pod.

Rekomendasi

Nonaktifkan Demux TCP Awal untuk Liveness Probe

Jika Anda menggunakan probe keaktifan atau kesiapan, Anda juga perlu menonaktifkan demux TCP awal, sehingga kubelet dapat terhubung ke Pod pada antarmuka jaringan cabang melalui. TCP Ini hanya diperlukan dalam mode ketat. Untuk melakukan ini jalankan perintah berikut:

kubectl edit daemonset aws-node -n kube-system

Di bawah initContainer bagian ini, ubah nilainya DISABLE_TCP_EARLY_DEMUX menjadi true.

Gunakan Security Group For Pod untuk memanfaatkan investasi AWS konfigurasi yang ada.

Grup keamanan memudahkan untuk membatasi akses jaringan ke VPC sumber daya, seperti RDS database atau EC2 instance. Salah satu keuntungan yang jelas dari grup keamanan per Pod adalah kesempatan untuk menggunakan kembali sumber daya grup AWS keamanan yang ada. Jika Anda menggunakan grup keamanan sebagai firewall jaringan untuk membatasi akses ke AWS layanan Anda, kami mengusulkan untuk menerapkan grup keamanan ke Pod menggunakan cabangENIs. Pertimbangkan untuk menggunakan grup keamanan untuk Pod jika Anda mentransfer aplikasi dari EC2 instans ke EKS dan membatasi akses ke AWS layanan lain dengan grup keamanan.

Konfigurasikan Mode Penegakan Grup Keamanan Pod

VPCCNIPlugin Amazon versi 1.11 menambahkan pengaturan baru bernama POD_SECURITY_GROUP_ENFORCING_MODE (“mode penegakan”). Mode penegakan mengontrol grup keamanan mana yang diterapkan ke pod, dan jika sumber NAT diaktifkan. Anda dapat menentukan mode penegakan sebagai ketat atau standar. Strict adalah default, yang mencerminkan perilaku sebelumnya dari VPC CNI with ENABLE_POD_ENI set totrue.

Dalam Mode Ketat, hanya kelompok ENI keamanan cabang yang diberlakukan. Sumbernya NAT juga dinonaktifkan.

Dalam Mode Standar, grup keamanan yang terkait dengan primer ENI dan cabang ENI (terkait dengan pod) diterapkan. Lalu lintas jaringan harus mematuhi kedua kelompok keamanan.

Mode Penegakan: Gunakan mode Ketat untuk mengisolasi lalu lintas pod dan node:

Secara default, grup keamanan untuk Pod diatur ke “mode ketat.” Gunakan pengaturan ini jika Anda harus benar-benar memisahkan lalu lintas Pod dari sisa lalu lintas node. Dalam mode ketat, sumber NAT dimatikan sehingga grup keamanan ENI keluar cabang dapat digunakan.

Mode Penegakan: Gunakan mode Standar dalam situasi berikut

IP sumber klien terlihat oleh kontainer di Pod

Jika Anda perlu menjaga IP sumber klien tetap terlihat oleh kontainer di dalam Pod, pertimbangkan POD_SECURITY_GROUP_ENFORCING_MODE untuk menyetelnyastandard. Dukungan layanan Kubernetes externalTrafficPolicy =local untuk mendukung pelestarian IP sumber klien (cluster tipe default). Anda sekarang dapat menjalankan layanan Kubernetes dari tipe NodePort dan LoadBalancer menggunakan target instance dengan externalTrafficPolicy set ke Local dalam mode standar. Localmempertahankan IP sumber klien dan menghindari lompatan kedua untuk LoadBalancer dan NodePort mengetik Layanan.

Menyebarkan NodeLocal DNSCache

Saat menggunakan grup keamanan untuk Pod, konfigurasikan mode standar untuk mendukung Pod yang digunakan NodeLocal DNSCache. NodeLocal DNSCachemeningkatkan DNS kinerja Cluster dengan menjalankan agen DNS caching pada node cluster sebagai DaemonSet file. Ini akan membantu pod yang memiliki DNS QPS persyaratan tertinggi untuk menanyakan Kube-DNS/Core lokal yang DNS memiliki cache lokal, yang akan meningkatkan latensi.

NodeLocal DNSCachetidak didukung dalam mode ketat karena semua lalu lintas jaringan, bahkan ke node, memasuki fileVPC.

Mendukung Kebijakan Jaringan Kubernetes

Sebaiknya gunakan mode penegakan standar saat menggunakan kebijakan jaringan dengan Pod yang memiliki grup keamanan terkait.

Kami sangat menyarankan untuk menggunakan grup keamanan untuk Pod untuk membatasi akses tingkat jaringan ke AWS layanan yang bukan merupakan bagian dari klaster. Pertimbangkan kebijakan jaringan untuk membatasi lalu lintas jaringan antara Pod di dalam klaster, sering dikenal sebagai lalu lintas Timur/Barat.

Identifikasi Ketidakcocokan dengan Grup Keamanan per Pod

Instance berbasis Windows dan non-nitro tidak mendukung grup keamanan untuk Pod. Untuk memanfaatkan grup keamanan dengan Pod, instance harus diberi tag. isTrunkingEnabled Gunakan kebijakan jaringan untuk mengelola akses antar Pod daripada grup keamanan jika Pod Anda tidak bergantung pada AWS layanan apa pun di dalam atau di luar Pod AndaVPC.

Gunakan Grup Keamanan per Pod untuk mengontrol lalu lintas ke AWS Layanan secara efisien

Jika aplikasi yang berjalan di dalam EKS klaster harus berkomunikasi dengan sumber daya lain di dalamVPC, misalnya RDS database, maka pertimbangkan SGs untuk menggunakan Pod. Meskipun ada mesin kebijakan yang memungkinkan Anda menentukan nama CIDR atau DNS nama, mereka adalah pilihan yang kurang optimal saat berkomunikasi dengan AWS layanan yang memiliki titik akhir yang berada di dalam. VPC

Sebaliknya, kebijakan jaringan Kubernetes menyediakan mekanisme untuk mengendalikan lalu lintas masuk dan keluar baik di dalam maupun di luar klaster. Kebijakan jaringan Kubernetes harus dipertimbangkan jika aplikasi Anda memiliki ketergantungan terbatas pada layanan lain. AWS Anda dapat mengonfigurasi kebijakan jaringan yang menentukan aturan jalan keluar berdasarkan CIDR rentang untuk membatasi akses ke AWS layanan sebagai lawan AWS dari semantik asli seperti. SGs Anda dapat menggunakan kebijakan jaringan Kubernetes untuk mengontrol lalu lintas jaringan antar Pod (sering disebut sebagai lalu lintas Timur/Barat) dan antara Pod dan layanan eksternal. Kebijakan jaringan Kubernetes diterapkan pada OSI level 3 dan 4.

Amazon EKS memungkinkan Anda untuk menggunakan mesin kebijakan jaringan seperti Calico dan Cilium. Secara default, mesin kebijakan jaringan tidak diinstal. Silakan periksa panduan pemasangan masing-masing untuk petunjuk tentang cara mengatur. Untuk informasi selengkapnya tentang cara menggunakan kebijakan jaringan, lihat Praktik terbaik EKS keamanan. Fitur DNS nama host tersedia dalam versi enterprise dari network policy engine, yang dapat berguna untuk mengontrol lalu lintas antara Layanan/Pod Kubernetes dan sumber daya yang berjalan di luar. AWS Selain itu, Anda dapat mempertimbangkan dukungan DNS nama host untuk AWS layanan yang tidak mendukung grup keamanan secara default.

Tandai satu Grup Keamanan untuk menggunakan AWS Loadbalancer Controller

Ketika banyak grup keamanan dialokasikan ke sebuah Pod, Amazon EKS merekomendasikan untuk menandai satu grup keamanan dengan kubernetes.io/cluster/$nameberbagi atau dimiliki. Tag ini memungkinkan AWS Loadbalancer Controller untuk memperbarui aturan grup keamanan untuk merutekan lalu lintas ke Pod. Jika hanya satu grup keamanan yang diberikan ke sebuah Pod, penetapan tag bersifat opsional. Izin yang ditetapkan dalam grup keamanan bersifat aditif, oleh karena itu menandai satu grup keamanan cukup bagi pengontrol loadbalancer untuk menemukan dan merekonsiliasi aturan. Ini juga membantu untuk mematuhi kuota default yang ditentukan oleh grup keamanan.

Konfigurasi NAT untuk Lalu Lintas Keluar

Sumber NAT dinonaktifkan untuk lalu lintas keluar dari Pod yang ditetapkan grup keamanan. Untuk Pod yang menggunakan grup keamanan yang memerlukan akses node pekerja peluncuran internet pada subnet pribadi yang dikonfigurasi dengan NAT gateway atau instance dan mengaktifkan eksternal SNAT di CNI file.

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

Menerapkan Pod dengan Grup Keamanan ke Subnet Pribadi

Pod yang diberi grup keamanan harus dijalankan pada node yang di-deploy ke subnet pribadi. Perhatikan bahwa Pod dengan grup keamanan yang ditetapkan yang disebarkan ke subnet publik tidak akan dapat mengakses internet.

Verifikasi terminationGracePeriodDetik dalam File Spesifikasi Pod

Pastikan itu terminationGracePeriodSeconds bukan nol dalam file spesifikasi Pod Anda (default 30 detik). Hal ini penting VPC CNI agar Amazon dapat menghapus jaringan Pod dari node pekerja. Ketika disetel ke nol, CNI plugin tidak menghapus jaringan Pod dari host, dan cabang ENI tidak dibersihkan secara efektif.

Menggunakan Grup Keamanan untuk Pod dengan Fargate

Grup keamanan untuk Pod yang berjalan di Fargate bekerja sangat mirip dengan Pod yang berjalan pada node EC2 pekerja. Misalnya, Anda harus membuat grup keamanan sebelum mereferensikannya dalam asosiasi SecurityGroupPolicy Anda dengan Pod Fargate Anda. Secara default, grup keamanan klaster ditetapkan ke semua Pod Fargate ketika Anda tidak secara eksplisit menetapkan a ke Pod Fargate. SecurityGroupPolicy Demi kesederhanaan, Anda mungkin ingin menambahkan grup keamanan klaster ke Pod Fagate SecurityGroupPolicy jika tidak, Anda harus menambahkan aturan grup keamanan minimum ke grup keamanan Anda. Anda dapat menemukan grup keamanan cluster menggunakan klaster deskripsikan. API

 aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'

cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-fargate-sg-policy
  namespace: my-fargate-namespace
spec:
  podSelector:
    matchLabels:
      role: my-fargate-role
  securityGroups:
    groupIds:
      - cluster_security_group_id
      - my_fargate_pod_security_group_id
EOF

Aturan grup keamanan minimum tercantum di sini. Aturan ini memungkinkan Pod Fargate untuk berkomunikasi dengan layanan in-cluster seperti kube-apiserver, kubelet, dan Core. DNS Anda juga perlu menambahkan aturan untuk mengizinkan koneksi masuk dan keluar ke dan dari Fargate Pod Anda. Ini akan memungkinkan Pod Anda untuk berkomunikasi dengan Pod atau sumber daya lain di dalam AndaVPC. Selain itu, Anda harus menyertakan aturan untuk Fargate untuk menarik gambar kontainer dari Amazon ECR atau pendaftar kontainer lainnya seperti. DockerHub Untuk informasi selengkapnya, lihat rentang alamat AWS IP di Referensi AWS Umum.

Anda dapat menggunakan perintah di bawah ini untuk menemukan grup keamanan yang diterapkan pada Pod Fargate.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Catat perintah eniId dari atas.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

Pod Fargate yang ada harus dihapus dan dibuat ulang agar grup keamanan baru dapat diterapkan. Misalnya, perintah berikut memulai penerapan example-app. Untuk memperbarui pod tertentu, Anda dapat mengubah namespace dan nama deployment pada perintah di bawah ini.

kubectl rollout restart -n example-ns deployment example-pod

📝 Edit halaman ini di GitHub