Melakukan hardening pada keamanan cluster Anda

Dokumen ini memberikan praktik terbaik untuk meningkatkan keamanan lingkungan Google Kubernetes Engine (GKE) Anda. Spesialis keamanan yang menentukan, mengatur, dan menerapkan kebijakan serta prosedur dapat menggunakan praktik terbaik ini untuk melindungi data organisasi mereka.

Anda seharusnya sudah memahami hal-hal berikut:

Cluster GKE baru menerapkan banyak praktik terbaik dalam dokumen ini secara default. Cluster mode Autopilot memiliki postur keamanan default yang lebih ketat daripada cluster mode Standard.

Untuk menerapkan dan memberlakukan praktik terbaik dalam dokumen ini di seluruh organisasi Anda, pertimbangkan layanan berikut:

  • Security Command Center: secara otomatis memeriksa apakah cluster Anda menerapkan banyak praktik terbaik ini dan memeriksa kesalahan konfigurasi umum lainnya.
  • Organization Policy Service: menerapkan praktik terbaik tertentu pada resource GKE di organisasi, folder, atau project. Bagian tertentu dalam dokumen ini memiliki link ke konsol Google Cloud agar Anda dapat menerapkan batasan terkelola untuk rekomendasi tersebut.

Google Cloud desain lingkungan

Bagian berikut menjelaskan langkah-langkah keamanan yang harus Anda pertimbangkan saat merencanakan dan mendesain resource di Google Cloud. Arsitek cloud harus menggunakan rekomendasi ini saat merencanakan dan menentukan Google Cloud arsitektur.

Praktik terbaik

Merencanakan struktur Google Cloud resource Anda

Direkomendasikan: terapkan blueprint dasar-dasar perusahaan, yang merupakan dasar lengkap untuk lingkungan perusahaan Anda berdasarkan praktik terbaik kami.

Arsitektur organisasi, folder, dan project Anda memengaruhi postur keamanan Anda. Google Cloud Rancang resource dasar ini sedemikian rupa sehingga memungkinkan kontrol tata kelola dan keamanan dalam skala besar di seluruh layanan Anda.

Merencanakan lingkungan multi-tenant

Direkomendasikan: terapkan praktik terbaik Google Cloud dan GKE untuk platform perusahaan multi-tenant.

Banyak pelanggan GKE mengelola tim terdistribusi, dengan alur kerja dan tanggung jawab engineering yang terpisah. Lingkungan multi-tenant ini harus memiliki infrastruktur bersama yang dapat digunakan oleh semua developer Anda, sekaligus membatasi akses ke komponen berdasarkan peran dan tanggung jawab. Blueprint aplikasi perusahaan dibangun berdasarkan blueprint dasar-dasar perusahaan untuk membantu Anda men-deploy platform developer internal di lingkungan multi-tenant.

Untuk informasi selengkapnya, baca dokumen berikut:

Menggunakan tag untuk mengelompokkan Google Cloud resource

Direkomendasikan: gunakan tag untuk mengatur resource GKE guna penerapan kebijakan bersyarat dan peningkatan akuntabilitas di seluruh tim Anda.

Tag adalah metadata yang dapat Anda lampirkan ke resource di organisasi, folder, dan project untuk mengidentifikasi dimensi bisnis di seluruh hierarki resource Anda.Google Cloud Anda dapat melampirkan tag ke cluster dan node pool GKE, lalu menggunakan tag tersebut untuk menerapkan kebijakan organisasi, kebijakan IAM, atau kebijakan firewall secara bersyarat.

Untuk informasi selengkapnya, baca dokumen berikut:

Merencanakan jaringan VPC

Direkomendasikan: terapkan praktik terbaik Google Cloud dan GKE untuk desain jaringan VPC.

Desain jaringan VPC dan fitur yang Anda gunakan memengaruhi keamanan jaringan Anda. Rencanakan jaringan berdasarkan hierarki resource dan tujuan keamanan Anda. Google CloudUntuk informasi selengkapnya, baca dokumen berikut:

Merancang rencana respons insiden

Direkomendasikan: buat dan pertahankan rencana respons insiden yang memenuhi sasaran keamanan dan keandalan Anda.

Insiden keamanan dapat terjadi meskipun Anda menerapkan setiap kontrol keamanan yang mungkin. Rencana respons insiden membantu Anda mengidentifikasi potensi celah dalam kontrol keamanan, merespons berbagai jenis insiden dengan cepat dan efektif, serta mengurangi waktu non-operasional selama gangguan. Untuk informasi selengkapnya, lihat referensi berikut:

Google Cloud keamanan jaringan

Bagian berikut memberikan rekomendasi keamanan untuk jaringan VPC Anda. Arsitek jaringan dan administrator jaringan harus menerapkan rekomendasi ini untuk mengurangi permukaan serangan di tingkat jaringan dan membatasi dampak akses jaringan yang tidak diinginkan.

