Halaman ini menjelaskan fitur, konfigurasi, dan setelan keamanan di Autopilot Google Kubernetes Engine (GKE), yang merupakan cara yang direkomendasikan untuk menjalankan GKE.
Siapa yang seharusnya menggunakan halaman ini?
Halaman ini ditujukan bagi administrator keamanan yang ingin memahami batasan keamanan yang diterapkan secara khusus oleh Google pada cluster Autopilot, dan fitur keamanan yang tersedia untuk digunakan dalam Autopilot.
Anda juga harus membaca ringkasan keamanan GKE, yang menjelaskan opsi, ukuran, dan rekomendasi hardening yang berlaku untuk semua cluster, konfigurasi jaringan, dan workload GKE.
Langkah keamanan di Autopilot
Cluster Autopilot mengaktifkan dan menerapkan praktik terbaik dan setelan keamanan secara default, termasuk banyak rekomendasi dalam ringkasan keamanan dan di Hardening keamanan cluster Anda.
Jika Anda menginginkan resource yang direkomendasikan berdasarkan kasus penggunaan Anda, lanjutkan ke Resource keamanan berdasarkan kasus penggunaan. Bagian berikut menjelaskan kebijakan keamanan yang diterapkan Autopilot untuk Anda.
Autopilot dan Standar Keamanan Pod Kubernetes
Project Kubernetes memiliki serangkaian panduan keamanan bernama Standar Keamanan Pod yang menentukan kebijakan berikut:
- Memiliki hak istimewa: Tidak ada pembatasan akses. Tidak digunakan di Autopilot.
- Dasar pengukuran: Mencegah jalur eskalasi akses yang diketahui. Memungkinkan sebagian besar workload dijalankan tanpa perubahan yang signifikan.
- Dibatasi: Tingkat keamanan tertinggi. Memerlukan perubahan signifikan pada sebagian besar workload.
Autopilot menerapkan kebijakan Dasar Pengukuran dengan beberapa modifikasi untuk kegunaan. Autopilot juga menerapkan banyak batasan dari kebijakan Terbatas, tetapi menghindari batasan yang akan memblokir sebagian besar workload Anda agar tidak berjalan. Autopilot menerapkan batasan ini di level cluster menggunakan pengontrol akses yang dikontrol Google. Jika Anda perlu menerapkan batasan tambahan untuk mematuhi kebijakan Terbatas penuh, Anda dapat menggunakan pengontrol akses PodSecurity di namespace tertentu.
Tabel berikut menjelaskan cara cluster Autopilot menerapkan kebijakan Dasar Pengukuran dan Terbatas. Untuk deskripsi setiap kontrol dalam tabel ini, lihat entri yang sesuai dalam Standar Keamanan Pod.
Saat mengevaluasi kepatuhan, kami mempertimbangkan bagaimana batasan diterapkan pada workload Anda. Tidak termasuk workload partner Google Cloud terverifikasi dan workload sistem yang memerlukan hak istimewa tertentu agar dapat berfungsi.
| Kontrol | Kepatuhan terhadap kebijakan Dasar Pengukuran | Kepatuhan terhadap kebijakan Terbatas | Informasi tambahan |
|---|---|---|---|
| HostProcess | Autopilot memblokir HostProcess. | ||
| Namespace host | Autopilot memblokir namespace host. Beberapa container dari partner terverifikasi diizinkan untuk menggunakan namespace host. | ||
| Container dengan hak istimewa | Autopilot memblokir container dengan hak istimewa secara default. Autopilot memungkinkan container dengan hak istimewa dari partner terverifikasi untuk tujuan seperti menjalankan alat keamanan dan pemantauan. | ||
| Kemampuan Linux | Workload autopilot hanya dapat mengakses kemampuan yang ditentukan dalam Standar Keamanan Pod Dasar Pengukuran secara default. Anda dapat mengaktifkan kemampuan berikut secara manual:
Autopilot juga memungkinkan beberapa workload partner terverifikasi untuk menetapkan kemampuan yang berkurang. |
||
| Volume HostPath | Mematuhi sebagian | Mematuhi sebagian | Autopilot memungkinkan container meminta akses hanya baca ke
/var/log untuk proses debug, tetapi menolak semua akses baca atau tulis
lainnya. |
| HostPorts | Menetapkan port host tertentu tidak diizinkan, sehingga mengurangi beberapa masalah penjadwalan, dan mencegah eksposur jaringan langsung ke layanan yang tidak disengaja atau disengaja. Anda dapat menyiapkan penetapan port host acak secara manual dari rentang yang diketahui untuk mendukung aplikasi jaringan koneksi langsung seperti server game. | ||
| AppArmor | Profil keamanan default Docker AppArmor otomatis diterapkan ke Container-Optimized OS. | ||
| SELinux | SELinux tidak diterapkan karena AppArmor sudah diterapkan. SELinux juga tidak wajib dalam Standar Keamanan Pod. | ||
Jenis pemasangan /proc |
GKE tidak menetapkan tombol fitur ProcMountType.
Jika securityContext Pod menetapkan procMount
ke "Unmasked", GKE akan otomatis menggantinya dengan
"Default". |
||
| seccomp profile | Autopilot menerapkan seccomp
profile RuntimeDefault ke semua workload. Anda dapat mengganti setelan ini secara manual untuk
workload tertentu dengan menyetel profil ke Unconfined dalam
spesifikasi Pod. |
||
| sysctls | GKE tidak menetapkan flag kubelet --allowed-unsafe-sysctls, sehingga pod dengan sysctls yang tidak aman gagal dijadwalkan. Untuk perlindungan tambahan, mulai 11 Juli 2023, cluster 1.27+ versi baru juga memiliki aturan kebijakan untuk menerapkan setelan securityContext dan menolak Pod yang menggunakan sysctl tidak aman. | ||
| Jenis volume | Autopilot hanya mengizinkan jenis volume dalam kebijakan Terbatas dengan tambahan berikut: Volume HostPath dengan akses hanya baca ke
/var/log untuk proses debug, gcePersistentDisk untuk persistent disk
Compute Engine, dan nf untuk volume sistem file jaringan. |
||
| Eskalasi akses | Setelan ini hanya memberikan perlindungan pada container yang tidak berjalan sebagai root. Survei industri menunjukkan bahwa 76% container berjalan sebagai root, sehingga Autopilot memungkinkan pengoperasiannya sebagai root untuk mengaktifkan sebagian besar workload. Saat ini, setelan ini juga berguna untuk membatalkan penetapan prioritas workload ke non-root dengan mengizinkan penggunaan kemampuan sistem file untuk mengatasi kekurangan dengan penanganan kemampuan root Kubernetes singkat ini. | ||
| Menjalankan sebagai non-root | Survei industri menunjukkan bahwa 76% container berjalan sebagai root, sehingga Autopilot memungkinkan pengoperasiannya sebagai root untuk mengaktifkan sebagian besar workload. | ||
| Menjalankan sebagai pengguna non-root | Container dapat menetapkan runAsUser ke 0.
Survei industri
menunjukkan bahwa 76% container dijalankan sebagai root, sehingga
Autopilot memungkinkan pengoperasiannya sebagai root untuk mengaktifkan sebagian besar workload |
Konfigurasi keamanan bawaan
Google menerapkan banyak setelan keamanan bawaan ke cluster Autopilot berdasarkan praktik terbaik industri dan keahlian kami. Tabel berikut menjelaskan beberapa konfigurasi keamanan yang diterapkan Autopilot untuk Anda:
| Konfigurasi | Deskripsi |
|---|---|
| Opsi host |
|
| Kemampuan Linux | Anda dapat menggunakan kemampuan Linux berikut: "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" Anda juga dapat mengaktifkan kemampuan berikut secara manual:
Pada GKE versi yang lebih lama dari 1.21, kemampuan |
| Container dengan hak istimewa | Container tidak dapat dijalankan dalam Mode istimewa kecuali jika container di-deploy oleh partner Google Cloud. Container dengan hak istimewa dapat melakukan perubahan pada node pokok, seperti mengubah kubelet. Akses ini dapat meningkatkan dampak penyusupan Pod. |
| Namespace yang dikelola GKE | Sebagai langkah keamanan, Autopilot tidak mengizinkan deployment
workload di namespace yang dikelola GKE, seperti
kube-system. |
| Isolasi container | Autopilot menerapkan pembatasan berikut pada container untuk membatasi dampak kerentanan container escape. Kemampuan Linux dan keamanan kernel
|
| Penerapan kebijakan keamanan tingkat pod | Autopilot mendukung mekanisme penerapan untuk kebijakan keamanan
level Pod seperti
pengontrol penerimaanPodSecurity,
Gatekeeper,
atau Pengontrol Kebijakan.
Namun, Anda mungkin tidak perlu menggunakan salah satunya jika konfigurasi keamanan bawaan yang dijelaskan di halaman ini sudah memenuhi persyaratan Anda. |
| SSH ke node | Autopilot memblokir akses SSH ke node. GKE menangani semua aspek operasional node, termasuk kondisi node dan semua komponen Kubernetes yang berjalan di node tersebut. Anda masih dapat terhubung dari jarak jauh ke container yang sedang berjalan menggunakan fungsi
|
| Peniruan identitas pengguna | GKE versi 1.22.4-gke.1501 dan yang lebih baru mendukung
peniruan identitas pengguna untuk semua pengguna dan grup yang ditentukan pengguna. Pengguna dan grup sistem seperti pengguna kube-apiserver dan grup system:masters tidak dapat ditiru. |
| Mengubah webhook penerimaan dinamis | Autopilot mengubah webhook yang bermutasi untuk mengecualikan resource dalam
namespace terkelola, seperti Autopilot juga menolak webhook yang menentukan satu atau beberapa resource berikut, serta sub-resource apa pun dari resource tersebut.
- group: "" resource: nodes - group: "" resource: persistentVolumes - group: certificates.k8s.io resource: certificatesigningrequests - group: authentication.k8s.io resource: tokenreviews Anda tidak dapat menggunakan karakter pengganti |
| Permintaan penandatanganan sertifikat | Anda dapat membuat CertificateSigningRequests di Autopilot untuk membuat sertifikat yang ditandatangani oleh certificate authority cluster. Untuk mencegah gangguan pada komponen sistem, Autopilot menolak CertificateSigningRequests untuk identitas dengan hak istimewa yang diketahui, seperti grup sistem, agen sistem, atau agen layanan IAM yang dikelola Google. |
| Fitur keamanan GKE | Cluster Autopilot mengaktifkan fitur keamanan GKE yang direkomendasikan untuk Anda. Untuk daftar fitur keamanan yang diaktifkan dan opsional, lihat fitur keamanan di Autopilot. |
| Sistem operasi node | Cluster Autopilot menggunakan Container-Optimized OS dengan
containerd sebagai sistem operasi node. Container-Optimized OS dibuat dan dikelola oleh Google. |
| Upgrade versi GKE | Cluster autopilot didaftarkan di saluran rilis GKE setelah pembuatan, dan upgrade otomatis selalu diaktifkan. Google secara otomatis mengupgrade bidang kontrol dan node Anda ke versi terbaru yang memenuhi syarat di saluran rilis dari waktu ke waktu. |
Batasan keamanan di Autopilot
Autopilot memberikan akses ke Kubernetes API, tetapi menghapus izin untuk menggunakan beberapa fitur Kubernetes dengan hak istimewa tinggi, seperti Pod dengan hak istimewa. Tujuannya adalah membatasi kemampuan untuk mengakses, memodifikasi, atau mengontrol secara langsung virtual machine (VM) node. Autopilot menerapkan batasan ini untuk membatasi workload agar tidak memiliki akses level rendah ke VM node, sehingga Google Cloud dapat menawarkan pengelolaan node secara penuh, dan level Pod SLA singkat ini.
Tujuan kami adalah mencegah akses yang tidak diinginkan ke VM node. Kami menerima pengiriman yang memengaruhi hal tersebut melalui Google Vulnerability Reward Program (VRP) dan akan memberikan reward atas laporan sesuai pertimbangan panel reward Google VRP.
Secara desain, pengguna dengan hak istimewa seperti administrator cluster memiliki kontrol penuh atas cluster GKE. Sebagai praktik terbaik keamanan, sebaiknya hindari memberikan hak istimewa GKE atau Kubernetes yang andal secara luas dan sebagai gantinya gunakan delegasi admin namespace jika memungkinkan, seperti yang dijelaskan dalam panduan multi-tenancy kami.
Autopilot menyediakan VM tenant tunggal dalam project Anda untuk penggunaan eksklusif Anda. Pada setiap VM, workload Autopilot Anda mungkin dijalankan bersama, berbagi kernel yang di-hardening dengan keamanan. Karena kernel bersama mewakili satu batas keamanan, sebaiknya jika Anda memerlukan isolasi yang kuat, seperti workload berisiko tinggi atau tidak tepercaya, jalankan workload Anda di Pod GKE Sandbox untuk memberikan perlindungan keamanan berlapis.
Resource keamanan berdasarkan kasus penggunaan
Bagian berikut memberi Anda link dan rekomendasi untuk merencanakan, menerapkan, dan mengelola keamanan cluster Autopilot, bergantung pada kasus penggunaan.
Merencanakan keamanan cluster
| Kasus penggunaan | Referensi |
|---|---|
| Memahami cara GKE sebagai platform mendekati keamanan |
|
| Memahami peran Anda dalam hardening lingkungan | Pelajari model tanggung jawab bersama. |
| Lihat rekomendasi Google untuk tindakan hardening dan respons insiden |
|
| Memahami cara GKE mengimplementasikan logging audit |
|
Mengautentikasi dan memberi otorisasi
Setelah menyiapkan cluster Autopilot, Anda mungkin perlu mengautentikasi pengguna dan aplikasi untuk menggunakan resource seperti Kubernetes API atau Google Cloud API.
| Kasus penggunaan | Referensi |
|---|---|
| Mengautentikasi pengguna atau aplikasi ke server cluster API |
|
| Mengautentikasi aplikasi ke Google Cloud API dan layanan Google Cloud | Dengan cluster autopilot, Anda dapat menggunakan Workload Identity Federation for GKE, untuk mengautentikasi workload secara aman ke Google Cloud API dengan mengonfigurasi akun layanan Kubernetes agar bertindak sebagai akun layanan IAM. Untuk mengetahui petunjuknya, lihat Mengonfigurasi aplikasi untuk menggunakan Workload Identity Federation for GKE. |
| Memberi otorisasi tindakan di level project | Untuk memberikan otorisasi pada tindakan lintas cluster pada level project, gunakan IAM. Anda dapat memberikan atau menolak akses ke resource GKE dan Kubernetes API tertentu menggunakan peran dan izin IAM. Untuk mengetahui petunjuknya, lihat Membuat kebijakan IAM. |
| Mengizinkan tindakan di level cluster | Untuk mengizinkan tindakan pada resource Kubernetes API di cluster tertentu, gunakan mekanisme role-based access control (RBAC) Kubernetes bawaan. Untuk mendapatkan petunjuk, lihat Memberi otorisasi tindakan dalam cluster menggunakan RBAC. |
| Memberi otorisasi tindakan di tingkat organisasi | Anda dapat menggunakan Google Cloud Organization Policy Service untuk menerapkan batasan pada operasi tertentu pada resource GKE di seluruh organisasi Google Cloud Anda. Untuk mendapatkan petunjuknya, lihat Membatasi tindakan pada resource GKE menggunakan kebijakan organisasi kustom. |
Hardening cluster dan workload
Jika Anda memiliki persyaratan khusus isolasi atau hardening di luar tindakan Autopilot yang telah dikonfigurasi sebelumnya, pertimbangkan referensi berikut:
| Kasus penggunaan | Referensi |
|---|---|
| Membatasi akses publik ke endpoint cluster Anda | Buat cluster Autopilot sebagai cluster pribadi, yang menonaktifkan alamat IP publik bidang kontrol cluster. Untuk mendapatkan petunjuk, lihat Cluster pribadi. |
| Membatasi akses cluster ke jaringan tertentu | Gunakan jaringan yang diizinkan bidang kontrol untuk menentukan rentang alamat IP yang dapat mengakses cluster. |
| Menyimpan informasi sensitif di luar cluster | Menyimpan data sensitif di penyedia penyimpanan eksternal terenkripsi dengan mengaktifkan pembuatan versi merupakan persyaratan kepatuhan umum dan praktik terbaik. Gunakan Secret Manager untuk menyimpan data dan mengaksesnya dari cluster Autopilot menggunakan Workload Identity Federation for GKE. Untuk petunjuknya, lihat Mengakses secret yang disimpan di luar cluster GKE menggunakan Workload Identity Federation for GKE. |
| Memverifikasi image container sebelum deployment ke cluster | Gunakan Otorisasi Biner untuk memeriksa integritas image container yang dirujuk dalam manifes Pod pada waktu deployment. Untuk mendapatkan petunjuk, lihat Memverifikasi image container saat deployment menggunakan Otorisasi Biner. |
Memantau postur keamanan Anda
Setelah menyiapkan cluster dan men-deploy workload, Anda harus menyiapkan dan mengonfigurasi pemantauan dan logging sehingga memiliki kemampuan observasi atas postur keamanan cluster. Sebaiknya lakukan semua tindakan berikut:
- Daftarkan cluster Anda di dasbor postur keamanan GKE untuk mengaudit workload berdasarkan masalah, seperti konfigurasi keamanan yang bermasalah atau kerentanan dalam paket sistem operasi container Anda, dan dapatkan informasi mitigasi yang dapat ditindaklanjuti.
- Dapatkan notifikasi tentang buletin keamanan baru dan peristiwa upgrade menggunakan notifikasi cluster.
- Amati cluster Anda menggunakan dasbor GKE di Cloud Monitoring atau tab Kemampuan observasi di GKE.
- Pelajari cara melihat dan mengelola log audit GKE Anda di Cloud Logging.
Langkah selanjutnya
- Baca ringkasan keamanan GKE.
- Baca panduan hardening GKE.
- Berlangganan buletin keamanan dan catatan rilis.