Halaman ini menjelaskan pendekatan yang dilakukan Google Kubernetes Engine (GKE) untuk meningkatkan kepatuhan terhadap tolok ukur Center for Internet Security (CIS) untuk Kubernetes dan untuk 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 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 penerapan Kubernetes yang dihosting dan dikelola sendiri.
Tolok Ukur GKE CIS: Menetapkan panduan untuk konfigurasi aman
komponen yang dapat Anda kontrol di cluster GKE. Mencakup rekomendasi khusus untuk GKE di Google Cloud.
Sebaiknya Anda membuat prioritas Tolok Ukur GKE CIS, karena tolok ukur ini
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 tolok ukur Kubernetes open source dan dapat menyebabkan konflik dengan rekomendasi tersebut.
Tolok ukur lain yang berlaku untuk GKE
Selain CIS GKE Benchmark dan CIS Kubernetes Benchmark, 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 mendapatkan panduan keamanan tambahan.
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 di project yang dimiliki GKE, sehingga Anda tidak dapat
mengubah atau mengevaluasi salah satu 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 menjadi
tanggung jawab Anda.
Pendekatan kami untuk mengamankan GKE untuk Tolok Ukur CIS
GKE adalah implementasi terkelola dari 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 pemberian skor 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 image registry 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 mekanisme 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.
Oleh karena itu, kita tidak perlu menetapkan flag logging audit server Kubernetes API.
Proses Debug
GKE menggunakan pembuatan profil untuk proses debug.
GKE menggunakan mTLS untuk traffic antara komponen bidang kontrol dan antara bidang kontrol dan node. Untuk mengetahui detailnya, lihat
Kepercayaan cluster.
etcd
Di 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 melayani etcd API di VM bidang kontrol. Semua interaksi klien dengan Kubernetes API sama seperti di Kubernetes open source. Bergantung pada teknologi database yang menjadi backend
untuk etcd API di cluster Anda, Anda mungkin melihat perbedaan dalam
skor terkait etcd dalam Tolok Ukur Kubernetes CIS open source.
kubelet
GKE mengaktifkan port hanya baca kubelet yang tidak diautentikasi. Anda dapat menonaktifkan port dengan
menyetel --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
default kernel jika diperlukan.
GKE membatasi jumlah peristiwa Kubernetes di
kubelet untuk mengurangi risiko serangan penolakan layanan.
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.
Anda dapat mengotomatiskan evaluasi cluster terhadap Tolok Ukur menggunakan salah satu metode berikut:
Tolok Ukur GKE CIS:
Semua edisi GKE:
Jalankan kube-bench untuk mengevaluasi node pekerja berdasarkan Benchmark. Untuk
detailnya, lihat repositori GitHub kube-bench.
Gunakan alat pihak ketiga seperti Twistlock Defender untuk mengevaluasi node terhadap
Benchmark.
Edisi GKE Enterprise: gunakan dasbor Kepatuhan untuk
mengevaluasi semua cluster Anda terkait kepatuhan terhadap Tolok Ukur GKE CIS. Untuk
mengetahui detailnya, lihat Tentang Dasbor Kepatuhan GKE.
CIS Kubernetes Benchmark: Jalankan kube-bench untuk mengevaluasi node pekerja berdasarkan Tolok Ukur. Anda tidak dapat mengevaluasi bidang kontrol terkelola terhadap rekomendasi tersebut dalam Tolok Ukur.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 UTC."],[],[],null,["# CIS Benchmarks\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the approach that Google Kubernetes Engine (GKE) takes to\nimprove compliance with the Center for Internet Security (CIS) benchmarks for\nKubernetes and for GKE. This page includes the following\ninformation:\n\n- How we configure the managed GKE control plane to conform to the CIS Kubernetes Benchmark\n- How you can configure your GKE nodes and workloads to conform to the CIS Google Kubernetes Engine (GKE) Benchmark\n\nAbout the CIS Benchmarks\n------------------------\n\nCIS releases the following benchmarks that contain secure configuration\nguidelines for Kubernetes:\n\n- **CIS Kubernetes Benchmark**: Applies to the open source Kubernetes project. Intended to provide guidance for a variety of self-managed and hosted Kubernetes implementations.\n- **CIS GKE Benchmark**: Establishes guidelines for the secure configuration of components you can control in GKE clusters. Includes recommendations that are specific to GKE on Google Cloud.\n\nWe recommend that you **prioritize the CIS GKE Benchmark**, because it is\nspecific to GKE on Google Cloud. The CIS Kubernetes\nBenchmark contains many recommendations for controls that you can't view or\nmodify in GKE. Our approach to cluster security includes\nmitigations that go beyond the scope of the open source Kubernetes benchmark and\nmight result in conflicts with those recommendations.\n\n### Other benchmarks that apply to GKE\n\nIn addition to the CIS GKE Benchmark and the CIS Kubernetes Benchmark, the following benchmarks apply to the operating systems that are available in GKE. Even if a specific OS benchmark doesn't explicitly address Kubernetes usage, you should still reference that benchmark for additional security guidance.\n\n- [**Container-Optimized OS Benchmark**](https://www.cisecurity.org/benchmark/google_cloud_computing_platform): the default operating system that's installed on all GKE Linux nodes\n- [**Ubuntu Linux Benchmark**](https://www.cisecurity.org/benchmark/ubuntu_linux): available for GKE Standard\n- [**Windows Server Benchmark**](https://www.cisecurity.org/benchmark/microsoft_windows_server): available for GKE Standard\n\nThe default container runtime, containerd, doesn't have a benchmark.\n\n### Shared responsibility model\n\nBased on the\n[GKE shared responsibility model](/kubernetes-engine/docs/concepts/shared-responsibility),\nwe manage the following components for you:\n\n- The control plane, including the control plane VMs, API server, and components like the cluster state database (etcd or Spanner-based), kube-controller-manager, and kube-scheduler.\n- The node operating system.\n\nThese components exist in a project that GKE owns, so you can't\nmodify or evaluate any of these components against corresponding CIS Benchmark\ncontrols. You can, however, evaluate and remediate any CIS Benchmark controls\nthat apply to your worker nodes and your workloads. Based on the\nGKE shared responsibility model, these components are your\nresponsibility.\n\nOur approach to securing GKE for the CIS Benchmark\n--------------------------------------------------\n\nGKE is a managed implementation of open source Kubernetes. We\nfully manage the control plane and are responsible for securing the\nconfiguration of control plane components. The following table describes some of\nour decisions that might affect scoring of the CIS benchmarks:\n\nEvaluate GKE against the CIS Benchmarks\n---------------------------------------\n\n| **Note:** This section mentions third-party applications like `kube-bench`. The versions of the CIS Benchmarks that these applications evaluate might not be the latest available versions. Ensure that you check which version your chosen application uses for evaluations.\n\nYou can automate evaluation of your clusters against the Benchmarks by using one\nof the following methods:\n\n- CIS GKE Benchmark:\n - Run `kube-bench` to evaluate worker nodes against the Benchmark. For details, see the [kube-bench GitHub repository](https://github.com/aquasecurity/kube-bench).\n - Use a third-party tool like Twistlock Defender to evaluate nodes against the Benchmark.\n- CIS Kubernetes Benchmark: Run `kube-bench` to evaluate worker nodes against the Benchmark. You can't evaluate the managed control plane against those recommendations in the Benchmark.\n\nWhat's next\n-----------\n\n- Read the [GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- Follow security best practices in the [GKE hardening guide](/kubernetes-engine/docs/how-to/hardening-your-cluster).\n- Learn about monitoring your clusters for security issues with [GKE security posture](/kubernetes-engine/docs/concepts/about-security-posture-dashboard).\n- Learn how to evaluate your clusters for compliance issues in the [GKE compliance dashboard](/kubernetes-engine/fleet-management/docs/about-compliance-dashboard) for GKE Enterprise."]]