Praktik terbaik

Menggunakan aturan firewall hak istimewa terendah

Direkomendasikan: saat Anda membuat aturan firewall, gunakan prinsip hak istimewa terendah guna membatasi akses hanya untuk tujuan yang diperlukan. Pastikan aturan firewall Anda tidak bertentangan dengan, atau menggantikan, aturan firewall default GKE jika memungkinkan.

GKE membuat aturan firewall VPC default untuk mengaktifkan fungsionalitas sistem dan menerapkan praktik keamanan yang baik. Jika Anda membuat aturan firewall permisif dengan prioritas yang lebih tinggi daripada aturan firewall default (misalnya, aturan firewall yang mengizinkan semua traffic masuk untuk proses debug), cluster Anda berisiko mendapatkan akses yang tidak diinginkan.

Menggunakan VPC Bersama untuk traffic lintas project

Direkomendasikan: gunakan VPC Bersama agar resource di beberapa project dapat berkomunikasi satu sama lain menggunakan alamat IP internal.

Resource dalam project yang berbeda di organisasi Anda mungkin perlu berkomunikasi satu sama lain. Misalnya, layanan frontend di cluster GKE dalam satu project mungkin perlu berkomunikasi dengan instance Compute Engine backend dalam project yang berbeda.

Untuk informasi selengkapnya, baca dokumen berikut:

Menggunakan jaringan terpisah untuk mengisolasi lingkungan

Direkomendasikan: gunakan jaringan VPC Bersama yang terpisah untuk lingkungan staging, pengujian, dan produksi.

Isolasi lingkungan pengembangan Anda satu sama lain untuk mengurangi dampak dan risiko akses tidak sah atau bug yang mengganggu. Untuk mengetahui informasi selengkapnya, lihat Beberapa project host.

Setelan keamanan yang tidak dapat diubah

Bagian berikut memberikan rekomendasi keamanan yang hanya dapat Anda konfigurasi saat membuat cluster atau node pool. Anda tidak dapat mengupdate cluster atau node pool yang sudah ada untuk mengubah setelan ini. Admin platform harus menerapkan rekomendasi ini ke cluster dan node pool baru.

Menggunakan akun layanan node IAM dengan hak istimewa terendah

Direkomendasikan: gunakan akun layanan IAM kustom untuk cluster dan node pool GKE Anda, bukan akun layanan Compute Engine default.

GKE menggunakan akun layanan IAM yang terlampir ke node Anda untuk menjalankan tugas sistem seperti logging dan pemantauan. Setidaknya, akun layanan node ini harus memiliki peran Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) di project Anda. Secara default, GKE menggunakan akun layanan default Compute Engine, yang otomatis dibuat di project Anda, sebagai akun layanan node.

Jika Anda menggunakan akun layanan default Compute Engine untuk fungsi lain di project atau organisasi Anda, akun layanan tersebut mungkin memiliki lebih banyak izin daripada yang dibutuhkan GKE, yang dapat membuat Anda berisiko keamanan.

Akun layanan yang terlampir ke node Anda hanya boleh digunakan oleh workload sistem yang melakukan tugas seperti logging dan pemantauan. Untuk workload Anda sendiri, sediakan identitas menggunakan Workload Identity Federation for GKE.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.disallowDefaultComputeServiceAccount batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Menggunakan image node Container-Optimized OS

Direkomendasikan: kecuali jika Anda memiliki persyaratan khusus untuk menggunakan Ubuntu atau Windows, gunakan image node Container-Optimized OS untuk node Anda.

Container-Optimized OS dibangun, dioptimalkan, dan diperkuat secara khusus untuk menjalankan container. Container-Optimized OS adalah satu-satunya image node yang didukung untuk mode Autopilot, dan merupakan image node default untuk mode Standar.

Untuk informasi selengkapnya, baca dokumen berikut:

Konfigurasi keamanan node

Bagian berikut memberikan rekomendasi keamanan untuk konfigurasi node GKE. Admin platform dan engineer keamanan harus menerapkan rekomendasi ini untuk meningkatkan integritas node GKE Anda.

Praktik terbaik

Gunakan Node GKE yang Terlindungi

Direkomendasikan: aktifkan Node GKE yang Terlindungi, booting aman, dan pemantauan integritas di semua cluster dan node pool.

Node GKE yang Terlindungi memberikan identitas yang dapat diverifikasi dan pemeriksaan integritas yang meningkatkan keamanan node Anda. Shielded GKE Node dan fitur seperti pemantauan integritas node dan boot aman selalu diaktifkan di cluster Autopilot. Di cluster Standard, lakukan hal berikut:

  • Jangan menonaktifkan Node GKE yang Terlindungi di cluster Anda.
  • Aktifkan booting aman di semua node pool Anda.
  • Jangan menonaktifkan pemantauan integritas di node pool Anda.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan fitur ini, lihat Menggunakan Node GKE yang Terlindungi.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableShieldedNodes batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Policy details.

