Melakukan hardening pada keamanan cluster Anda

Dengan cepatnya ritme pengembangan di Kubernetes, akan sering diperkenalkan fitur keamanan baru yang dapat Anda gunakan. Dokumen ini menjelaskan cara melakukan hardening pada cluster Google Distributed Cloud Anda.

Dokumen ini memprioritaskan mitigasi keamanan penting yang memerlukan tindakan Anda saat pembuatan cluster. Fitur yang kurang penting, setelan yang aman secara default, dan fitur yang dapat diaktifkan setelah pembuatan cluster akan dibahas nanti dalam dokumen ini. Untuk ringkasan umum topik keamanan, tinjau Keamanan.

Checklist

Checklist deployment berikut menyoroti praktik terbaik untuk melakukan hardening pada deployment platform cluster GKE Anda. Untuk mengetahui informasi selengkapnya tentang setiap praktik, lihat bagian dalam dokumen ini.

Checklist deployment Deskripsi
Kontrol akses dan identitas

Menggunakan hak istimewa akun vSphere:
Gunakan akun administrator vSphere dengan hak istimewa minimal.

Mengamankan Google Cloud akun layanan:
Minimalkan Google Cloud hak istimewa akun layanan.

Mengonfigurasi OpenID Connect (OIDC):
Konfigurasi OpenID Connect untuk autentikasi pengguna.

Menggunakan namespace dan RBAC Kubernetes untuk membatasi akses:
Gunakan namespace dengan RBAC untuk isolasi administratif serta peran dan hak istimewa hak istimewa terendah.

Perlindungan data

Mengenkripsi virtual machine vSphere:
Tetapkan vSphere untuk mengenkripsi volume yang digunakan oleh Google Distributed Cloud.

Mengelola secret:
Enkripsi secret dalam penyimpanan.

Perlindungan jaringan

Membatasi akses jaringan ke bidang kontrol dan node:
Siapkan kontrol untuk mengisolasi dan melindungi jaringan dan node bidang kontrol.

Menggunakan kebijakan jaringan untuk membatasi traffic:
Terapkan kebijakan jaringan untuk membatasi traffic intra-cluster.

Keamanan deklaratif

Menggunakan Pengontrol Kebijakan:
Instal Pengontrol Kebijakan untuk kebijakan keamanan deklaratif dalam cluster Anda.

Pemeliharaan

Upgrade:
Pastikan Anda menjalankan Google Distributed Cloud versi terbaru.

Memantau buletin keamanan:
Periksa buletin keamanan GKE untuk mengetahui saran terbaru dan panduan tentang pembuatan versi.

Monitoring dan logging

Menetapkan opsi untuk logging:
Pastikan logging diaktifkan dan terintegrasi ke dalam solusi SIEM.

Kontrol akses dan identitas

Bagian ini memberikan informasi tentang cara mengontrol akses ke cluster Anda.

Menggunakan hak istimewa akun vSphere

Akun pengguna vCenter yang Anda gunakan untuk menginstal Google Distributed Cloud harus memiliki hak istimewa yang memadai. Misalnya, akun pengguna yang diberi peran Administrator vCenter memiliki hak istimewa untuk akses lengkap ke semua objek vCenter dan memberikan akses penuh kepada administrator cluster Google Distributed Cloud.

The prinsip hak istimewa terendah direkomendasikan, hanya memberikan hak istimewa yang diperlukan untuk berhasil menginstal {product_name}}. Kami telah menetapkan serangkaian hak istimewa minimum yang diperlukan untuk melakukan penginstalan, serta perintah yang diperlukan untuk memberikan izin ini.

Mengamankan Google Cloud akun layanan

Google Distributed Cloud memerlukan beberapa Google Cloud akun layanan. Selama penginstalan, Anda mengikat peran Identity and Access Management ke akun layanan ini. Peran tersebut memberikan hak istimewa tertentu kepada akun layanan dalam project Anda. Beberapa akun layanan dapat dibuat untuk Anda selama penginstalan.

Mengonfigurasi autentikasi untuk pengguna cluster

Untuk mengonfigurasi autentikasi pengguna untuk cluster Anda, Anda dapat menggunakan OpenID Connect (OIDC) atau Lightweight Directory Access Protocol (LDAP).

Untuk mengetahui informasi selengkapnya, lihat Layanan Identitas GKE.

Menggunakan namespace dan RBAC Kubernetes untuk membatasi akses

