Grup Keamanan Per Pod

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

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

Grup keamanan AWS bertindak sebagai firewall virtual untuk EC2 instans untuk mengontrol lalu lintas masuk dan keluar. Secara default, Amazon VPC CNI akan menggunakan grup keamanan yang terkait dengan ENI utama 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 database RDS (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. Berbagai jenis aturan keamanan, seperti Pod-to-Pod dan layanan Pod-to-External AWS, 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 database Amazon RDS.

Anda dapat mengaktifkan grup keamanan untuk Pod dengan menyetel ENABLE_POD_ENI=true untuk VPC CNI. Setelah diaktifkan, VPC Resource Controller yang berjalan di bidang kontrol (dikelola oleh EKS) membuat dan melampirkan antarmuka trunk yang disebut “`aws-k8 “`s-trunk-enike 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 klaster Amazon EKS 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 Pengguna EKS tentang 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 pengguna EKS 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 dalam ENIConfig. Akibatnya, ketika jaringan kustom diaktifkan, hati-hati menilai urutan grup keamanan saat menggunakan grup keamanan per Pod.

Rekomendasi

Nonaktifkan TCP Early Demux untuk Liveness Probe

Jika Anda menggunakan liveness atau readiness probe, Anda juga perlu menonaktifkan TCP early demux, 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 Grup Keamanan Untuk Pod untuk memanfaatkan investasi konfigurasi AWS yang ada.

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

Konfigurasikan Mode Penegakan Grup Keamanan Pod

Plugin Amazon VPC CNI 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, mencerminkan perilaku sebelumnya dari VPC CNI ENABLE_POD_ENI dengan disetel ke. true

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

Dalam Mode Standar, grup keamanan yang terkait dengan ENI primer dan ENI cabang (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 keluar ENI 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 DNSCache meningkatkan kinerja DNS Cluster dengan menjalankan agen caching DNS pada node cluster sebagai file. DaemonSet Ini akan membantu pod yang memiliki persyaratan QPS DNS tertinggi untuk menanyakan Kube-DNS/CoreDNS lokal yang memiliki cache lokal, yang akan meningkatkan latensi.

NodeLocal DNSCache tidak didukung dalam mode ketat karena semua lalu lintas jaringan, bahkan ke node, memasuki VPC.

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

Instans 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 dan bukan grup keamanan jika Pod Anda tidak bergantung pada layanan AWS apa pun di dalam atau di luar VPC Anda.

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

Jika aplikasi yang berjalan di dalam kluster EKS harus berkomunikasi dengan sumber daya lain di dalam VPC, misalnya database RDS, maka pertimbangkan untuk menggunakan SGs Pod. Meskipun ada mesin kebijakan yang memungkinkan Anda menentukan CIDR atau nama DNS, mereka adalah pilihan yang kurang optimal saat berkomunikasi dengan layanan AWS yang memiliki titik akhir yang berada 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 AWS lainnya. Anda dapat mengonfigurasi kebijakan jaringan yang menentukan aturan keluar berdasarkan rentang CIDR untuk membatasi akses ke layanan AWS sebagai lawan dari semantik asli AWS. 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 diimplementasikan pada level OSI 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 Security. Fitur nama host DNS tersedia di engine kebijakan jaringan versi perusahaan, 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 nama host DNS untuk layanan AWS yang tidak mendukung grup keamanan secara default.

Tandai satu Grup Keamanan untuk menggunakan AWS Loadbalancer Controller

Ketika banyak grup keamanan dialokasikan ke Pod, Amazon EKS merekomendasikan untuk menandai satu grup keamanan dengan kubernetes.io/cluster/$namedibagikan 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.

Konfigurasikan 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 gateway atau instance NAT dan mengaktifkan SNAT eksternal di CNI.

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 agar Amazon VPC CNI dapat menghapus jaringan Pod dari node pekerja. Ketika disetel ke nol, plugin CNI 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 klaster menggunakan API klaster deskripsikan.

 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 CoreDNS. 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 VPC Anda. 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 IP AWS di AWS General Reference.

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 eNIID dari perintah di 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 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