Buka Detail kebijakan

Menonaktifkan port hanya baca kubelet yang tidak aman

Direkomendasikan: nonaktifkan port hanya baca kubelet dan alihkan semua beban kerja yang menggunakan port 10255 agar menggunakan port 10250 yang lebih aman.

Proses kubelet yang berjalan di node menyajikan API hanya baca menggunakan port 10255 yang tidak aman. Kubernetes tidak melakukan pemeriksaan autentikasi atau otorisasi pada port ini. kubelet melayani endpoint yang sama di port 10250 yang lebih aman dan diautentikasi.

Untuk mengetahui informasi selengkapnya, lihat Menonaktifkan port hanya baca kubelet di cluster GKE.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.disableInsecureKubeletReadOnlyPort batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Kontrol akses

Bagian berikut memberikan rekomendasi untuk membatasi akses tidak sah di cluster Anda. Engineer keamanan serta admin identitas dan akun harus menerapkan rekomendasi ini untuk mengurangi permukaan serangan dan membatasi dampak akses tidak sah.

Praktik terbaik

Membatasi akses ke penemuan API cluster

Direkomendasikan: batasi akses ke bidang kontrol dan node Anda dari internet untuk mencegah akses yang tidak diinginkan ke endpoint penemuan API cluster.

Secara default, Kubernetes membuat cluster dengan serangkaian peran penemuan API default yang permisif. Peran default ini memberikan akses luas ke informasi tentang API cluster kepada berbagai grup default, seperti system:authenticated. Peran default ini tidak mewakili tingkat keamanan yang berarti untuk cluster GKE. Misalnya, grup system:authenticated, yang dapat membaca informasi tentang API seperti CustomResources, ditetapkan ke pengguna terautentikasi mana pun (termasuk siapa pun yang memiliki Akun Google).

Untuk membatasi akses ke API penemuan cluster Anda, lakukan hal berikut:

  • Membatasi akses ke bidang kontrol: gunakan hanya endpoint berbasis DNS untuk akses bidang kontrol. Jika Anda menggunakan endpoint berbasis IP, batasi akses ke serangkaian rentang alamat yang diketahui dengan mengonfigurasi jaringan yang diizinkan.
  • Konfigurasi node pribadi: nonaktifkan alamat IP eksternal node Anda, sehingga klien di luar jaringan Anda tidak dapat mengakses node.

Untuk mengetahui informasi selengkapnya, lihat Tentang isolasi jaringan.

Jika Anda tidak mengaktifkan fitur isolasi jaringan ini, perlakukan semua informasi penemuan API (terutama skema CustomResources, definisi APIService, dan informasi penemuan yang dihosting oleh server API ekstensi) sebagai informasi yang terungkap secara publik.

Menempatkan tim dan lingkungan di namespace atau cluster terpisah

Berikan tim Anda akses hak istimewa terendah ke Kubernetes dengan membuat namespace atau cluster terpisah untuk setiap tim dan lingkungan. Untuk setiap namespace atau cluster, tetapkan pusat biaya dan label untuk akuntabilitas dan penagihan balik.

Anda dapat menggunakan izin IAM dan RBAC beserta namespace untuk membatasi interaksi pengguna dengan resource cluster di Google Cloud konsol. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan akses dan melihat resource cluster berdasarkan namespace.

Menggunakan prinsip hak istimewa terendah dalam kebijakan akses

Direkomendasikan: hanya berikan akses yang diperlukan kepada developer untuk men-deploy dan mengelola aplikasi di namespace mereka, terutama di lingkungan produksi. Saat mendesain kebijakan kontrol akses, petakan tugas yang perlu dilakukan pengguna di cluster dan berikan hanya izin yang memungkinkan mereka melakukan tugas tersebut.

Di GKE, Anda dapat menggunakan IAM dan role-based access control (RBAC) Kubernetes untuk memberikan izin pada resource. Mekanisme kontrol akses ini bekerja sama. Untuk mengurangi kompleksitas pengelolaan akses, lakukan hal berikut:

  • Untuk memberikan akses ke project atau Google Cloud resource, gunakan peran IAM.

  • Untuk memberikan akses ke resource Kubernetes di cluster Anda, seperti namespace, gunakan RBAC.

Untuk mengetahui informasi selengkapnya tentang perencanaan dan perancangan kebijakan IAM dan RBAC, lihat dokumen berikut:

Menggunakan Workload Identity Federation for GKE untuk mengakses Google Cloud API

Direkomendasikan: untuk mengakses Google Cloud resource dari workload GKE Anda, gunakan Workload Identity Federation for GKE.