Untuk memberikan akses hak istimewa terendah kepada tim ke Kubernetes, buat Kubernetes Namespace atau cluster khusus lingkungan. Tetapkan pusat biaya dan label yang sesuai ke setiap namespace untuk akuntabilitas dan penagihan balik. Hanya berikan tingkat akses secukupnya kepada developer agar dapat mengakses Namespace untuk men-deploy dan mengelola aplikasi mereka, terutama dalam produksi.

Petakan tugas yang perlu diselesaikan pengguna terhadap cluster dan tentukan izin yang diperlukan untuk menyelesaikan setiap tugas. Untuk memberikan izin tingkat cluster dan namespace, gunakan Kubernetes RBAC.

Selain izin untuk Google Cloud service accounts yang digunakan untuk menginstal Google Distributed Cloud, IAM tidak berlaku untuk cluster Google Distributed Cloud.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

Perlindungan data

Bagian ini memberikan informasi tentang cara melindungi data Anda.

Mengenkripsi virtual machine vSphere

Node cluster Google Distributed Cloud berjalan di virtual machine (VM) di cluster vSphere Anda. Google sangat menyarankan Anda mengenkripsi semua data dalam penyimpanan. Untuk melakukannya di vSphere, ikuti Panduan Konfigurasi & Hardening Keamanan VMware vSphere 7 dan panduan praktik terbaik untuk mengenripsi VM.

Hal ini harus dilakukan sebelum penginstalan Google Distributed Cloud.

Mengelola secret

Untuk memberikan lapisan perlindungan tambahan untuk data sensitif, seperti Secret Kubernetes yang disimpan di etcd, konfigurasi secret manager yang terintegrasi dengan cluster Google Distributed Cloud.

Jika Anda menjalankan workload di beberapa lingkungan, Anda mungkin lebih memilih solusi yang berfungsi untuk Google Kubernetes Engine dan Google Distributed Cloud. Jika Anda memilih untuk menggunakan secret manager eksternal, seperti HashiCorp Vault, siapkan sebelum mengintegrasikan cluster Google Distributed Cloud Anda.

Anda memiliki beberapa opsi untuk pengelolaan secret:

  • Anda dapat menggunakan Secret Kubernetes secara native di Google Distributed Cloud. Kami berharap cluster menggunakan enkripsi vSphere untuk VM seperti yang dijelaskan sebelumnya, yang memberikan perlindungan enkripsi dalam penyimpanan dasar untuk secret. Secret tidak dienkripsi lebih lanjut secara default.
  • Anda dapat menggunakan secret manager eksternal, seperti HashiCorp Vault. Anda dapat melakukan autentikasi ke HashiCorp menggunakan akun layanan Kubernetes atau akun Google Cloud layanan.

Perlindungan jaringan

Bagian ini memberikan informasi tentang cara melindungi jaringan Anda.

Membatasi akses jaringan ke bidang kontrol dan node

Usahakan agar bidang kontrol dan node cluster Anda tidak terlalu terekspos ke internet. Pilihan ini tidak dapat diubah setelah pembuatan cluster. Secara default, node cluster Google Distributed Cloud dibuat menggunakan alamat RFC 1918, dan sebaiknya jangan mengubahnya. Terapkan aturan firewall di jaringan lokal Anda untuk membatasi akses ke bidang kontrol.

Menggunakan kebijakan jaringan untuk membatasi traffic

Secara default, semua Layanan di cluster Google Distributed Cloud dapat saling berkomunikasi. Untuk mengetahui informasi tentang cara mengontrol komunikasi Layanan-ke-Layanan sesuai kebutuhan workload Anda, lihat bagian berikut.

Membatasi akses jaringan ke layanan dapat mempersempit ruang gerak penyerang dalam cluster Anda, dan juga memberikan perlindungan tambahan terhadap denial of service baik yang disengaja maupun tidak. Ada dua cara yang direkomendasikan untuk mengontrol traffic:

  • Untuk mengontrol traffic L7 ke endpoint aplikasi Anda, gunakan Istio. Pilih opsi ini jika Anda tertarik dengan load balancing, otorisasi layanan, pembatasan, kuota, dan metrik.
  • Untuk mengontrol traffic L4 antar-Pod, gunakan kebijakan jaringan Kubernetes. Pilih opsi ini jika Anda memerlukan kemampuan kontrol akses dasar yang dikelola oleh Kubernetes.

Anda dapat mengaktifkan kebijakan jaringan Istio dan Kubernetes setelah membuat cluster Google Distributed Cloud. Anda dapat menggunakannya bersama-sama jika perlu.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

Keamanan deklaratif

Bagian ini memberikan rekomendasi untuk mengamankan cluster Anda.

