Melakukan hardening pada keamanan cluster Anda

Autopilot Standard

---

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.

Catatan: Jika Anda membuat cluster baru di GKE, sebagian besar perlindungan ini akan diaktifkan secara default. Jika mengupgrade cluster lama, pastikan untuk meninjau panduan hardening ini secara berkala dan mengaktifkan fitur-fitur baru.

Cluster yang dibuat dalam mode Autopilot akan menerapkan banyak fitur hardening GKE secara default.

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.

Note: Upgrade otomatis node diaktifkan secara default untuk cluster yang dibuat menggunakan Google Cloud sejak Juni 2019, dan untuk cluster yang dibuat menggunakan API mulai 11 November 2019.

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.

Saat Anda membuat aturan firewall, gunakan prinsip hak istimewa terendah guna membatasi akses hanya untuk tujuan yang diperlukan. Pastikan aturan firewall Anda tidak bentrok dengan aturan firewall default GKE jika memungkinkan.

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.

Catatan: Untuk mengedit kebijakan IAM, Anda harus mengaktifkan Cloud Resource Manager API di project Anda:

gcloud services enable cloudresourcemanager.googleapis.com

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.

1. Untuk membuat akun layanan, download resource berikut sebagai service-account.yaml.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMServiceAccount
   metadata:
     name: [SA_NAME]
   spec:
     displayName: [DISPLAY_NAME]

   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

2. Terapkan peran logging.logWriter ke akun layanan. Download resource berikut sebagai policy-logging.yaml. Ganti [SA_NAME] dan [PROJECT_ID] dengan informasi Anda sendiri.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-logging
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/logging.logWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-logging.yaml

3. Terapkan peran monitoring.metricWriter. Download resource berikut sebagai policy-metrics-writer.yaml. Ganti [SA_NAME] dan [PROJECT_ID] dengan informasi Anda sendiri.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-metrics-writer
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/monitoring.metricWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-metrics-writer.yaml

4. Terapkan peran monitoring.viewer. Download resource berikut sebagai policy-monitoring.yaml. Ganti [SA_NAME] dan [PROJECT_ID] dengan informasi Anda sendiri.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-monitoring
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/monitoring.viewer
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-monitoring.yaml

5. Terapkan peran autoscaling.metricsWriter. Download resource berikut sebagai policy-autoscaling-metrics-writer.yaml. Ganti [SA_NAME] dan [PROJECT_ID] dengan informasi Anda sendiri.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-autoscaling-metrics-writer
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/autoscaling.metricsWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   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.

Catatan: Langkah-langkah ini mengasumsikan bahwa Anda menggunakan Config Connector untuk mengelola repositori Artifact Registry. Jika repositori Anda tidak tersedia sebagai resource Config Connector, langkah-langkah ini tidak akan berfungsi.

1. Simpan manifes berikut sebagai policy-artifact-registry-reader.yaml:

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-artifact-registry-reader
   spec:
     member: serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com
     role: roles/artifactregistry.reader
     resourceRef:
       apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
       kind: ArtifactRegistryRepository
       name: REPOSITORY_NAME

   Ganti kode berikut:

   • SA_NAME: nama akun layanan IAM Anda.
   • PROJECT_ID: ID project Google Cloud Anda.
   • REPOSITORY_NAME: nama repositori Artifact Registry Anda.

2. 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 host gcr.io, atau
• STORAGE_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 host us.gcr.io
  • eu untuk registry di host eu.gcr.io
  • asia untuk registry di host asia.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.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

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.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

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:

1. Menggunakan Istio. Baca panduan Menginstal Istio di Google Kubernetes Engine jika Anda tertarik dengan load balancing, otorisasi layanan, throttling, kuota, metrik, dan banyak lagi.
2. 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:

1. 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 kolom rules di bagian spesifikasi MutatingWebhookConfiguration 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.

2. 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
   

3. 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.

4. 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

Catatan: Autentikasi dasar tidak digunakan lagi dan telah dihapus di GKE 1.19 dan yang lebih baru.

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.

Catatan: GKE memiliki Cloud Logging dan Cloud Monitoring yang dikonfigurasi secara default. Untuk mengetahui informasi selengkapnya, lihat Kemampuan observasi di GKE.

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.

Catatan: Secara default, UI web Kubernetes (Dasbor) tidak memiliki akses admin dan dinonaktifkan di GKE 1.10 dan yang lebih baru. Pada versi 1.15 dan yang lebih baru, add-on UI web Kubernetes KubernetesDashboard tidak didukung sebagai add-on terkelola di GKE. Jika masih ingin menjalankan UI web Kubernetes, Anda dapat menginstalnya sendiri dengan mengikuti dokumentasi UI web Kubernetes.

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.