Workload Identity Federation for GKE adalah cara yang direkomendasikan untuk melakukan autentikasi ke Google Cloud API. Anda dapat memberikan peran IAM pada berbagai resource kepada entity utama di cluster Anda, seperti ServiceAccount atau Pod Kubernetes tertentu. Workload Identity Federation untuk GKE juga melindungi metadata sensitif di node Anda dan memberikan alur kerja autentikasi yang lebih aman daripada alternatif seperti file token statis.

Workload Identity Federation for GKE selalu diaktifkan di cluster Autopilot. Di cluster Standard, aktifkan Workload Identity Federation for GKE untuk semua cluster dan node pool. Selain itu, ikuti rekomendasi berikut:

  • Jika Anda menggunakan library klien Google Cloud dalam kode aplikasi Anda, jangan distribusikan kredensial Google Cloud ke beban kerja Anda. Kode yang menggunakan library klien akan otomatis mengambil kredensial untuk Workload Identity Federation for GKE.
  • Gunakan namespace dan ServiceAccount terpisah untuk setiap workload yang memerlukan identitas yang berbeda. Memberikan izin IAM ke ServiceAccount tertentu.

Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi ke Google Cloud API dari workload GKE.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableWorkloadIdentityFederation batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Menggunakan grup untuk mengelola akses

Direkomendasikan: dalam kebijakan akses Anda, berikan izin kepada grup pengguna, bukan kepada individu.

Saat Anda mengelola pengguna dalam grup, sistem pengelolaan identitas dan administrator identitas Anda dapat mengontrol identitas secara terpusat dengan mengubah keanggotaan pengguna dalam berbagai grup. Jenis pengelolaan ini menghilangkan kebutuhan untuk memperbarui kebijakan RBAC atau IAM setiap kali pengguna tertentu memerlukan izin yang diperbarui.

Anda dapat menentukan Google Grup dalam kebijakan IAM atau RBAC. Untuk informasi selengkapnya, baca dokumen berikut:

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableGoogleGroupsRBAC batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Membatasi akses anonim ke endpoint cluster

Direkomendasikan: mencegah permintaan anonim ke semua endpoint cluster kecuali untuk endpoint pemeriksaan kondisi, di semua cluster Autopilot dan Standar.

Secara default, Kubernetes menetapkan pengguna system:anonymous dan grup system:unauthenticated ke permintaan anonim ke endpoint cluster. Jika kebijakan RBAC Anda memberikan izin tambahan kepada pengguna atau grup ini, pengguna anonim mungkin dapat membahayakan keamanan layanan atau cluster itu sendiri.

Di GKE versi 1.32.2-gke.1234000 dan yang lebih baru, Anda dapat membatasi kumpulan endpoint yang dapat dijangkau oleh permintaan anonim hanya ke endpoint pemeriksaan kondisi server API Kubernetes /healthz, /livez, dan /readyz. Akses anonim ke endpoint health check ini diperlukan untuk memverifikasi bahwa cluster beroperasi dengan benar.

Untuk membatasi akses anonim ke endpoint cluster, tentukan LIMITED untuk flag --anonymous-authentication-config saat Anda menggunakan gcloud CLI atau GKE API untuk membuat atau mengupdate cluster Standar dan Autopilot. GKE menolak permintaan anonim ke endpoint cluster yang bukan endpoint health check selama autentikasi. Permintaan anonim tidak mencapai endpoint, meskipun kebijakan RBAC Anda memberikan akses ke pengguna dan grup anonim. Permintaan yang ditolak akan menampilkan status HTTP 401.

Untuk menerapkan rekomendasi ini di organisasi, folder, atau project Anda menggunakan kebijakan organisasi, buat batasan kustom dengan kondisi resource.anonymousAuthenticationConfig.mode. Untuk mengetahui informasi selengkapnya dan contoh batasan, lihat Membatasi tindakan pada resource GKE menggunakan kebijakan organisasi kustom.

Jangan hanya mengandalkan kemampuan ini untuk mengamankan cluster Anda. Terapkan langkah-langkah keamanan tambahan seperti berikut:

Keamanan jaringan GKE

Bagian berikut memberikan rekomendasi untuk meningkatkan keamanan jaringan di cluster Anda. Administrator jaringan dan engineer keamanan harus menerapkan rekomendasi ini untuk melindungi beban kerja dan infrastruktur dari akses eksternal atau internal yang tidak diinginkan.

Praktik terbaik

Membatasi akses ke bidang kontrol

Direkomendasikan: aktifkan endpoint berbasis DNS untuk akses bidang kontrol dan nonaktifkan semua endpoint bidang kontrol berbasis IP.

Secara default, entitas eksternal, seperti klien di internet, dapat menjangkau bidang kontrol Anda. Anda dapat membatasi siapa yang dapat mengakses bidang kontrol dengan mengonfigurasi isolasi jaringan.

