Melakukan hardening pada keamanan cluster Anda

Autopilot Standard

---

Halaman ini memandu Anda menerapkan praktik terbaik saat ini untuk 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.

Dokumen ini ditujukan untuk Spesialis keamanan yang menentukan, mengatur, dan menerapkan kebijakan dan prosedur untuk melindungi data organisasi dari akses yang tidak sah. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

Sebelum membaca halaman ini, pastikan Anda memahami hal-hal berikut:

• Ringkasan umum keamanan GKE
• Rekomendasi Tolok Ukur GKE CIS

Jika Anda membuat cluster baru di GKE, banyak perlindungan ini akan diaktifkan secara default. Jika Anda mengupgrade cluster yang ada, pastikan untuk meninjau panduan hardening ini secara berkala dan mengaktifkan fitur baru.

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

Banyak dari rekomendasi ini, serta kesalahan konfigurasi umum lainnya, dapat diperiksa secara otomatis menggunakan Analisis Kondisi Keamanan.

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.

Upgrade otomatis node diaktifkan secara default untuk cluster yang dibuat menggunakan Konsol 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 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

Secara default, bidang kontrol dan node cluster GKE memiliki alamat yang dirutekan di internet dan dapat diakses dari alamat IP apa pun.

Praktik terbaik:

Batasi eksposur node dan bidang kontrol cluster Anda ke internet.

Membatasi akses ke bidang kontrol

Untuk membatasi akses ke bidang kontrol cluster GKE, lihat Mengonfigurasi akses bidang kontrol. Berikut adalah opsi yang Anda miliki untuk perlindungan tingkat jaringan:

• Endpoint berbasis DNS diaktifkan (direkomendasikan): Anda dapat mengontrol siapa yang dapat mengakses endpoint berbasis DNS dengan Kontrol Layanan VPC. Kontrol Layanan VPC memungkinkan Anda menentukan satu parameter keamanan untuk semua Google API dalam project Anda dengan atribut berbasis konteks seperti asal jaringan. Setelan ini dapat dikontrol secara terpusat untuk project di semua Google API, sehingga mengurangi jumlah tempat yang harus Anda konfigurasi untuk aturan akses.

• Akses endpoint berbasis IP eksternal dan internal dinonaktifkan: Tindakan ini mencegah semua akses ke bidang kontrol melalui endpoint berbasis IP.

• Akses endpoint berbasis IP eksternal dinonaktifkan: Tindakan ini mencegah semua akses internet ke kedua bidang kontrol. 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 berbasis IP eksternal diaktifkan, jaringan yang diizinkan diaktifkan: 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 eksternal diaktifkan, jaringan yang diizinkan dinonaktifkan: Hal ini memungkinkan siapa saja di internet membuat koneksi jaringan ke bidang kontrol.

Jika menggunakan endpoint berbasis IP, sebaiknya cluster menggunakan jaringan yang diizinkan.

Dengan demikian, bidang kontrol dapat dijangkau oleh:

• CIDR yang diizinkan di jaringan yang diizinkan.
• Node dalam VPC cluster Anda.
• Alamat IP yang dicadangkan Google untuk tujuan pengelolaan cluster.

Membatasi akses ke node

Praktik terbaik:

Aktifkan node pribadi di cluster Anda untuk mencegah klien eksternal mengakses node.

Untuk menonaktifkan akses internet langsung ke node, tentukan opsi gcloud CLI --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.

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 untuk menggunakan Penyembunyian Metadata sehingga kedua pendekatan ini tidak kompatibel. Metadata sensitif yang dilindungi oleh Penyembunyian Metadata juga dilindungi oleh Workload Identity Federation for GKE.

Hardening isolasi 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.

Menonaktifkan port hanya baca kubelet yang tidak aman

Nonaktifkan port hanya baca kubelet dan alihkan workload apa pun yang menggunakan port 10255 untuk menggunakan port 10250 yang lebih aman.

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

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

Izin

Menggunakan 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

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

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

Praktik terbaik: Daripada menggunakan akun layanan default Compute Engine, buat akun layanan kustom untuk digunakan node Anda dan berikan hanya izin yang diperlukan GKE untuk menjalankan tugas sistem.

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

Untuk membuat akun layanan kustom dan memberinya peran yang diperlukan untuk GKE, selesaikan langkah-langkah berikut:

console

1. Di konsol Google Cloud, aktifkan Cloud Resource Manager API:

   Enable the API

2. Buka halaman Akun Layanan.

   Buka halaman Service accounts

3. Klik Buat akun layanan.
4. Masukkan nama untuk akun layanan. Kolom ID akun layanan secara otomatis menghasilkan ID unik untuk akun layanan berdasarkan namanya.
5. Klik Buat dan lanjutkan.
6. Di menu Select a role, pilih peran Kubernetes Engine Default Node Service Account.
7. Klik Done.

gcloud

