Produk yang dijelaskan dalam dokumentasi ini, GKE di Azure, kini dalam mode pemeliharaan dan akan dihentikan pada 17 Maret 2027.

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan keamanan

Halaman ini menjelaskan arsitektur keamanan GKE di Azure, termasuk enkripsi dan konfigurasi node.

Cluster GKE menawarkan fitur untuk membantu mengamankan workload Anda, termasuk konten image container, runtime container, jaringan cluster, dan akses ke server API cluster.

Saat menggunakan cluster GKE, Anda setuju untuk memikul tanggung jawab tertentu atas cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Tanggung jawab bersama cluster GKE.

Enkripsi data dalam penyimpanan

Enkripsi data dalam penyimpanan adalah enkripsi data yang disimpan, yang berbeda dengan data dalam transit. Secara default, GKE di Azure mengenkripsi data dalam etcd dan volume penyimpanan dalam penyimpanan menggunakan kunci yang dikelola platform Azure.

Cluster GKE di Azure menyimpan data dalam volume Disk Azure. Volume ini selalu dienkripsi dalam penyimpanan menggunakan kunci Azure Key Vault. Saat membuat cluster dan node pool, Anda dapat memberikan Kunci Keyvault yang Dikelola Pelanggan untuk mengenkripsi volume Disk yang mendasari cluster. Jika Anda tidak menentukan kunci, Azure akan menggunakan kunci yang dikelola Azure secara default dalam region Azure tempat cluster berjalan.

Selain itu, semua cluster GKE mengaktifkan Enkripsi Secret Lapisan Aplikasi untuk data sensitif, seperti objek Secret Kubernetes, yang disimpan di etcd. Meskipun penyerang mendapatkan akses ke volume dasar tempat data etcd disimpan, data ini dienkripsi.

Saat membuat cluster, Anda dapat memberikan kunci Azure Key Vault dalam parameter --database-encryption-kms-key-arn. Kunci ini digunakan untuk mengenkripsi data aplikasi Anda. Jika Anda tidak memberikan kunci selama pembuatan cluster, GKE di Azure akan membuat kunci untuk cluster Anda secara otomatis. Kolom resource ini tidak dapat diubah dan tidak dapat dimodifikasi setelah cluster dibuat.

Anda juga dapat membuat kunci Key Vault secara manual atau membawa kunci Anda sendiri (BYOK) dengan modul keamanan hardware (HSM). Untuk mengetahui informasi selengkapnya, lihat Membawa kunci Anda sendiri.

Cara kerja enkripsi tingkat aplikasi

Kubernetes menawarkan enkripsi tingkat aplikasi dengan teknik yang dikenal sebagai enkripsi menyeluruh. Kunci lokal, yang biasanya disebut kunci enkripsi data (DEK), digunakan untuk mengenkripsi Secret. DEK itu sendiri kemudian dienkripsi dengan kunci kedua yang disebut kunci enkripsi kunci (KEK). KEK tidak disimpan oleh Kubernetes. Saat Anda membuat Secret Kubernetes baru, cluster Anda akan melakukan hal berikut:

Server Kubernetes API menghasilkan DEK unik untuk Secret menggunakan generator angka acak.
Server Kubernetes API mengenkripsi Secret secara lokal dengan DEK.
Server Kubernetes API mengirimkan DEK ke Azure Key Vault untuk dienkripsi.
Azure Key Vault menggunakan KEK yang telah dibuat sebelumnya untuk mengenkripsi DEK dan menampilkan DEK yang dienkripsi ke plugin Azure Key Vault server Kubernetes API.
Server Kubernetes API menyimpan Secret terenkripsi dan DEK terenkripsi ke etcd. DEK teks biasa tidak disimpan ke disk.
Server Kubernetes API membuat entri cache dalam memori untuk memetakan DEK terenkripsi ke DEK teks biasa. Hal ini memungkinkan Server API mendekripsi Secret yang baru diakses tanpa mengkueri Azure Key Vault.

Saat klien meminta Secret dari server Kubernetes API, inilah yang akan terjadi:

Server Kubernetes API mengambil Secret terenkripsi dan DEK terenkripsi dari etcd.
Server Kubernetes API memeriksa cache untuk entri peta yang ada dan jika ditemukan, mendekripsi Secret dengannya.
Jika tidak ada entri cache yang cocok, server API akan mengirimkan DEK ke Azure Key Vault untuk dekripsi menggunakan KEK. DEK yang didekripsi kemudian digunakan untuk mendekripsi Secret.
Terakhir, server Kubernetes API menampilkan Secret yang didekripsi kepada klien.

Enkripsi Konfigurasi dengan Firewall Key Vault

Jika Anda meneruskan kunci publik untuk enkripsi, akun utama layanan tidak memerlukan izin untuk mengenkripsi, tetapi memerlukan izin untuk mengelola penetapan peran. Cara termudah untuk melakukannya adalah dengan menetapkan peran bawaan Azure User Access Administrator ke akun utama layanan Anda.