Untuk mengisolasi panel kontrol, lakukan salah satu tindakan berikut:

  • Gunakan hanya endpoint berbasis DNS (direkomendasikan): aktifkan endpoint berbasis DNS untuk bidang kontrol dan nonaktifkan endpoint berbasis IP internal dan eksternal. Semua akses bidang kontrol harus menggunakan endpoint berbasis DNS. Anda dapat menggunakan Kontrol Layanan VPC untuk mengontrol siapa yang dapat mengakses endpoint berbasis DNS.

    Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableControlPlaneDNSOnlyAccess batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Policy details.

    Buka Detail kebijakan

  • Menonaktifkan endpoint berbasis IP eksternal: hapus alamat IP eksternal bidang kontrol. Klien yang berada di luar jaringan VPC Anda tidak dapat menggunakan alamat IP eksternal untuk mengakses bidang kontrol.

    Opsi ini berfungsi baik jika Anda menggunakan teknologi seperti Cloud Interconnect dan Cloud VPN untuk menghubungkan jaringan perusahaan Anda ke jaringan VPC Anda.

  • Gunakan jaringan yang diizinkan dengan endpoint berbasis IP eksternal: batasi akses ke endpoint berbasis IP eksternal hanya untuk rentang alamat IP sumber yang tepercaya.

    Opsi ini berfungsi dengan baik jika Anda tidak memiliki infrastruktur VPN, atau jika Anda memiliki pengguna jarak jauh atau kantor cabang yang mengakses cluster Anda menggunakan internet publik.

Dalam sebagian besar skenario, gunakan hanya endpoint berbasis DNS untuk akses bidang kontrol. Jika Anda harus mengaktifkan endpoint berbasis IP, gunakan jaringan yang diizinkan untuk membatasi akses bidang kontrol ke entitas berikut:

  • Rentang alamat IP yang Anda tentukan.
  • Node GKE dalam jaringan VPC yang sama dengan cluster.
  • Alamat IP yang dicadangkan Google untuk tujuan pengelolaan cluster.

Mengisolasi node dari internet

Secara default, semua node GKE memiliki alamat IP eksternal yang dapat dijangkau oleh klien di internet. Untuk menghapus alamat IP eksternal ini, aktifkan node pribadi.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enablePrivateNodes batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Membatasi traffic jaringan di antara Pod

Direkomendasikan: kontrol traffic jaringan Pod-ke-Pod dengan menggunakan NetworkPolicy, mesh layanan, atau keduanya.

Secara default, setiap Pod di cluster Anda dapat berkomunikasi dengan setiap Pod lainnya. Membatasi akses jaringan antar-layanan akan mempersulit penyerang untuk bergerak secara lateral dalam cluster Anda. Layanan Anda juga mendapatkan perlindungan terhadap insiden denial of service yang disengaja atau tidak disengaja. Bergantung pada persyaratan Anda, gunakan salah satu atau kedua metode berikut untuk membatasi traffic Pod-ke-Pod:

  • Gunakan Cloud Service Mesh jika Anda menginginkan fitur seperti load balancing, otorisasi layanan, pembatasan, kuota, dan metrik. Mesh layanan berguna jika Anda memiliki sejumlah besar layanan berbeda yang memiliki interaksi yang kompleks satu sama lain.

  • Gunakan NetworkPolicy Kubernetes jika Anda menginginkan mekanisme kontrol alur traffic dasar. Untuk memverifikasi bahwa NetworkPolicy Anda berfungsi seperti yang diharapkan, konfigurasikan logging kebijakan jaringan.

    Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableNetworkPolicy batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

    Buka Detail kebijakan

Perlindungan data sensitif

Bagian berikut memberikan rekomendasi untuk mengenkripsi data dan melindungi informasi sensitif seperti kredensial. Engineer keamanan dan admin platform harus menerapkan rekomendasi ini untuk mengurangi risiko akses yang tidak disengaja ke data penting.

Praktik terbaik

Mengenkripsi data workload yang sedang digunakan

Gunakan enkripsi memori berbasis hardware untuk melindungi data yang sedang digunakan oleh beban kerja Anda dengan menggunakan Confidential GKE Node. Anda dapat memilih teknologi Confidential Computing berdasarkan persyaratan Anda. Untuk mengetahui informasi selengkapnya, lihat Mengenkripsi data workload yang sedang digunakan dengan Confidential GKE Node.

Menyimpan secret di luar cluster

Direkomendasikan: gunakan pengelola secret eksternal seperti Secret Manager untuk menyimpan data sensitif, seperti kunci API, di luar cluster Anda.

Di Kubernetes, Anda dapat menyimpan data sensitif dalam Secret di cluster Anda. Anda dapat menggunakan Secret untuk memberikan data rahasia ke aplikasi tanpa menyertakan data tersebut dalam kode aplikasi. Namun, menyimpan data ini di cluster Anda memiliki risiko seperti berikut:

  • Siapa saja yang dapat membuat Pod di namespace dapat membaca data Secret apa pun di namespace tersebut.
  • Siapa pun yang memiliki akses RBAC atau IAM untuk membaca semua objek Kubernetes API dapat membaca Secret.

Karena risiko ini, buat Secret di cluster Anda hanya jika Anda tidak dapat memberikan data tersebut ke workload Anda dengan cara lain. Sebaiknya gunakan metode berikut, berdasarkan urutan preferensi, untuk menyimpan dan mengakses data sensitif Anda:

  • Library klien Secret Manager: mengakses secret secara terprogram dari kode aplikasi Anda menggunakan Secret Manager API dengan Workload Identity Federation untuk GKE. Untuk mengetahui informasi selengkapnya, lihat Mengakses secret yang disimpan di luar cluster GKE menggunakan library klien.
  • Data Secret Manager sebagai volume yang terpasang: menyediakan data sensitif ke Pod Anda sebagai volume yang terpasang menggunakan add-on Secret Manager untuk GKE. Metode ini berguna jika Anda tidak dapat mengubah kode aplikasi untuk menggunakan library klien Secret Manager. Untuk mengetahui informasi selengkapnya, lihat Menggunakan add-on Secret Manager dengan Google Kubernetes Engine.

  • Alat pengelolaan secret pihak ketiga: alat pihak ketiga seperti HashiCorp Vault menyediakan kemampuan pengelolaan secret untuk workload Kubernetes. Alat ini memerlukan konfigurasi awal yang lebih banyak daripada Secret Manager, tetapi merupakan opsi yang lebih aman daripada membuat Secret di cluster. Untuk mengonfigurasi alat pihak ketiga untuk pengelolaan secret, lihat dokumentasi penyedia. Selain itu, pertimbangkan rekomendasi berikut:

    • Jika alat pihak ketiga berjalan di cluster, gunakan cluster yang berbeda dengan cluster yang menjalankan workload Anda.
    • Gunakan Cloud Storage atau Spanner untuk menyimpan data alat.
    • Gunakan Load Balancer Jaringan passthrough internal untuk mengekspos alat pengelolaan rahasia pihak ketiga ke Pod yang berjalan di jaringan VPC Anda.

  • Menggunakan Secret Kubernetes (tidak direkomendasikan): jika tidak ada opsi sebelumnya yang cocok untuk kasus penggunaan Anda, Anda dapat menyimpan data sebagai Secret Kubernetes. Google Cloud mengenkripsi data di lapisan penyimpanan secara default. Enkripsi lapisan penyimpanan default ini mencakup database yang menyimpan status cluster Anda, yang didasarkan pada etcd atau Spanner. Selain itu, Anda dapat mengenkripsi Secret ini pada lapisan aplikasi dengan kunci yang Anda kelola. Untuk mengetahui informasi selengkapnya, lihat Mengenkripsi secret di lapisan aplikasi.

Keamanan workload

Bagian berikut memberikan rekomendasi untuk meningkatkan keamanan cluster Anda terhadap masalah workload. Engineer keamanan dan admin platform harus menerapkan rekomendasi ini untuk meningkatkan perlindungan infrastruktur GKE dari workload.

Praktik terbaik

Mengisolasi workload dengan menggunakan GKE Sandbox

Direkomendasikan: gunakan GKE Sandbox untuk mencegah kode berbahaya memengaruhi kernel host di node cluster Anda.

Anda dapat menjalankan container di lingkungan yang di-sandbox untuk memitigasi sebagian besar serangan container escape, yang juga disebut serangan eskalasi akses lokal. Seperti yang dijelaskan dalam buletin keamanan GKE, jenis serangan ini memungkinkan penyerang mendapatkan akses ke VM host container. Penyerang dapat menggunakan akses host ini untuk mengakses container lain di VM yang sama. GKE Sandbox dapat membantu membatasi dampak serangan ini.

Gunakan GKE Sandbox dalam skenario seperti berikut:

  • Anda memiliki workload yang menjalankan kode tidak tepercaya.
  • Anda ingin membatasi dampak jika penyerang menyusupi container di Workload.

Untuk mengetahui informasi selengkapnya, lihat Memperkuat isolasi workload dengan GKE Sandbox.

Membatasi kemampuan workload dalam modifikasi mandiri

Direkomendasikan: gunakan pengontrol penerimaan untuk mencegah workload mengubah dirinya sendiri, atau untuk mencegah modifikasi atribut workload yang berisiko seperti ServiceAccount.

Workload Kubernetes tertentu, terutama workload sistem, memiliki izin untuk menjalankan modifikasi mandiri Sebagai contoh, beberapa workload melakukan penskalaan otomatis secara vertikal. Meskipun berguna, modifikasi mandiri dapat memungkinkan penyerang yang telah menyusupi node untuk menjelajahi cluster lebih dalam lagi. Misalnya, penyerang dapat membuat workload di namespace melakukan modifikasi mandiri untuk dijalankan sebagai ServiceAccount dengan hak istimewa yang lebih tinggi di namespace yang sama.

Kecuali jika diperlukan, jangan berikan izin kepada Pod untuk mengubah dirinya sendiri. Jika beberapa Pod harus mengubah dirinya sendiri, gunakan Policy Controller untuk membatasi apa yang dapat diubah oleh workload. Misalnya, Anda dapat menggunakan template batasan NoUpdateServiceAccount untuk mencegah Pod mengubah ServiceAccount-nya. Saat membuat kebijakan, kecualikan komponen pengelolaan cluster dari batasan Anda, seperti dalam contoh berikut:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Penegakan berbasis kebijakan

Bagian berikut memberikan rekomendasi untuk menggunakan kebijakan guna menerapkan batasan keamanan di beberapa resource. Admin identitas dan akun serta engineer keamanan harus menerapkan rekomendasi ini untuk mempertahankan kepatuhan cluster dan workload terhadap persyaratan keamanan organisasi.

Praktik terbaik

Menerapkan kebijakan di seluruh Google Cloud hierarki resource

Direkomendasikan: untuk menerapkan praktik keamanan di organisasi, folder, atau project Anda, gunakan Layanan Kebijakan Organisasi.

Dengan Kebijakan Organisasi, Anda dapat menentukan batasan secara terpusat dan menerapkannya di berbagai tingkat hierarki resource Anda. Berbagai produk memublikasikan batasan terkelola yang memungkinkan Anda menerapkan rekomendasi praktik terbaik untuk produk tersebut. Google Cloud Misalnya, GKE memublikasikan batasan terkelola untuk banyak praktik terbaik dalam dokumen ini.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan Kebijakan Organisasi, lihat Membuat dan mengelola kebijakan organisasi.

Menerapkan kebijakan selama penerimaan beban kerja

Direkomendasikan: gunakan pengontrol penerimaan seperti Policy Controller atau pengontrol penerimaan PodSecurity untuk meninjau permintaan API masuk dan menerapkan kebijakan pada permintaan tersebut.

Pengontrol penerimaan mencegat permintaan yang diautentikasi dan diotorisasi ke Kubernetes API untuk melakukan tugas validasi atau mutasi sebelum mengizinkan resource dipertahankan di API.

Anda dapat menggunakan metode berikut untuk kontrol penerimaan di cluster GKE:

Pengelolaan cluster

Bagian berikut memberikan rekomendasi untuk mengelola cluster Anda dari waktu ke waktu, seperti mengupgrade, memantau, dan mengonfigurasi log. Engineer keamanan, admin platform, dan SRE harus menggunakan rekomendasi ini untuk mempertahankan postur keamanan platform GKE.

Praktik terbaik

Mengupgrade infrastruktur GKE Anda secara rutin

Direkomendasikan: selalu perbarui versi GKE Anda untuk mengakses fitur keamanan baru dan menerapkan patch keamanan. Gunakan saluran rilis, upgrade otomatis patch yang dipercepat, dan upgrade node otomatis.

Kubernetes dan GKE sering merilis versi patch baru yang mencakup peningkatan keamanan dan perbaikan kerentanan. Untuk semua cluster, GKE secara otomatis mengupgrade bidang kontrol ke versi patch dan versi minor yang lebih stabil.

Untuk memastikan cluster GKE Anda menjalankan versi terbaru, lakukan hal berikut:

  • Daftarkan cluster Anda di saluran rilis. Cluster Autopilot selalu terdaftar di saluran rilis.
  • Untuk cluster yang berada di saluran rilis, aktifkan upgrade otomatis patch yang dipercepat untuk mendapatkan versi patch keamanan segera setelah tersedia di saluran rilis Anda.
  • Untuk cluster Standar yang tidak berada di saluran rilis, aktifkan upgrade node otomatis. Upgrade otomatis node diaktifkan secara default untuk cluster yang dibuat menggunakan Google Cloud konsol sejak Juni 2019, dan untuk cluster yang dibuat menggunakan GKE API mulai 11 November 2019.
  • Jika Anda menggunakan kebijakan pemeliharaan, gunakan masa pemeliharaan agar GKE mengupgrade node Anda secara otomatis setidaknya sebulan sekali.
  • Untuk node pool yang tidak menggunakan upgrade otomatis node, upgrade node pool setidaknya sebulan sekali sesuai jadwal Anda.
  • Pantau buletin keamanan GKE dan catatan rilis GKE untuk mengetahui informasi tentang patch keamanan.

Mengaktifkan notifikasi buletin keamanan

Direkomendasikan: konfigurasi notifikasi untuk buletin keamanan baru yang memengaruhi cluster Anda.

Jika tersedia buletin keamanan yang relevan dengan cluster Anda, GKE akan memublikasikan notifikasi tentang peristiwa tersebut sebagai pesan ke topik Pub/Sub yang Anda konfigurasikan. Anda dapat menerima notifikasi ini di langganan Pub/Sub, berintegrasi dengan layanan pihak ketiga, dan menerima notifikasi di Cloud Logging.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableSecurityBulletinNotifications batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Policy details.

Buka Detail kebijakan

Mengonfigurasi pengumpulan log

Direkomendasikan: untuk mengurangi overhead operasional dan mempertahankan tampilan gabungan log Anda, terapkan strategi logging yang konsisten di seluruh cluster Anda. Jangan menonaktifkan pengumpulan log di cluster Standard Anda.

Cluster GKE mengirimkan log tertentu ke Google Cloud Observability. Anda dapat mengonfigurasi pengumpulan jenis log tambahan secara opsional. Selain log sistem dan beban kerja, semua cluster GKE mengirimkan log audit berikut ke Logging:

  • Log audit Kubernetes: catatan kronologis panggilan yang telah dilakukan ke server Kubernetes API. Entri log audit Kubernetes berguna untuk menyelidiki permintaan API yang mencurigakan, mengumpulkan statistik, atau membuat pemberitahuan pemantauan terkait panggilan API yang tidak diinginkan.
  • Log audit GKE: catatan aktivitas administratif dan akses untuk GKE API.

Untuk informasi selengkapnya, baca dokumen berikut:

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.enableCloudLogging batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Memantau masalah keamanan pada resource Anda

Gunakan dasbor postur keamanan GKE dan Security Command Center untuk memantau potensi masalah pada cluster dan workload Anda. Anda dapat menggunakan layanan ini untuk memeriksa kerentanan, ancaman, dan buletin keamanan aktif yang memengaruhi infrastruktur GKE Anda.

Konfigurasi keamanan default

Bagian berikut menjelaskan opsi yang dikonfigurasi secara default di cluster baru untuk memitigasi masalah keamanan tertentu, seperti kerentanan atau risiko. Engineer keamanan dan admin platform harus memvalidasi bahwa cluster yang ada menggunakan setelan ini.

Praktik terbaik

Membiarkan metode autentikasi klien lama dinonaktifkan

Direkomendasikan: nonaktifkan metode autentikasi server API lama seperti sertifikat statis dan sandi.

Ada beberapa metode untuk mengautentikasi ke server Kubernetes API. Di GKE, metode yang didukung adalah token pemilik akun layanan, token OAuth, dan sertifikat klien X.509. gcloud CLI menggunakan token OAuth untuk mengautentikasi pengguna untuk GKE.

Metode autentikasi lama seperti sandi statis dinonaktifkan, karena metode ini meningkatkan permukaan serangan untuk penyusupan cluster. Di cluster Autopilot, Anda tidak dapat mengaktifkan atau menggunakan metode autentikasi ini.

Gunakan salah satu metode berikut untuk melakukan autentikasi ke server Kubernetes API:

  • Pengguna: gunakan gcloud CLI untuk mengizinkan GKE mengautentikasi pengguna, membuat token akses OAuth untuk cluster, dan terus memperbarui token.
  • Aplikasi: gunakan Workload Identity Federation agar aplikasi di Google Cloud atau di lingkungan lain dapat melakukan autentikasi ke cluster Anda.

Untuk mengetahui informasi selengkapnya tentang cara melakukan autentikasi dan cara menonaktifkan metode autentikasi lama, lihat Melakukan autentikasi ke server Kubernetes API.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.disableLegacyClientCertificateIssuance batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Membiarkan ABAC dinonaktifkan

Direkomendasikan: gunakan IAM dan RBAC untuk mengontrol akses di GKE. Jangan aktifkan kontrol akses berbasis atribut (ABAC).

ABAC adalah metode otorisasi lama yang dinonaktifkan secara default di semua cluster GKE, dan tidak dapat diaktifkan di cluster Autopilot.

Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.disableABAC batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Detail kebijakan.

Buka Detail kebijakan

Membiarkan pengontrol penerimaan DenyServiceExternalIPs diaktifkan

Direkomendasikan: jangan nonaktifkan pengontrol penerimaan DenyServiceExternalIPs.

Pengontrol penerimaan ini mencegah Layanan agar tidak menggunakan ExternalIP dan meminimalkan risiko GCP-2020-015. Pengontrol penerimaan ini diaktifkan secara default di cluster yang dibuat di GKE versi 1.21 dan yang lebih baru. Untuk cluster yang awalnya dibuat di versi GKE sebelumnya, aktifkan pengontrol penerimaan:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Untuk menerapkan rekomendasi ini di organisasi Anda, gunakan constraints/container.managed.denyServiceExternalIPs batasan Kebijakan Organisasi terkelola. Untuk meninjau batasan terkelola ini di konsol Google Cloud , buka halaman Policy details.

Buka Detail kebijakan

Langkah berikutnya