Tolok Ukur CIS

Halaman ini menjelaskan pendekatan yang dilakukan Google Kubernetes Engine (GKE) untuk meningkatkan kepatuhan terhadap tolok ukur Center for Internet Security (CIS) untuk Kubernetes dan GKE. Halaman ini menyertakan informasi berikut:

  • Cara kami mengonfigurasi bidang kontrol GKE terkelola agar sesuai dengan Tolok Ukur Kubernetes CIS
  • Cara mengonfigurasi node dan beban kerja GKE agar sesuai dengan CIS Google Kubernetes Engine (GKE) Benchmark

Tentang Tolok Ukur CIS

CIS merilis benchmark berikut yang berisi panduan konfigurasi yang aman untuk Kubernetes:

  • CIS Kubernetes Benchmark: Berlaku untuk project Kubernetes open source. Dimaksudkan untuk memberikan panduan bagi berbagai implementasi Kubernetes yang dikelola sendiri dan dihosting.
  • CIS GKE Benchmark: Menetapkan panduan untuk konfigurasi komponen yang aman yang dapat Anda kontrol di cluster GKE. Menyertakan rekomendasi yang khusus untuk GKE di Google Cloud.

Sebaiknya prioritaskan CIS GKE Benchmark, karena khusus untuk GKE di Google Cloud. Tolok Ukur Kubernetes CIS berisi banyak rekomendasi untuk kontrol yang tidak dapat Anda lihat atau ubah di GKE. Pendekatan kami terhadap keamanan cluster mencakup mitigasi yang melampaui cakupan benchmark Kubernetes open source dan mungkin menyebabkan konflik dengan rekomendasi tersebut.

Benchmark lain yang berlaku untuk GKE

Selain Tolok Ukur GKE CIS dan Tolok Ukur Kubernetes CIS, tolok ukur berikut berlaku untuk sistem operasi yang tersedia di GKE. Meskipun benchmark OS tertentu tidak secara eksplisit membahas penggunaan Kubernetes, Anda tetap harus mereferensikan benchmark tersebut untuk mendapatkan panduan keamanan tambahan.

Runtime container default, containerd, tidak memiliki benchmark.

Model tanggung jawab bersama

Berdasarkan model tanggung jawab bersama GKE, kami mengelola komponen berikut untuk Anda:

  • Bidang kontrol, termasuk VM bidang kontrol, server API, dan komponen seperti etcd, kube-controller-manager, dan kube-scheduler.
  • Sistem operasi node.

Komponen ini ada dalam project yang dimiliki GKE, sehingga Anda tidak dapat mengubah atau mengevaluasi komponen mana pun terhadap kontrol CIS Benchmark yang sesuai. Namun, Anda dapat mengevaluasi dan memperbaiki kontrol CIS Benchmark yang berlaku untuk node pekerja dan workload Anda. Berdasarkan model tanggung jawab bersama GKE, komponen ini adalah tanggung jawab Anda.

Pendekatan kami untuk mengamankan GKE untuk CIS Benchmark

GKE adalah implementasi terkelola Kubernetes open source. Kami mengelola sepenuhnya bidang kontrol dan bertanggung jawab untuk mengamankan konfigurasi komponen bidang kontrol. Tabel berikut menjelaskan beberapa keputusan kami yang dapat memengaruhi penskoran benchmark CIS:

Pendekatan keamanan GKE
Autentikasi
  • Beberapa komponen pemantauan GKE menggunakan autentikasi anonim untuk mendapatkan metrik.
  • Beberapa komponen bidang kontrol di-bootstrap menggunakan token statis, yang kemudian digunakan untuk melakukan autentikasi ke server API. Token ini dibuat setiap kali VM dimulai atau dimulai ulang.
Pengontrol akses

GKE menonaktifkan pengontrol akses berikut:

  • EventRateLimit: Ini adalah fitur alfa di Kubernetes
  • AlwaysPullImages: Pengontrol ini memberikan beberapa perlindungan untuk image registry pribadi di cluster multitenant non-kooperatif, dengan mengorbankan registry image sebagai titik tunggal kegagalan untuk membuat Pod baru di cluster.
  • SecurityContextDeny: Pengontrol Penerimaan Keamanan Pod lebih disukai dan tersedia di semua edisi GKE. Jika menggunakan GKE Enterprise, Anda juga dapat mengaktifkan penerapan Standar Keamanan Pod menggunakan Policy Controller.
  • ImagePolicyWebhook: GKE menonaktifkan ImagePolicyWebhook secara default karena memiliki mekanismenya sendiri untuk pengelolaan dan keamanan image. Hal ini memungkinkan GKE mempertahankan kontrol yang lebih ketat atas lingkungan dan memastikan bahwa praktik keamanannya diterapkan secara konsisten. Namun, Anda dapat menggunakan Otorisasi Biner atau Pengontrol Kebijakan untuk pengelolaan kebijakan.
Logging audit GKE merekam log audit menggunakan kebijakan audit GKE. Akibatnya, kita tidak perlu menetapkan flag logging audit server Kubernetes API.
Proses Debug GKE menggunakan pembuatan profil untuk proses debug.
Enkripsi
kubelet
  • GKE mengaktifkan port hanya baca kubelet yang tidak diautentikasi. Anda dapat menonaktifkan port dengan menetapkan --no-autoprovisioning-enable-insecure-kubelet-readonly-port. Port hanya baca akan dinonaktifkan secara default dalam rilis mendatang setelah memberi Anda waktu untuk melakukan migrasi.
  • Mode GKE Standard memungkinkan workload Anda mengubah setelan default kernel jika diperlukan.
  • GKE membatasi jumlah peristiwa Kubernetes di kubelet untuk mengurangi risiko serangan denial-of-service.
  • GKE menggunakan mTLS untuk mengamankan traffic antara kubelet dan server API.
  • GKE merotasi sertifikat server secara default, dan merotasi sertifikat klien saat Node GKE yang Terlindungi diaktifkan.
  • GKE menggunakan set cipher yang diizinkan default golang, yang juga merupakan default untuk Kubernetes.

Mengevaluasi GKE terhadap Tolok Ukur CIS

Anda dapat mengotomatiskan evaluasi cluster terhadap Benchmark menggunakan salah satu metode berikut:

  • Tolok Ukur GKE CIS:

    • Semua edisi GKE:
      • Jalankan kube-bench untuk mengevaluasi node pekerja terhadap Benchmark. Untuk mengetahui detailnya, lihat repositori GitHub kube-bench.
      • Gunakan alat pihak ketiga seperti Twistlock Defender untuk mengevaluasi node berdasarkan Benchmark.
    • Edisi GKE Enterprise: gunakan dasbor Kepatuhan untuk mengevaluasi kepatuhan semua cluster Anda terhadap Tolok Ukur GKE CIS. Untuk mengetahui detailnya, lihat Tentang Dasbor Kepatuhan GKE.

  • CIS Kubernetes Benchmark: Jalankan kube-bench untuk mengevaluasi node pekerja terhadap Tolok Ukur. Anda tidak dapat mengevaluasi panel kontrol terkelola berdasarkan rekomendasi tersebut dalam Benchmark.

Langkah berikutnya