Melindungi infrastruktur (host) - Amazon EKS
RekomendasiAlternatifAlat dan sumber daya

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

Melindungi infrastruktur (host)

Karena penting untuk mengamankan gambar kontainer Anda, sama pentingnya untuk menjaga infrastruktur yang menjalankannya. Bagian ini mengeksplorasi berbagai cara untuk mengurangi risiko dari serangan yang diluncurkan langsung terhadap tuan rumah. Pedoman ini harus digunakan bersama dengan yang diuraikan di bagian Keamanan Runtime.

Rekomendasi

Gunakan OS yang dioptimalkan untuk menjalankan kontainer

Pertimbangkan untuk menggunakan Flatcar Linux, Project Atomic, RancherOS, dan Bottlerocket, OS tujuan khusus dari AWS yang dirancang untuk menjalankan wadah Linux. Ini termasuk permukaan serangan yang dikurangi, gambar disk yang diverifikasi saat boot, dan batasan izin yang diberlakukan menggunakan SELinux.

Sebagai alternatif, gunakan AMI yang dioptimalkan EKS untuk node pekerja Kubernetes Anda. AMI yang dioptimalkan EKS dirilis secara teratur dan berisi kumpulan minimal paket OS dan binari yang diperlukan untuk menjalankan beban kerja kontainer Anda.

Silakan lihat Amazon EKS AMI RHEL Build Specification untuk contoh skrip konfigurasi yang dapat digunakan untuk membangun Amazon EKS AMI khusus yang berjalan di Red Hat Enterprise Linux menggunakan Hashicorp Packer. Skrip ini dapat dimanfaatkan lebih lanjut untuk membangun kustom EKS yang sesuai dengan STIG. AMIs

Tetap perbarui OS node pekerja Anda

Terlepas dari apakah Anda menggunakan OS host yang dioptimalkan kontainer seperti Bottlerocket atau yang lebih besar, tetapi masih minimalis, Gambar Mesin Amazon seperti EKS yang dioptimalkan AMIs, praktik terbaik untuk menjaga gambar OS host ini tetap up to date dengan patch keamanan terbaru.

Untuk EKS yang dioptimalkan AMIs, periksa saluran CHANGELOG dan/atau catatan rilis secara teratur dan otomatiskan peluncuran gambar node pekerja yang diperbarui ke dalam klaster Anda.

Perlakukan infrastruktur Anda sebagai tidak dapat diubah dan otomatiskan penggantian node pekerja Anda

Daripada melakukan peningkatan di tempat, ganti pekerja Anda saat patch atau pembaruan baru tersedia. Ini bisa didekati dengan beberapa cara. Anda dapat menambahkan instance ke grup penskalaan otomatis yang ada menggunakan AMI terbaru saat Anda secara berurutan mengikat dan menguras node hingga semua node dalam grup diganti dengan AMI terbaru. Atau, Anda dapat menambahkan instance ke grup node baru saat Anda secara berurutan mengikat dan menguras node dari grup node lama sampai semua node telah diganti. Grup node terkelola EKS menggunakan pendekatan pertama dan akan menampilkan pesan di konsol untuk meningkatkan pekerja Anda saat AMI baru tersedia. eksctljuga memiliki mekanisme untuk membuat grup node dengan AMI terbaru dan untuk mengepung dan menguras pod dengan anggun dari grup node sebelum instance dihentikan. Jika Anda memutuskan untuk menggunakan metode yang berbeda untuk mengganti node pekerja Anda, sangat disarankan agar Anda mengotomatiskan proses untuk meminimalkan pengawasan manusia karena Anda mungkin perlu mengganti pekerja secara teratur saat baru updates/patches dirilis dan ketika bidang kontrol ditingkatkan.

Dengan EKS Fargate, AWS akan secara otomatis memperbarui infrastruktur yang mendasarinya saat pembaruan tersedia. Seringkali hal ini dapat dilakukan dengan mulus, tetapi mungkin ada kalanya pembaruan akan menyebabkan pod Anda dijadwalkan ulang. Oleh karena itu, kami menyarankan Anda membuat deployment dengan beberapa replika saat menjalankan aplikasi Anda sebagai pod Fargate.

Jalankan kube-bench secara berkala untuk memverifikasi kepatuhan terhadap benchmark CIS untuk Kubernetes

