Tolok Ukur CIS

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

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

Tentang Tolok Ukur CIS

CIS merilis tolok ukur berikut yang berisi panduan konfigurasi aman untuk Kubernetes:

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

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

Tolok ukur 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 tolok ukur OS tertentu tidak secara eksplisit membahas penggunaan Kubernetes, Anda tetap harus merujuk tolok ukur tersebut untuk panduan keamanan tambahan.

Runtime container default, containerd, tidak memiliki tolok ukur.

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 database status cluster (berbasis etcd atau Spanner), 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 ini terhadap kontrol Tolok Ukur CIS yang sesuai. Namun, Anda dapat mengevaluasi dan memperbaiki kontrol CIS Benchmark yang berlaku untuk worker node dan workload Anda. Berdasarkan model tanggung jawab bersama GKE, komponen ini adalah tanggung jawab Anda.

Pendekatan kami dalam mengamankan GKE untuk Tolok Ukur CIS

GKE adalah implementasi terkelola dari Kubernetes open source. Kami sepenuhnya mengelola bidang kontrol dan bertanggung jawab untuk mengamankan konfigurasi komponen bidang kontrol. Tabel berikut menjelaskan beberapa keputusan kami yang mungkin memengaruhi penskoran tolok ukur 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 penerimaan

GKE menonaktifkan pengontrol penerimaan berikut:

  • EventRateLimit: Ini adalah fitur alfa di Kubernetes
  • AlwaysPullImages: Pengontrol ini memberikan beberapa perlindungan untuk image registry pribadi di cluster multitenant non-kooperatif, namun juga menjadikan registry image titik tunggal kegagalan untuk membuat Pod baru di cluster.
  • SecurityContextDeny: Pengontrol Penerimaan Keamanan Pod lebih disarankan dan tersedia di semua edisi GKE. Anda juga dapat mengaktifkan penerapan Standar Keamanan Pod menggunakan Pengontrol Kebijakan.
  • 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 menangkap log audit menggunakan kebijakan audit GKE. Oleh karena itu, kita tidak perlu menetapkan flag logging audit server Kubernetes API apa pun.
Proses Debug GKE menggunakan pembuatan profil untuk proses debug.
Enkripsi
etcd

Dalam Kubernetes open source, database status cluster menggunakan etcd. Di GKE, database backend yang menyimpan status cluster adalah salah satu teknologi berikut:

  • etcd: cluster menjalankan instance etcd di bidang kontrol.
  • Spanner: GKE menyimpan status cluster dalam database berbasis Spanner yang terpisah dari VM bidang kontrol.

Semua cluster GKE menyajikan etcd API di VM bidang kontrol. Setiap interaksi klien dengan Kubernetes API sama seperti di Kubernetes open source. Bergantung pada teknologi database yang menjadi backend untuk API etcd di cluster Anda, Anda mungkin melihat perbedaan dalam skor terkait etcd di Tolok Ukur Kubernetes CIS open source.
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 bermigrasi.
  • Mode GKE Standard memungkinkan workload Anda mengubah 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 Shielded GKE Node 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:
    • Jalankan kube-bench untuk mengevaluasi worker node berdasarkan Benchmark. Untuk mengetahui detailnya, lihat repositori GitHub kube-bench.
    • Gunakan alat pihak ketiga seperti Twistlock Defender untuk mengevaluasi node terhadap Tolok Ukur.
  • Tolok Ukur Kubernetes CIS: Jalankan kube-bench untuk mengevaluasi worker node terhadap Tolok Ukur. Anda tidak dapat mengevaluasi bidang kontrol terkelola berdasarkan rekomendasi tersebut di Benchmark.

Langkah berikutnya