Dengan cepatnya ritme pengembangan di Kubernetes, akan sering diperkenalkan fitur keamanan baru yang dapat Anda gunakan. Halaman ini memandu Anda menerapkan pedoman terbaru kami dalam melakukan hardening cluster Google Kubernetes Engine (GKE).
Panduan ini memprioritaskan mitigasi keamanan penting yang memerlukan tindakan dari pelanggan saat pembuatan cluster. Fitur yang kurang penting, setelan yang aman secara default, dan fitur yang dapat diaktifkan setelah pembuatan akan dibahas nanti dalam dokumen ini. Untuk membaca ringkasan umum tentang topik keamanan, lihat Ringkasan Keamanan.
Banyak dari rekomendasi ini, serta kesalahan konfigurasi umum lainnya, dapat diperiksa secara otomatis menggunakan Analisis Kondisi Keamanan.
Jika rekomendasi di bawah ini berkaitan dengan Rekomendasi Tolok Ukur GKE CIS, nomor rekomendasinya akan disebutkan.
Mengupgrade infrastruktur GKE Anda secara tepat waktu
Rekomendasi Tolok Ukur GKE CIS: 6.5.3. Pastikan upgrade otomatis Node diaktifkan untuk node GKE
Memastikan versi Kubernetes selalu yang terbaru adalah salah satu hal sederhana yang dapat Anda lakukan untuk meningkatkan keamanan. Kubernetes secara berkala memperkenalkan fitur keamanan baru dan memberikan patch keamanan.
Lihat buletin keamanan GKE untuk mengetahui informasi tentang patch keamanan.
Di Google Kubernetes Engine, bidang kontrol di-patch dan diupgrade secara otomatis untuk Anda. Upgrade otomatis node juga otomatis mengupgrade node di cluster Anda.
Jika Anda memilih untuk menonaktifkan upgrade otomatis node, sebaiknya upgrade setiap bulan sesuai jadwal Anda. Cluster lama harus mengaktifkan upgrade otomatis node dan mengikuti buletin keamanan GKE agar tidak ketinggalan patch penting.
Untuk mempelajari lebih lanjut, lihat Mengupgrade node secara otomatis.
Membatasi akses jaringan ke bidang kontrol dan node
Rekomendasi Tolok Ukur GKE CIS: 6.6.2. Sebaiknya gunakan cluster VPC native, 6.6.3. Pastikan Jaringan yang Diizinkan Master Diaktifkan, 6.6.4. Pastikan cluster dibuat dengan Endpoint Pribadi Diaktifkan dan Akses Publik Dinonaktifkan, dan 6.6.5. Pastikan cluster dibuat dengan Node Pribadi
Usahakan agar bidang kontrol dan node cluster Anda tidak terlalu terekspos ke internet. Setelan ini hanya dapat ditetapkan pada saat pembuatan cluster.
Secara default, bidang kontrol dan node cluster GKE memiliki alamat yang dirutekan di internet dan dapat diakses dari alamat IP apa pun.
Untuk mengetahui informasi tentang bidang kontrol cluster GKE, lihat Membuat cluster pribadi. Ada tiga ragam berbeda untuk cluster pribadi yang dapat memberikan perlindungan tingkat jaringan:
- Akses endpoint publik dinonaktifkan: Ini adalah opsi yang paling aman karena mencegah semua akses internet ke bidang kontrol dan node. Ini adalah pilihan yang tepat jika Anda telah mengonfigurasi jaringan lokal untuk terhubung ke Google Cloud menggunakan Cloud Interconnect dan Cloud VPN. Teknologi tersebut secara efektif menghubungkan jaringan perusahaan Anda ke VPC cloud.
- Akses endpoint publik diaktifkan, jaringan yang diizinkan diaktifkan (direkomendasikan): Opsi ini memberikan akses terbatas ke bidang kontrol melalui alamat IP sumber yang Anda tentukan. Ini adalah pilihan yang tepat jika Anda tidak memiliki infrastruktur VPN atau jika pengguna jarak jauh maupun kantor cabang masih terhubung melalui internet publik, bukan VPN perusahaan dan Cloud Interconnect atau Cloud VPN.
- Akses endpoint publik diaktifkan, jaringan yang diizinkan dinonaktifkan: Ini adalah ragam default yang memungkinkan siapa saja di internet membuat koneksi jaringan ke bidang kontrol.
Untuk menonaktifkan akses internet langsung ke node, tentukan gcloud CLIoption --enable-private-nodes saat pembuatan cluster.
Tindakan ini akan memberi tahu GKE untuk menyediakan node dengan alamat IP internal, yang artinya node tersebut tidak dapat dijangkau secara langsung melalui internet publik.
Sebaiknya cluster Anda menggunakan setidaknya jaringan yang diizinkan dan node pribadi. Dengan demikian, bidang kontrol dapat dijangkau oleh:
- CIDR yang diizinkan di jaringan yang diizinkan.
- Node dalam VPC cluster Anda.
- Tugas produksi internal Google yang mengelola bidang kontrol Anda.
Hal ini sesuai dengan flag gcloud
berikut pada saat pembuatan cluster:
--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks
Menggunakan aturan firewall hak istimewa terendah
Minimalkan risiko adanya akses yang tidak diinginkan dengan menggunakan prinsip hak istimewa terendah untuk aturan firewall
GKE membuat aturan firewall VPC default untuk mengaktifkan fungsionalitas sistem dan menerapkan praktik keamanan yang baik. Untuk mengetahui daftar lengkap aturan firewall yang dibuat otomatis, lihat Aturan firewall yang dibuat otomatis.
Aturan firewall default yang dibuat GKE memiliki
prioritas 1.000. Jika Anda membuat aturan firewall permisif dengan
prioritas yang lebih tinggi, misalnya aturan firewall allow-all
untuk
proses debug, cluster Anda berisiko mendapatkan akses yang tidak diinginkan.
Autentikasi grup
Rekomendasi Tolok Ukur GKE CIS: 6.8.3. Pertimbangkan untuk mengelola pengguna RBAC Kubernetes dengan Google Grup untuk RBAC
Sebaiknya gunakan grup untuk mengelola pengguna Anda. Dengan grup, identitas dapat dikontrol menggunakan Sistem pengelolaan identitas dan Administrator identitas Anda. Dengan menyesuaikan keanggotaan grup, Anda tidak perlu memperbarui konfigurasi RBAC setiap kali ada anggota yang ditambahkan atau dihapus dari grup.
Untuk mengelola izin pengguna menggunakan Google Grup, Anda harus mengaktifkan Google Grup untuk RBAC di cluster Anda. Ini akan memudahkan Anda dalam mengelola pengguna dengan izin yang sama, sekaligus memungkinkan administrator identitas mengelola pengguna secara terpusat dan konsisten.
Lihat Google Grup untuk RBAC dan dapatkan petunjuk cara mengaktifkan Google Grup untuk RBAC.
Pilihan node container
Bagian berikut menjelaskan pilihan konfigurasi node yang aman.
Mengaktifkan Node GKE yang Terlindungi
Rekomendasi Tolok Ukur GKE CIS: 6.5.5. Pastikan Node GKE yang Terlindungi diaktifkan
Node GKE yang Terlindungi memberikan identitas dan integritas node yang kuat serta dapat diverifikasi untuk meningkatkan keamanan node GKE. Sebaiknya selalu aktifkan node ini di semua cluster GKE.
Anda dapat mengaktifkan Node GKE yang Terlindungi saat membuat atau mengupdate cluster. Node GKE yang Terlindungi harus diaktifkan dengan booting aman. Booting aman tidak boleh digunakan jika Anda memerlukan modul kernel pihak ketiga yang tidak ditandatangani. Untuk petunjuk tentang cara mengaktifkan Node GKE yang Terlindungi dan booting aman dengan Node GKE yang Terlindungi, lihat Menggunakan Node GKE yang Terlindungi.
Memilih image node yang telah melalui proses hardening dengan runtime containerd
Container-Optimized OS dengan image
containerd (cos_containerd
) adalah
varian dari image Container-Optimized OS dengan containerd sebagai runtime container
utama yang terintegrasi langsung dengan Kubernetes.
containerd adalah komponen runtime inti dari Docker yang dapat memberikan fungsionalitas container inti untuk Antarmuka Runtime Container (CRI) Kubernetes. containerd jauh lebih sederhana dibandingkan daemon Docker yang lengkap, sehingga memiliki permukaan serangan yang lebih kecil.
Untuk menggunakan image cos_containerd
di cluster Anda, lihat Image containerd.
Image cos_containerd
adalah image yang disarankan untuk GKE
karena telah dibuat, dioptimalkan, dan di-hardening secara khusus untuk menjalankan container.
Mengaktifkan Workload Identity Federation untuk GKE
Rekomendasi Tolok Ukur GKE CIS: 6.2.2. Sebaiknya gunakan Akun Layanan Google Cloud dan Workload Identity khusus
Workload Identity Federation for GKE adalah cara yang direkomendasikan untuk melakukan autentikasi ke Google Cloud API.
Workload Identity Federation for GKE menggantikan kebutuhan penggunaan Metadata Concealment, sehingga kedua pendekatan ini tidak kompatibel. Metadata sensitif yang dilindungi oleh Metadata Concealment juga dilindungi oleh Workload Identity Federation for GKE.
Melakukan hardening pada pemisahan workload dengan GKE Sandbox
Rekomendasi Tolok Ukur GKE CIS: 6.10.4. Pertimbangkan penggunaan GKE Sandbox untuk melakukan hardening pada pemisahan workload, terutama untuk workload yang tidak tepercaya
GKE Sandbox memberikan lapisan keamanan tambahan 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. Untuk kerentanan container escape yang sebelumnya, lihat buletin keamanan. Jenis serangan ini memungkinkan penyerang mendapatkan akses ke VM host container, sehingga juga dapat mengakses container lain di VM yang sama. Sandbox seperti GKE Sandbox dapat membantu membatasi dampak serangan ini.
Sebaiknya pertimbangkan untuk men-sandbox workload dalam situasi berikut:
- Workload menjalankan kode tidak tepercaya
- Anda ingin membatasi dampak jika penyerang menyusupi container di Workload.
Pelajari cara menggunakan GKE Sandbox dalam panduan Melakukan hardening pada pemisahan workload dengan GKE Sandbox.
Mengaktifkan notifikasi buletin keamanan
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 memfilter jenis notifikasi yang ingin diterima.
Untuk informasi selengkapnya tentang cara menerima buletin keamanan menggunakan notifikasi cluster GKE, lihat Notifikasi cluster.
Izin
Gunakan akun layanan IAM dengan hak istimewa terendah
Rekomendasi Tolok Ukur GKE CIS: 6.2.1. Sebaiknya tidak menjalankan cluster GKE menggunakan akun layanan default Compute Engine
Setiap node GKE memiliki Akun Layanan Identity and Access Management (IAM) yang terkait dengannya. Secara default, node diberi akun layanan default Compute Engine, yang dapat Anda temukan dengan membuka bagian IAM di Konsol Google Cloud. Akun ini memiliki akses yang luas secara default, sehingga berguna untuk berbagai macam aplikasi, tetapi memiliki lebih banyak izin daripada yang diperlukan untuk menjalankan cluster Kubernetes Engine Anda. Anda harus membuat dan menggunakan akun layanan dengan hak istimewa minimal untuk digunakan node Anda, bukan akun layanan default Compute Engine.
Dengan diluncurkannya Workload Identity Federation for GKE, kami menyarankan kasus penggunaan yang lebih terbatas untuk akun layanan node. Kami memperkirakan akun layanan node akan digunakan oleh daemon sistem yang bertanggung jawab menjalankan logging, pemantauan, dan tugas serupa lainnya. Workload di Pod harus disediakan identitas dengan Workload Identity Federation untuk GKE.
GKE mengharuskan akun layanan setidaknya memiliki peran
monitoring.viewer
, monitoring.metricWriter
, logging.logWriter
,
stackdriver.resourceMetadata.writer
, dan autoscaling.metricsWriter
.
Baca selengkapnya tentang peran monitoring dan peran logging.
Perintah berikut membuat akun layanan IAM dengan izin minimum yang diperlukan untuk mengoperasikan GKE. Anda juga dapat menggunakan akun layanan untuk resource dalam project lain. Untuk mendapatkan petunjuk, lihat Mengaktifkan peniruan akun layanan di seluruh project.
gcloud
gcloud iam service-accounts create SA_NAME \
--display-name=DISPLAY_NAME
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/monitoring.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/stackdriver.resourceMetadata.writer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/autoscaling.metricsWriter
Ganti kode berikut:
SA_NAME
: nama akun layanan baru.DISPLAY_NAME
: nama tampilan untuk akun layanan baru, yang mempermudah identifikasi akun.PROJECT_ID
: project ID untuk project tempat Anda ingin membuat akun layanan baru.
Config Connector
Catatan: Langkah ini memerlukan Config Connector. Ikuti petunjuk penginstalan untuk menginstal Config Connector di cluster Anda.
Untuk membuat akun layanan, download resource berikut sebagai
service-account.yaml
.Ganti kode berikut:
SA_NAME
: nama akun layanan baru.DISPLAY_NAME
: nama tampilan untuk akun layanan baru, yang mempermudah identifikasi akun.
Kemudian, jalankan:
kubectl apply -f service-account.yaml
Terapkan peran
logging.logWriter
ke akun layanan. Download resource berikut sebagaipolicy-logging.yaml
. Ganti[SA_NAME]
dan[PROJECT_ID]
dengan informasi Anda sendiri.kubectl apply -f policy-logging.yaml
Terapkan peran
monitoring.metricWriter
. Download resource berikut sebagaipolicy-metrics-writer.yaml
. Ganti[SA_NAME]
dan[PROJECT_ID]
dengan informasi Anda sendiri.kubectl apply -f policy-metrics-writer.yaml
Terapkan peran
monitoring.viewer
. Download resource berikut sebagaipolicy-monitoring.yaml
. Ganti[SA_NAME]
dan[PROJECT_ID]
dengan informasi Anda sendiri.kubectl apply -f policy-monitoring.yaml
Terapkan peran
autoscaling.metricsWriter
. Download resource berikut sebagaipolicy-autoscaling-metrics-writer.yaml
. Ganti[SA_NAME]
dan[PROJECT_ID]
dengan informasi Anda sendiri.kubectl apply -f policy-autoscaling-metrics-writer.yaml
Memberikan akses ke repositori image pribadi
Untuk menggunakan image pribadi di Artifact Registry, berikan
peran Pembaca Artifact Registry
(roles/artifactregistry.reader
) ke akun layanan.
gcloud
gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
--member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--role=roles/artifactregistry.reader
Ganti REPOSITORY_NAME
dengan nama
repositori Artifact Registry Anda.
Config Connector
Catatan: Langkah ini memerlukan Config Connector. Ikuti petunjuk penginstalan untuk menginstal Config Connector di cluster Anda.
Simpan manifes berikut sebagai
policy-artifact-registry-reader.yaml
:Ganti kode berikut:
- SA_NAME: nama akun layanan IAM Anda.
- PROJECT_ID: ID project Google Cloud Anda.
- REPOSITORY_NAME: nama repositori Artifact Registry Anda.
Berikan peran Pembaca Artifact Registry ke akun layanan:
kubectl apply -f policy-artifact-registry-reader.yaml
Jika menggunakan image pribadi di Container Registry, Anda juga perlu memberikan akses ke image tersebut:
gsutil
gsutil iam ch \
serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
gs://BUCKET_NAME
Bucket yang menyimpan image Anda memiliki nama BUCKET_NAME
dengan format:
artifacts.PROJECT_ID.appspot.com
untuk image yang dikirim ke registry di hostgcr.io
, atauSTORAGE_REGION.artifacts.PROJECT_ID.appspot.com
Ganti kode berikut:
PROJECT_ID
: project ID untuk Konsol Google Cloud Anda.STORAGE_REGION
: lokasi bucket penyimpanan:us
untuk registry di hostus.gcr.io
eu
untuk registry di hosteu.gcr.io
asia
untuk registry di hostasia.gcr.io
Lihat dokumentasi gsutil iam
untuk informasi selengkapnya tentang perintah tersebut.
Config Connector
Catatan: Langkah ini memerlukan Config Connector. Ikuti petunjuk penginstalan untuk menginstal Config Connector di cluster Anda.
Terapkan peran storage.objectViewer
ke akun layanan Anda. Download resource berikut sebagai policy-object-viewer.yaml
. Ganti [SA_NAME]
dan [PROJECT_ID]
dengan informasi Anda sendiri.
kubectl apply -f policy-object-viewer.yaml
Jika ingin pengguna manusia lain memiliki kemampuan membuat cluster atau node pool baru dengan akun layanan ini, Anda harus memberi mereka peran Service Account User di akun layanan ini:
gcloud
gcloud iam service-accounts add-iam-policy-binding \ SA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --member=user:USER \ --role=roles/iam.serviceAccountUser
Config Connector
Catatan: Langkah ini memerlukan Config Connector. Ikuti petunjuk penginstalan untuk menginstal Config Connector di cluster Anda.
Terapkan peran iam.serviceAccountUser
ke akun layanan Anda. Download
resource berikut sebagai policy-service-account-user.yaml
. Ganti [SA_NAME]
dan [PROJECT_ID]
dengan informasi Anda sendiri.
kubectl apply -f policy-service-account-user.yaml
Untuk cluster Standar yang sudah ada, Anda kini dapat membuat kumpulan node baru dengan akun layanan baru ini. Untuk cluster Autopilot, Anda harus membuat cluster baru dengan akun layanan. Untuk mengetahui petunjuknya, lihat Membuat cluster Autopilot.
Buat kumpulan node yang menggunakan akun layanan baru:
gcloud container node-pools create NODE_POOL_NAME \ --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --cluster=CLUSTER_NAME
Jika ingin cluster GKE memiliki akses ke layanan Google Cloud lainnya, Anda harus menggunakan Workload Identity Federation for GKE.
Membatasi akses ke penemuan API cluster
Secara default, Kubernetes mem-bootstrap cluster dengan serangkaian penemuan ClusterRoleBinding permisif yang memberikan akses luas ke informasi terkait API pada cluster, termasuk API dari CustomResourceDefinitions.
Pengguna harus mengetahui bahwa Grup system:authenticated
yang termasuk
dalam subjek ClusterRoleBinding system:discovery
dan system:basic-user
dapat mencakup semua pengguna terautentikasi (termasuk pengguna dengan Akun Google),
dan tidak merepresentasikan tingkat keamanan yang berarti untuk cluster di
GKE. Untuk informasi selengkapnya, lihat
Menghindari peran dan grup default.
Pengguna yang ingin melakukan hardening untuk discovery API pada cluster harus mempertimbangkan satu atau beberapa hal berikut:
- Mengonfigurasi Jaringan yang diizinkan untuk membatasi akses ke rentang IP yang ditetapkan.
- Menyiapkan cluster pribadi untuk membatasi akses ke VPC.
Jika tidak satu pun dari opsi tersebut sesuai dengan kasus penggunaan GKE Anda, sebaiknya perlakukan semua informasi penemuan API (yaitu skema CustomResources, definisi APIService, dan informasi penemuan yang dihosting oleh server extension API) sebagai informasi yang terungkap secara publik.
Kedua opsi tersebut memungkinkan akses ke alamat IP dari server API melalui Cloud Run dan Cloud Functions. Akses ini akan dihapus, jadi jadi jangan mengandalkan layanan ini untuk berkomunikasi dengan server API Anda. Untuk informasi selengkapnya, lihat postingan blog Google Cloud.
Menggunakan namespace dan RBAC untuk membatasi akses ke resource cluster
Rekomendasi Tolok Ukur GKE CIS: 5.6.1. Membuat batas administratif antar-resource menggunakan namespace
Berikan tim Anda akses hak istimewa terendah ke Kubernetes dengan membuat namespace atau cluster terpisah untuk setiap tim dan 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 dilakukan pengguna terhadap cluster dan tentukan izin yang diperlukan untuk melakukan setiap tugas.
Untuk informasi selengkapnya tentang cara membuat namespace, lihat dokumentasi Kubernetes. Untuk praktik terbaik dalam merencanakan konfigurasi RBAC, lihat Praktik terbaik untuk GKE RBAC.
IAM and Role-based access control (RBAC) berfungsi bersama, dan entity harus memiliki izin yang memadai di kedua level agar dapat berfungsi dengan resource di cluster Anda.
Tetapkan peran IAM yang sesuai untuk GKE ke grup dan pengguna agar dapat memberikan izin di level project dan gunakan RBAC untuk memberikan izin pada level cluster dan namespace. Untuk mempelajari lebih lanjut, lihat Kontrol akses.
Anda dapat menggunakan izin IAM dan RBAC beserta namespace untuk membatasi interaksi pengguna dengan resource cluster di konsol Google Cloud. Untuk informasi selengkapnya, lihat Mengaktifkan akses dan melihat resource cluster berdasarkan namespace.Membatasi traffic di antara Pod dengan kebijakan jaringan
Rekomendasi Tolok Ukur GKE CIS: 6.6.7. Pastikan Kebijakan Jaringan Diaktifkan dan ditetapkan sebagaimana mestinya
Secara default, semua Pod dalam cluster dapat saling berkomunikasi. Anda harus mengontrol komunikasi antar-Pod sesuai dengan kebutuhan workload.
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. Dua cara yang direkomendasikan untuk mengontrol traffic adalah:
- Menggunakan Istio. Baca panduan Menginstal Istio di Google Kubernetes Engine jika Anda tertarik dengan load balancing, otorisasi layanan, throttling, kuota, metrik, dan banyak lagi.
- Menggunakan kebijakan jaringan Kubernetes. Baca panduan Membuat kebijakan jaringan cluster. Pilih cara ini jika Anda memerlukan fungsionalitas kontrol akses dasar yang diekspos oleh Kubernetes. Agar dapat menerapkan pendekatan umum untuk membatasi traffic menggunakan kebijakan jaringan, ikuti panduan penerapan dari Blueprint Keamanan GKE Enterprise. Selain itu, dokumentasi Kubernetes memiliki panduan lengkap untuk memudahkan deployment nginx. Sebaiknya gunakan logging kebijakan jaringan untuk memastikan bahwa kebijakan jaringan Anda berfungsi sesuai harapan.
Istio dan kebijakan jaringan dapat digunakan bersama jika diperlukan.
Pengelolaan secret
Rekomendasi Tolok Ukur GKE CIS: 6.3.1. Pertimbangkan untuk mengenkripsi Secret Kubernetes menggunakan kunci yang dikelola di Cloud KMS
Anda harus memberikan lapisan perlindungan tambahan untuk data sensitif, seperti secret, yang disimpan di etcd. Untuk melakukannya, Anda perlu mengonfigurasi secret manager yang terintegrasi dengan cluster GKE. Beberapa solusi akan berfungsi di GKE dan di GKE pada VMware, sehingga mungkin lebih diminati jika Anda menjalankan workload di beberapa lingkungan. Jika ingin menggunakan secret manager eksternal seperti HashiCorp Vault, Anda harus menyiapkannya sebelum membuat cluster.
Anda memiliki beberapa opsi untuk pengelolaan secret.
- Anda dapat menggunakan secret Kubernetes secara native di GKE. Jika perlu, Anda dapat mengenkripsi secret Kubernetes pada lapisan aplikasi dengan kunci yang dikelola menggunakan Enkripsi secret lapisan aplikasi.
- Anda dapat menggunakan secret manager seperti HashiCorp Vault. Saat dijalankan dalam mode HA yang telah melalui proses hardening, opsi ini akan memberikan cara pengelolaan secret yang konsisten dan siap produksi. Anda dapat melakukan autentikasi ke HashiCorp Vault menggunakan akun layanan Kubernetes atau akun layanan Google Cloud. Untuk mempelajari lebih lanjut penggunaan GKE dengan Vault, lihat Menjalankan dan menghubungkan ke HashiCorp Vault di Kubernetes.
VM GKE secara default dienkripsi pada lapisan penyimpanan, yang mencakup etcd.
Menggunakan pengontrol penerimaan untuk menerapkan kebijakan
Pengontrol penerimaan adalah plugin yang mengatur dan menerapkan cara penggunaan cluster. Plugin ini harus diaktifkan agar dapat menggunakan beberapa fitur keamanan lanjutan di Kubernetes, sehingga merupakan bagian penting dari pendekatan pertahanan yang mendalam untuk melakukan hardening pada cluster Anda
Secara default, Pod di Kubernetes dapat beroperasi dengan kemampuan melebihi yang dibutuhkan. Anda harus membatasi kemampuan Pod hanya pada level yang diperlukan untuk workload yang bersangkutan.
Kubernetes mendukung banyak kontrol untuk membatasi Pod agar dijalankan hanya dengan kemampuan yang diberikan secara eksplisit. Misalnya, Pengontrol Kebijakan yang tersedia untuk cluster dalam fleet. Kubernetes juga memiliki pengontrol penerimaan PodSecurity bawaan yang memungkinkan Anda menerapkan Standar Keamanan Pod untuk tiap-tiap cluster.
Pengontrol Kebijakan adalah fitur GKE Enterprise yang memungkinkan Anda menerapkan dan memvalidasi keamanan pada cluster GKE dalam skala besar menggunakan kebijakan deklaratif. Guna mempelajari cara menggunakan Pengontrol Kebijakan untuk menerapkan kontrol deklaratif pada cluster GKE, lihat Menginstal Pengontrol Kebijakan.
Pengontrol penerimaan PodSecurity memungkinkan Anda menerapkan kebijakan bawaan di namespace tertentu atau di seluruh cluster. Kebijakan tersebut sesuai dengan Standar Keamanan Pod yang berbeda.
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 tersebut. Hal ini diperlukan agar
pengontrol dapat membuat perubahan pada cluster, seperti menerapkan upgrade
cluster. Misalnya, jika Anda men-deploy kebijakan NoUpdateServiceAccount
di
GKE, Anda harus menetapkan parameter berikut di Constraint
:
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:addon-manager
Membatasi penggunaan jenis volume gcePersistentDisk
yang tidak digunakan lagi
Jenis volume gcePersistentDisk
yang tidak digunakan lagi memungkinkan Anda memasang persistent disk
Compute Engine ke Pod. Sebaiknya batasi penggunaan
jenis volume gcePersistentDisk
di workload Anda. GKE tidak
melakukan pemeriksaan otorisasi IAM pada Pod saat memasang
jenis volume ini, meskipun Google Cloud melakukan pemeriksaan otorisasi saat
memasang disk ke VM dasar. Dengan demikian, jika penyerang memiliki kemampuan
untuk membuat Pod dalam namespace, mereka dapat mengakses konten
persistent disk Compute Engine di project Google Cloud Anda.
Untuk mengakses dan menggunakan persistent disk Compute Engine, sebaiknya gunakan
PersistentVolumes dan
PersistentVolumeClaims. Terapkan kebijakan keamanan di cluster Anda yang
mencegah penggunaan jenis volume gcePersistentDisk
.
Untuk mencegah penggunaan jenis volume gcePersistentDisk
, terapkan kebijakan
Dasar atau Terbatas dengan
Pengontrol penerimaan PodSecurity, atau tentukan batasan khusus di
Pengontrol Kebijakan
atau di pengontrol penerimaan Pemilah Komunikasi.
Agar dapat menentukan batasan khusus untuk membatasi jenis volume ini, lakukan langkah berikut:
Instal pengontrol penerimaan berbasis kebijakan seperti Pengontrol Kebijakan atau OPA Pemilah Komunikasi.
Pengontrol Kebijakan
Instal Pengontrol Kebijakan di cluster Anda.
Pengontrol Kebijakan adalah fitur berbayar untuk pengguna GKE. Pengontrol Kebijakan didasarkan pada Gatekeeper open source, tetapi Anda juga akan mendapatkan akses ke library template batasan lengkap, paket kebijakan, dan integrasi dengan dasbor Google Cloud Console untuk membantu mengamati dan memelihara cluster Anda. Paket kebijakan adalah praktik terbaik opini yang dapat diterapkan ke cluster Anda, termasuk paket berdasarkan rekomendasi seperti CIS Kubernetes Benchmark.
Pemilah Komunikasi
Instal Pemilah Komunikasi di cluster Anda.
Untuk cluster Autopilot, buka manifes
gatekeeper.yaml
Pemilah Komunikasi di editor teks. Edit kolomrules
di bagian spesifikasiMutatingWebhookConfiguration
untuk mengubah karakter pengganti (*
) dengan grup API dan nama resource tertentu, seperti dalam contoh berikut:apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration ... webhooks: - admissionReviewVersions: - v1 - v1beta1 ... rules: - apiGroups: - core - batch - apps apiVersions: - '*' operations: - CREATE - UPDATE resources: - Pod - Deployment - Job - Volume - Container - StatefulSet - StorageClass - Secret - ConfigMap sideEffects: None timeoutSeconds: 1
Terapkan manifes
gatekeeper.yaml
yang telah diperbarui ke cluster Autopilot untuk menginstal Pemilah Komunikasi. Penerapan ini diperlukan karena Autopilot memiliki langkah keamanan bawaan yang tidak mengizinkan penggunaan karakter pengganti dalam webhook penerimaan pemutasi objek.Deploy ConstraintTemplate bawaan untuk Jenis Volume Kebijakan Keamanan Pod:
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml
Simpan Batasan berikut dengan daftar jenis volume yang diizinkan sebagai
constraint.yaml
:apiVersion: constraints.gatekeeper.sh/v1beta1 kind: k8sPSPVolumeTypes metadata: name: nogcepersistentdisk spec: match: kinds: - apiGroups: [""] kinds: ["Pods"] parameters: volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]
Batasan ini membatasi volume pada daftar di kolom
spec.parameters.volumes
.Men-deploy batasan:
kubectl apply -f constraint.yaml
Memantau konfigurasi cluster Anda
Anda harus mengaudit konfigurasi cluster untuk menemukan penyimpangan dari setelan yang ditentukan.
Kebanyakan rekomendasi yang dicakup dalam panduan hardening ini, serta kesalahan konfigurasi umum lainnya, dapat diperiksa secara otomatis menggunakan Analisis Kondisi Analytics.
Default yang aman
Bagian berikut menjelaskan opsi yang secara default dikonfigurasi dengan aman di cluster baru. Anda harus memastikan cluster yang ada sudah dikonfigurasi dengan aman.
Melindungi metadata node
Rekomendasi Tolok Ukur GKE CIS: 6.4.1. Pastikan API metadata instance Compute Engine lama Dinonaktifkan, dan 6.4.2. Pastikan Server Metadata GKE Diaktifkan
Endpoint server metadata Compute Engine v0.1
dan v1beta1
tidak digunakan lagi
dan dinonaktifkan pada 30 September 2020. Endpoint ini tidak menerapkan header kueri metadata.
Untuk jadwal penonaktifan, lihat penghentian penggunaan endpoint server metadata v0.1
dan v1beta1
.
Beberapa praktik serangan terhadap Kubernetes mengandalkan akses ke server metadata VM untuk mengekstrak kredensial. Serangan ini akan diblokir jika Anda menggunakan Workload Identity Federation for GKE atau Metadata Concealment.
Membiarkan metode autentikasi klien lama dinonaktifkan
Rekomendasi Tolok Ukur GKE CIS: 6.8.1. Pastikan Autentikasi Dasar yang menggunakan sandi statis Dinonaktifkan, dan 6.8.2. Pastikan autentikasi menggunakan Sertifikat Klien Dinonaktifkan
Terdapat beberapa metode untuk mengautentikasi
ke server Kubernetes API. Di GKE, metode yang didukung
adalah token pemilik akun layanan, token OAuth, dan sertifikat klien x509.
GKE mengelola autentikasi dengan gcloud
untuk Anda menggunakan
metode token OAuth, menyiapkan konfigurasi Kubernetes, mendapatkan token
akses, dan terus memperbaruinya.
Sebelum OAuth diintegrasikan ke GKE, hanya ada metode autentikasi dengan sertifikat x509 atau kata sandi statis sekali pakai, tetapi keduanya tidak lagi direkomendasikan dan harus dinonaktifkan. Kedua metode tersebut memperluas permukaan serangan untuk penyusupan cluster dan telah dinonaktifkan secara default sejak GKE versi 1.12. Jika masih menggunakan metode autentikasi lama, sebaiknya Anda menonaktifkan metode tersebut. Autentikasi dengan sandi statis tidak digunakan lagi dan telah dihapus sejak GKE versi 1.19.
Cluster yang ada harus beralih ke OAuth. Jika kredensial dengan masa berlaku panjang dibutuhkan oleh sistem di luar cluster, sebaiknya buat akun layanan Google atau akun layanan Kubernetes dengan hak istimewa yang diperlukan dan ekspor kuncinya.
Untuk memperbarui cluster yang ada dan menghapus sandi statis, lihat Menonaktifkan autentikasi dengan sandi statis.
Saat ini, tidak memungkinkan untuk menghapus sertifikat klien keluaran sebelumnya dari cluster yang ada, tetapi sertifikat tersebut tidak akan memiliki izin jika RBAC diaktifkan dan ABAC dinonaktifkan.
Membiarkan Cloud Logging tetap aktif
Rekomendasi Tolok Ukur GKE CIS: 6.7.1. Pastikan Logging dan Monitoring Stackdriver Kubernetes Diaktifkan
Untuk mengurangi overhead operasional dan mempertahankan tampilan gabungan dari log Anda, terapkan strategi logging yang konsisten di mana pun cluster Anda di-deploy. Cluster GKE Enterprise terintegrasi dengan Cloud Logging secara default dan harus tetap dikonfigurasi.
Semua cluster GKE memiliki logging audit Kubernetes diaktifkan secara default, yang menyimpan kumpulan data kronologis terkait panggilan yang 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.
Cluster GKE mengintegrasikan Audit Logging Kubernetes dengan Cloud Audit Logs dan Cloud Logging. Log dapat dirutekan dari Cloud Logging ke sistem logging Anda sendiri.
Membiarkan UI web Kubernetes (Dasbor) dinonaktifkan
Rekomendasi Tolok Ukur GKE CIS: 6.10.1. Pastikan UI web Kubernetes Dinonaktifkan
Jangan mengaktifkan UI web (Dasbor) Kubernetes saat menjalankan GKE.
UI web Kubernetes (Dasbor) didukung oleh Akun Layanan Kubernetes dengan hak istimewa tinggi. Konsol Google Cloud menyediakan banyak fungsi yang sama, sehingga Anda tidak memerlukan izin ini.
Untuk menonaktifkan UI web Kubernetes:
gcloud container clusters update CLUSTER_NAME \ --update-addons=KubernetesDashboard=DISABLED
Membiarkan ABAC dinonaktifkan
Rekomendasi Tolok Ukur GKE CIS: 6.8.4. Pastikan Otorisasi Lama (ABAC) Dinonaktifkan
Anda harus menonaktifkan Kontrol Akses Berbasis Atribut (ABAC), dan menggunakan Kontrol Akses Berbasis Peran (RBAC) di GKE.
Secara default, ABAC dinonaktifkan untuk cluster yang dibuat menggunakan GKE versi 1.8 dan yang lebih baru. Di Kubernetes, RBAC digunakan untuk memberikan izin ke resource di level cluster dan namespace. RBAC memungkinkan Anda menentukan peran dengan aturan yang berisi serangkaian izin. RBAC memiliki keunggulan signifikan dari segi keamanan dibandingkan ABAC.
Jika Anda masih mengandalkan ABAC, tinjau terlebih dahulu Prasyarat untuk menggunakan RBAC. Jika Anda mengupgrade cluster dari versi lama dan menggunakan ABAC, sebaiknya perbarui konfigurasi kontrol akses:
gcloud container clusters update CLUSTER_NAME \ --no-enable-legacy-authorization
Untuk membuat cluster baru dengan rekomendasi di atas:
gcloud container clusters create CLUSTER_NAME \ --no-enable-legacy-authorization
Membiarkan pengontrol penerimaan DenyServiceExternalIPs
tetap aktif
Jangan nonaktifkan pengontrol penerimaan DenyServiceExternalIPs
.
Pengontrol penerimaan
DenyServiceExternalIPs
mencegah Service agar tidak menggunakan ExternalIP dan meminimalkan risiko
kerentanan keamanan yang diketahui.
Pengontrol penerimaan DenyServiceExternalIPs
diaktifkan secara default pada cluster baru
yang dibuat di GKE versi 1.21 dan yang lebih baru. Untuk cluster
yang diupgrade ke GKE versi 1.21 dan yang lebih baru, Anda dapat mengaktifkan
pengontrol penerimaan menggunakan perintah berikut:
gcloud beta container clusters update CLUSTER_NAME \
--no-enable-service-externalips
Langkah selanjutnya
- Mempelajari lebih lanjut keamanan GKE di Ringkasan Keamanan.
- Memastikan pemahaman Anda tentang model tanggung jawab bersama GKE.
- Memahami cara menerapkan Tolok Ukur GKE CIS ke cluster Anda.
- Mempelajari lebih lanjut kontrol akses di GKE.
- Membaca ringkasan jaringan GKE.
- Membaca ringkasan multi-tenancy GKE.