kube-bench adalah proyek open source dari Aqua yang mengevaluasi cluster Anda terhadap benchmark CIS untuk Kubernetes. Tolok ukur ini menjelaskan praktik terbaik untuk mengamankan klaster Kubernetes yang tidak dikelola. Benchmark CIS Kubernetes mencakup bidang kontrol dan bidang data. Karena Amazon EKS menyediakan pesawat kontrol yang dikelola sepenuhnya, tidak semua rekomendasi dari Tolok Ukur CIS Kubernetes dapat diterapkan. Untuk memastikan cakupan ini mencerminkan bagaimana Amazon EKS diimplementasikan, AWS membuat Benchmark CIS Amazon EKS. Benchmark EKS mewarisi dari CIS Kubernetes Benchmark dengan masukan tambahan dari komunitas dengan pertimbangan konfigurasi khusus untuk kluster EKS.

Saat menjalankan kube-bench terhadap cluster EKS, ikuti instruksi ini dari Aqua Security. Untuk informasi lebih lanjut lihat Memperkenalkan Benchmark CIS Amazon EKS.

Minimalkan akses ke node pekerja

Alih-alih mengaktifkan akses SSH, gunakan SSM Session Manager saat Anda perlu remote ke host. Tidak seperti kunci SSH yang dapat hilang, disalin, atau dibagikan, Session Manager memungkinkan Anda untuk mengontrol akses ke EC2 instance menggunakan IAM. Selain itu, ia menyediakan jejak audit dan log perintah yang dijalankan pada instance.

Per 19 Agustus 2020 Grup Node Terkelola mendukung kustom AMIs dan Template EC2 Peluncuran. Ini memungkinkan Anda untuk menyematkan agen SSM ke AMI atau menginstalnya saat node pekerja sedang di-bootstrap. Jika Anda lebih suka tidak memodifikasi AMI yang Dioptimalkan atau template peluncuran ASG, Anda dapat menginstal agen SSM dengan DaemonSet seperti dalam contoh ini.

Kebijakan IAM minimal untuk Akses SSH berbasis SSM

Kebijakan AmazonSSMManagedInstanceCore AWS managed berisi sejumlah izin yang tidak diperlukan untuk SSM Session Manager/SSM RunCommand jika Anda hanya ingin menghindari akses SSH. Yang menjadi perhatian khusus adalah * izin ssm:GetParameter(s) yang memungkinkan peran mengakses semua parameter di Parameter Store (termasuk SecureStrings dengan kunci KMS terkelola AWS yang dikonfigurasi).

Kebijakan IAM berikut berisi kumpulan izin minimal untuk mengaktifkan akses node melalui SSM Systems Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Dengan kebijakan ini dan plugin Session Manager diinstal, Anda kemudian dapat menjalankannya

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

untuk mengakses node.

catatan

Anda mungkin juga ingin mempertimbangkan untuk menambahkan izin untuk mengaktifkan pencatatan Manajer Sesi.

Menyebarkan pekerja ke subnet pribadi

Dengan mengerahkan pekerja ke subnet pribadi, Anda meminimalkan eksposur mereka ke Internet di mana serangan sering berasal. Mulai 22 April 2020, penugasan alamat IP publik ke node dalam grup node yang dikelola akan dikendalikan oleh subnet tempat mereka digunakan. Sebelum ini, node dalam Grup Node Terkelola secara otomatis diberi IP publik. Jika Anda memilih untuk menerapkan node pekerja ke subnet publik, terapkan aturan grup keamanan AWS yang membatasi untuk membatasi eksposur mereka.

Jalankan Amazon Inspector untuk menilai host untuk eksposur, kerentanan, dan penyimpangan dari praktik terbaik

Anda dapat menggunakan Amazon Inspector untuk memeriksa akses jaringan yang tidak diinginkan ke node dan kerentanan pada instans Amazon yang mendasarinya. EC2

Amazon Inspector dapat menyediakan data kerentanan dan eksposur umum (CVE) untuk EC2 instans Amazon Anda hanya jika agen Amazon Systems EC2 Manager (SSM) diinstal dan diaktifkan. Agen ini sudah diinstal sebelumnya di beberapa Amazon Machine Images (AMIs) termasuk Amazon Linux AMIs yang dioptimalkan EKS. Terlepas dari status agen SSM, semua EC2 instans Amazon Anda dipindai untuk masalah jangkauan jaringan. Untuk informasi selengkapnya tentang mengonfigurasi pemindaian untuk Amazon EC2, lihat Memindai instans Amazon EC2 .

penting

Inspector tidak dapat dijalankan pada infrastruktur yang digunakan untuk menjalankan pod Fargate.

Alternatif

Jalankan SELinux

catatan

Tersedia di Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket, dan Amazon Linux 2023