Menggunakan Pengontrol Kebijakan

Pengontrol penerimaan Kubernetes adalah plugin yang mengatur dan menerapkan cara penggunaan cluster Kubernetes. Pengontrol penerimaan adalah bagian penting dari pendekatan pertahanan mendalam untuk melakukan hardening pada cluster Anda.

Praktik terbaiknya adalah menggunakan Pengontrol Kebijakan. Pengontrol Kebijakan menggunakan OPA Constraint Framework untuk mendeskripsikan dan menerapkan kebijakan sebagai CRD. Batasan yang Anda terapkan ke cluster Anda ditentukan dalam template batasan, yang di-deploy di cluster Anda.

Untuk mengetahui informasi tentang cara menggunakan batasan Pengontrol Kebijakan untuk mencapai banyak perlindungan yang sama dengan PodSecurityPolicies, dengan kemampuan tambahan untuk menguji kebijakan Anda sebelum menerapkannya, lihat Menggunakan batasan untuk menerapkan keamanan Pod.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

Membatasi kemampuan workload dalam modifikasi mandiri

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

Idealnya, workload seharusnya sejak awal tidak diizinkan untuk melakukan modifikasi mandiri. Jika memerlukan modifikasi mandiri, Anda dapat membatasi izin dengan menerapkan batasan Pemilah Komunikasi atau Pengontrol Kebijakan, seperti NoUpdateServiceAccount dari library open source Pemilah Komunikasi, yang memberikan beberapa solusi keamanan bermanfaat.

Saat Anda men-deploy kebijakan, biasanya Anda perlu mengizinkan pengontrol yang mengelola siklus proses cluster untuk mengabaikan kebijakan dan pipeline logging serta monitoring. Hal ini diperlukan agar pengontrol dapat membuat perubahan pada cluster, seperti menerapkan upgrade cluster. Misalnya, jika Anda men-deploy kebijakan NoUpdateServiceAccount di Google Distributed Cloud, Anda harus menetapkan parameter berikut di Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:serviceaccount:kube-system:monitoring-operator
  - system:serviceaccount:kube-system:stackdriver-operator
  - system:serviceaccount:kube-system:metrics-server-operator
  - system:serviceaccount:kube-system:logmon-operator

Pemeliharaan

Bagian ini memberikan informasi tentang cara memelihara cluster Anda.

Mengupgrade Google Distributed Cloud

Kubernetes secara berkala memperkenalkan fitur keamanan baru dan memberikan patch keamanan.

Anda bertanggung jawab untuk memastikan cluster Google Distributed Cloud Anda selalu yang terbaru. Untuk setiap rilis, tinjau catatan rilis. Selain itu, rencanakan untuk mengupdate ke rilis patch baru setiap bulan dan versi minor setiap tiga bulan. Pelajari cara meng upgrade cluster Anda.

Anda juga bertanggung jawab untuk mengupgrade dan mengamankan infrastruktur vSphere:

Memantau buletin keamanan

Tim keamanan GKE memublikasikan buletin keamanan untuk kerentanan tingkat keparahan tinggi dan penting.

Buletin ini mengikuti skema penomoran kerentanan umum Google Cloud dan ditautkan dari halaman buletin utama Google Cloud dan catatan rilis Google Distributed Cloud. Setiap halaman buletin keamanan memiliki feed RSS tempat pengguna dapat berlangganan info terbaru.

Jika tindakan pelanggan diperlukan untuk mengatasi kerentanan tingkat tinggi dan penting ini, Google akan menghubungi pelanggan melalui email. Selain itu, Google juga dapat menghubungi pelanggan untuk memberikan kontrak dukungan melalui saluran dukungan.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

Monitoring dan logging

Google Distributed Cloud menyertakan beberapa opsi untuk logging dan monitoring cluster, termasuk layanan terkelola berbasis cloud, alat open source, dan kompatibilitas yang divalidasi dengan solusi komersial pihak ketiga:

  • Cloud Logging dan Cloud Monitoring, diaktifkan oleh agen dalam cluster yang di-deploy dengan Google Distributed Cloud
  • Konfigurasi yang divalidasi dengan solusi pihak ketiga

Solusi logging apa pun yang Anda pilih berdasarkan persyaratan bisnis, sebaiknya log peristiwa dan pemberitahuan yang relevan ke depan ke layanan informasi keamanan dan manajemen peristiwa (SIEM) terpusat untuk pengelolaan insiden keamanan.

Untuk informasi selengkapnya, lihat dokumentasi berikut: