Melakukan hardening pada keamanan cluster Anda

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 serta 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 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, sebagian besar perlindungan ini diaktifkan secara default. Jika Anda mengupgrade cluster yang ada, 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.

Mengupgrade infrastruktur GKE Anda secara rutin

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 Google Cloud konsol 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.

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 di project Anda dengan atribut yang sesuai konteks seperti asal jaringan. Setelan ini dapat dikontrol secara terpusat untuk project di semua Google API, sehingga mengurangi jumlah tempat yang harus Anda konfigurasi aturan aksesnya.

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

• Akses endpoint berbasis IP eksternal dinonaktifkan: Opsi 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: Konfigurasi 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

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.

Membatasi akses anonim ke endpoint cluster

Peningkatan keamanan ini membantu mengurangi risiko yang terkait dengan pengikatan peran yang tidak disengaja atau berbahaya dengan membatasi akses anonim ke endpoint cluster. Secara default, Kubernetes menetapkan pengguna system:anonymous dan grup system:unauthenticated ke permintaan anonim ke endpoint cluster. Jika pengguna atau grup tersebut memiliki izin di cluster melalui binding RBAC, hal ini dapat memberikan akses yang tidak diinginkan kepada pengguna anonim ke endpoint yang dapat digunakan untuk membahayakan keamanan layanan atau cluster itu sendiri.

Kecuali jika dibatasi secara eksplisit melalui binding RBAC, permintaan autentikasi anonim akan diterima untuk semua endpoint cluster. Di GKE versi 1.32.2-gke.1234000 dan yang lebih baru, saat membuat atau memperbarui cluster, Anda dapat membatasi kumpulan endpoint yang dapat dijangkau oleh permintaan anonim hanya ke tiga endpoint pemeriksaan kondisi server Kubernetes API: /healthz, /livez, dan /readyz. Akses anonim ke endpoint health check ini diperlukan untuk memverifikasi bahwa cluster beroperasi dengan benar.

Untuk membatasi akses anonim ke endpoint cluster, tentukan LIMITED untuk flag --anonymous-authentication-config dalam salah satu perintah gcloud CLI berikut:

• gcloud container clusters create
• gcloud container clusters create-auto
• gcloud container clusters update

Flag --anonymous-authentication-config mengambil nilai LIMITED atau ENABLED. Nilai defaultnya adalah ENABLED. Jika Anda menyetel nilai ke LIMITED, permintaan anonim akan ditolak selama autentikasi meskipun akses tersebut diizinkan oleh binding RBAC yang ada. Permintaan yang ditolak akan menampilkan status HTTP 401.

Seperti yang ditunjukkan dalam contoh berikut, Anda dapat menggunakan batasan kebijakan organisasi untuk menerapkan pembatasan akses ini di seluruh cluster dalam organisasi Anda:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Ganti ORGANIZATION_ID dengan ID organisasi Anda, seperti 123456789.

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

• Membatasi akses ke bidang kontrol
• Mengaktifkan node pribadi
• Menghindari peran dan grup default

Untuk mengetahui informasi tentang implementasi Kubernetes yang mendasari peningkatan ini, lihat Konfigurasi Pengautentikasi Anonim. Untuk mengetahui informasi selengkapnya tentang kebijakan role-based access control (RBAC), lihat Praktik terbaik untuk RBAC GKE.

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.

Menggunakan 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. Hal ini memungkinkan Anda 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.

Mengonfigurasi keamanan untuk 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 Google Cloud Akun Layanan dan Workload Identity khusus

Workload Identity Federation for GKE adalah cara yang direkomendasikan untuk melakukan autentikasi ke Google Cloud API.

Workload Identity Federation untuk 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 untuk 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 kubelet hanya baca 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 menyajikan API hanya baca menggunakan port 10255 yang tidak aman. Kubernetes tidak melakukan pemeriksaan autentikasi atau otorisasi apa pun di port ini. Kubelet melayani endpoint yang sama di port yang lebih aman dan diautentikasi 10250.

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

Memberikan izin akses

Bagian berikut menjelaskan cara memberikan akses ke infrastruktur GKE Anda.

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

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

Akun layanan yang terlampir ke node Anda hanya boleh digunakan oleh 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 memberikan peran yang diperlukan untuk GKE, selesaikan langkah-langkah berikut:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

Anda juga dapat menggunakan akun layanan ini untuk resource dalam project lain. Untuk mendapatkan petunjuk, lihat Mengaktifkan peniruan identitas 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 artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Jika menggunakan image pribadi di Container Registry, Anda juga perlu memberikan akses ke image tersebut:

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

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 iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

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 sudah 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:

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

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.

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

Melindungi data Anda dengan pengelolaan rahasia

Rekomendasi Tolok Ukur GKE CIS: 6.3.1. Pertimbangkan untuk mengenkripsi Secret Kubernetes menggunakan kunci yang dikelola di Cloud KMS

Gunakan alat pengelolaan rahasia eksternal untuk menyimpan data sensitif di luar cluster Anda, dan akses data tersebut secara terprogram.

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

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

Jika memungkinkan, gunakan layanan pengelolaan rahasia eksternal, seperti Secret Manager, untuk menyimpan data sensitif Anda di luar cluster. Buat Secret di cluster Anda hanya jika Anda tidak dapat memberikan data tersebut ke workload Anda dengan cara lain. Kami merekomendasikan metode berikut, sesuai urutan preferensi, untuk mengakses rahasia Anda:

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

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

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

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

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 melampirkan 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 memantau dan memelihara 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.

Meninjau opsi default 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

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