SELinux menyediakan lapisan keamanan tambahan untuk menjaga kontainer terisolasi satu sama lain dan dari host. SELinux memungkinkan administrator untuk menegakkan kontrol akses wajib (MAC) untuk setiap pengguna, aplikasi, proses, dan file. Anggap saja sebagai backstop yang membatasi operasi yang dapat dilakukan terhadap sumber daya tertentu berdasarkan serangkaian label. Pada EKS, SELinux dapat digunakan untuk mencegah kontainer mengakses sumber daya masing-masing.

SELinux Kebijakan kontainer didefinisikan dalam paket container-selinux. Docker CE memerlukan paket ini (bersama dengan dependensinya) sehingga proses dan file yang dibuat oleh Docker (atau runtime kontainer lainnya) berjalan dengan akses sistem yang terbatas. Container memanfaatkan container_t label yang merupakan alias untuksvirt_lxc_net_t. Kebijakan ini secara efektif mencegah kontainer mengakses fitur tertentu dari host.

Saat Anda mengonfigurasi SELinux untuk Docker, Docker secara otomatis memberi label beban kerja container_t sebagai tipe dan memberi setiap kontainer tingkat MCS yang unik. Ini akan mengisolasi wadah satu sama lain. Jika Anda memerlukan pembatasan yang lebih longgar, Anda dapat membuat profil Anda sendiri SElinux yang memberikan izin kontainer ke area tertentu dari sistem file. Ini mirip dengan PSPs di mana Anda dapat membuat profil yang berbeda untuk wadah/pod yang berbeda. Misalnya, Anda dapat memiliki profil untuk beban kerja umum dengan serangkaian kontrol terbatas dan lainnya untuk hal-hal yang memerlukan akses istimewa.

SELinux untuk Kontainer memiliki serangkaian opsi yang dapat dikonfigurasi untuk memodifikasi batasan default. SELinux Booleans berikut dapat diaktifkan atau dinonaktifkan berdasarkan kebutuhan Anda:

Boolean Default Deskripsi

container_connect_any

off

Izinkan kontainer mengakses port istimewa di host. Misalnya, jika Anda memiliki wadah yang perlu memetakan port ke 443 atau 80 pada host.

container_manage_cgroup

off

Izinkan kontainer untuk mengelola konfigurasi cgroup. Misalnya, wadah yang menjalankan systemd akan membutuhkan ini untuk diaktifkan.

container_use_cephfs

off

Izinkan kontainer menggunakan sistem file ceph.

Secara default, kontainer diizinkan untuk read/execute di bawah /usr dan membaca sebagian besar konten dari/etc. File di bawah /var/lib/docker dan /var/lib/containers memiliki labelcontainer_var_lib_t. Untuk melihat daftar lengkap default, label melihat file container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

File berlabel container_file_t adalah satu-satunya file yang dapat ditulis oleh kontainer. Jika Anda ingin volume mount dapat ditulis, Anda harus menentukan :z atau :Z di akhir.

  • :zakan memberi label ulang file sehingga wadah dapat membaca/menulis

  • :Zakan memberi label ulang file sehingga hanya wadah yang dapat membaca/menulis

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

Di Kubernetes, pelabelan ulang sedikit berbeda. Daripada meminta Docker memberi label ulang file secara otomatis, Anda dapat menentukan label MCS khusus untuk menjalankan pod. Volume yang mendukung pelabelan ulang secara otomatis akan diberi label ulang sehingga dapat diakses. Pod dengan label MCS yang cocok akan dapat mengakses volume. Jika Anda membutuhkan isolasi yang ketat, tetapkan label MCS yang berbeda untuk setiap pod.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

Dalam contoh ini s0:c144:c154 sesuai dengan label MCS yang ditetapkan ke file yang wadah diizinkan untuk diakses.

Di EKS Anda dapat membuat kebijakan yang memungkinkan wadah istimewa berjalan, seperti fluentD dan membuat SELinux kebijakan untuk mengizinkannya membaca dari/var/log di host tanpa perlu memberi label ulang pada direktori host. Pod dengan label yang sama akan dapat mengakses volume host yang sama.

Kami telah menerapkan sampel AMIs untuk Amazon EKS yang telah SELinux dikonfigurasi pada CentOS 7 dan RHEL 7. Ini AMIs dikembangkan untuk menunjukkan implementasi sampel yang memenuhi persyaratan pelanggan yang sangat diatur.

Awas

SELinux akan mengabaikan wadah di mana tipenya tidak terbatas.

Alat dan sumber daya