Untuk lebih mengamankan Azure Key Vault, Anda dapat mengaktifkan firewall Azure Key Vault. GKE di Azure kemudian dapat menggunakan kunci publik untuk enkripsi dan menghindari akses jaringan ke key vault.

Untuk mengonfigurasi firewall, Anda mendownload Kunci Key Vault dengan Azure CLI. Anda meneruskan kunci ke --config-encryption-public-key saat membuat cluster dengan Google Cloud CLI.

Anda tetap perlu mengaktifkan endpoint layanan untuk Key Vault di semua subnet yang digunakan untuk cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Endpoint layanan jaringan virtual untuk Azure Key Vault.

Rotasi Kunci

Berbeda dengan rotasi sertifikat, rotasi kunci adalah tindakan mengubah materi kriptografi pokok yang terdapat dalam kunci enkripsi kunci (KEK). Rotasi kunci dapat dipicu secara otomatis sebagai bagian dari rotasi terjadwal, atau secara manual, biasanya setelah terjadi insiden keamanan yang menyebabkan kunci mungkin telah disusupi. Rotasi kunci hanya mengganti satu kolom dalam kunci yang berisi data kunci enkripsi/dekripsi mentah.

Untuk mengetahui informasi selengkapnya, lihat Rotasi kunci.

Kepercayaan cluster

Semua komunikasi cluster menggunakan Transport Layer Security (TLS). Setiap cluster disediakan dengan certificate authority (CA) root utama yang ditandatangani sendiri berikut:

CA root cluster digunakan untuk memvalidasi permintaan yang dikirim ke server API.
CA root etcd digunakan untuk memvalidasi permintaan yang dikirim ke replika etcd.

Setiap cluster memiliki CA root yang unik. Jika CA di satu cluster disusupi, CA di cluster lain tidak akan terpengaruh. Semua CA root memiliki periode validitas 30 tahun.

Keamanan node

GKE di Azure men-deploy workload Anda ke node pool instance VM Azure. Bagian berikut menjelaskan fitur keamanan node.

Ubuntu

Node Anda menjalankan versi OS Ubuntu yang dioptimalkan untuk menjalankan bidang kontrol dan node Kubernetes. Untuk mengetahui informasi selengkapnya, lihat fitur keamanan dalam dokumentasi Ubuntu.

Cluster GKE menerapkan beberapa fitur keamanan, termasuk berikut ini:

Set paket yang dioptimalkan
Google Cloud-tailored Linux kernel
Akun pengguna terbatas dan login root dinonaktifkan

Panduan keamanan tambahan tersedia untuk Ubuntu, seperti berikut:

Mengamankan workload Anda

Dengan Kubernetes, pengguna dapat menyediakan, menskalakan, dan memperbarui beban kerja berbasis container dengan cepat. Bagian ini menjelaskan taktik yang dapat Anda gunakan untuk membatasi efek samping dari menjalankan container di cluster dan layanan. Google Cloud

Membatasi hak istimewa proses container Pod

Membatasi hak istimewa pada proses dalam container sangat penting untuk keamanan cluster Anda. Anda dapat menyetel opsi terkait keamanan dengan konteks keamanan. Setelan ini memungkinkan Anda mengubah setelan keamanan proses Anda seperti berikut:

Pengguna dan grup yang menjalankan proses
Kemampuan Linux yang tersedia
Eskalasi akses

Sistem operasi node GKE di Azure default, Ubuntu, menggunakan kebijakan keamanan Docker AppArmor default untuk semua container. Anda dapat melihat template profil di GitHub. Di antara berbagai hal lainnya, profil ini menolak kemampuan berikut untuk container:

Menulis ke file secara langsung dalam direktori ID proses (/proc/)
Menulis ke file yang tidak ada di /proc/
Menulis ke file di /proc/sys selain /proc/sys/kernel/shm*
Memasang sistem file

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 menginstal Pengontrol Kebijakan atau Pemilah Komunikasi di cluster Anda dan menerapkan batasan, 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 di Azure, Anda harus menetapkan parameter berikut di Constraint:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Ganti PROJECT_NUMBER dengan nomor (bukan ID) project yang menghosting cluster.

Mengisolasi workload pada node pool khusus

Anda dapat menggunakan taint dan toleransi Kubernetes untuk menetapkan kumpulan node tertentu guna menjalankan jenis workload tertentu. Misalnya, Anda dapat memberi tahu GKE di Azure untuk menjadwalkan workload pengguna agar tidak berdekatan dengan sebagian besar workload yang dikelola sistem, atau menempatkan workload dengan tingkat kepercayaan yang berbeda di node pool yang berbeda.

Isolasi workload menggunakan taint dan toleransi bukanlah jaminan keamanan. Gunakan fitur ini bersama dengan langkah-langkah pengamanan lainnya yang ditawarkan GKE di Azure.

Untuk mempelajari lebih lanjut, lihat Mengisolasi workload di node pool khusus.

Langkah berikutnya

Pelajari Rotasi kunci.