1. Aktifkan Cloud Resource Manager API:

   gcloud services enable cloudresourcemanager.googleapis.com

2. Buat akun layanan:

   gcloud iam service-accounts create SERVICE_ACCOUNT_ID \
       --display-name=DISPLAY_NAME

   Ganti kode berikut:

   • SERVICE_ACCOUNT_ID: ID unik untuk akun layanan.
   • DISPLAY_NAME: nama tampilan untuk akun layanan.
3. Berikan peran Akun Layanan Node Default Kubernetes Engine (roles/container.defaultNodeServiceAccount) ke akun layanan:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_ID@PROJECT_ID.iam.gserviceaccount.com" \
       --role=roles/container.defaultNodeServiceAccount

   Ganti kode berikut:

   • PROJECT_ID: Project ID Google Cloud Anda.
   • SERVICE_ACCOUNT_ID: ID akun layanan yang Anda buat.

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.
2. Buat akun layanan:

   kubectl apply -f service-account.yaml

3. Terapkan peran roles/logging.logWriter ke akun layanan:
   1. Download resource berikut sebagai policy-logging.yaml.
      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]

      Ganti kode berikut:

      • [SA_NAME]: nama akun layanan.
      • [PROJECT_ID]: Project ID Google Cloud Anda.
   2. Terapkan peran ke akun layanan:

      kubectl apply -f policy-logging.yaml

4. Terapkan peran roles/monitoring.metricWriter ke akun layanan:
   1. 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]

      Ganti kode berikut:

      • [SA_NAME]: nama akun layanan.
      • [PROJECT_ID]: Project ID Google Cloud Anda.
   2. Terapkan peran ke akun layanan:

      kubectl apply -f policy-metrics-writer.yaml

5. Terapkan peran roles/monitoring.viewer ke akun layanan:
   1. Download resource berikut sebagai policy-monitoring.yaml.
      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]

      Ganti kode berikut:

      • [SA_NAME]: nama akun layanan.
      • [PROJECT_ID]: Project ID Google Cloud Anda.
   2. Terapkan peran ke akun layanan:

      kubectl apply -f policy-monitoring.yaml

6. Terapkan peran roles/autoscaling.metricsWriter ke akun layanan:
   1. Download resource berikut sebagai policy-autoscaling-metrics-writer.yaml.
      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]

      Ganti kode berikut:

      • [SA_NAME]: nama akun layanan.
      • [PROJECT_ID]: Project ID Google Cloud Anda.
   2. Terapkan peran ke akun layanan:

      kubectl apply -f policy-autoscaling-metrics-writer.yaml

Anda juga dapat menggunakan akun layanan ini untuk resource dalam project lain. Untuk mendapatkan petunjuk, lihat Mengaktifkan peniruan akun layanan di seluruh project.

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:

Perhatian: Container Registry tidak digunakan lagi dan dijadwalkan untuk dihentikan. Organisasi yang belum menggunakan Container Registry sebelum 8 Januari 2024 memiliki repositori gcr.io baru yang dihosting di Artifact Registry secara default. Mulai 15 Mei 2024, project Google Cloud yang sebelumnya tidak menggunakan Container Registry hanya akan mendukung hosting dan pengelolaan image untuk domain gcr.io di Artifact Registry.

Container Registry dijadwalkan untuk dihentikan pada 18 Maret 2025. Untuk mengetahui detail penghentian penggunaan, lihat Penghentian penggunaan Container Registry.

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

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 gcloud storage buckets add-iam-policy-binding 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 Standard yang ada, Anda kini dapat membuat node pool 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 node pool 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 Anda memiliki akses ke layanan Google Cloud lainnya, Anda harus menggunakan Workload Identity Federation untuk 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:

• Hanya aktifkan endpoint berbasis DNS untuk akses ke bidang kontrol.
• Mengonfigurasi jaringan yang diizinkan untuk membatasi akses ke rentang IP yang ditetapkan.
• Batasi akses ke bidang kontrol dan aktifkan node pribadi.

Jika tidak ada opsi yang 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.

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. Untuk menerapkan pendekatan umum guna membatasi traffic menggunakan kebijakan jaringan, ikuti panduan penerapan dari Blueprint Keamanan Enterprise GKE. 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 untuk GKE dan Google Distributed Cloud, sehingga mungkin lebih baik 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 kebijakan keamanan yang berguna.

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 mendapatkan akses ke library template batasan lengkap, paket kebijakan, dan integrasi dengan dasbor konsol Google Cloud untuk membantu mengamati dan mengelola cluster Anda. Paket kebijakan adalah praktik terbaik yang dapat Anda terapkan ke cluster, 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 dapat dicegah jika Anda menggunakan Workload Identity Federation untuk GKE atau Penyembunyian Metadata.

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 Observabilitas 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 \
    --location=LOCATION \
    --no-enable-service-externalips

Langkah berikutnya

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