Dokumentasi ini ditujukan untuk GKE versi terbaru di Azure, yang dirilis pada November 2021. Lihat Catatan rilis untuk mengetahui informasi selengkapnya.

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 berbagai 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 untuk 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 pengiriman. Secara default, GKE di Azure mengenkripsi data dalam etcd dan volume penyimpanan dalam penyimpanan menggunakan kunci yang dikelola platform Azure.

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

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

Saat membuat cluster, Anda dapat menyediakan kunci Azure Key Vault dalam parameter --database-encryption-kms-key-arn. Kunci ini digunakan untuk enkripsi 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 diubah setelah cluster dibuat.

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

Cara kerja enkripsi tingkat aplikasi

Kubernetes menawarkan enkripsi tingkat aplikasi dengan teknik yang dikenal sebagai enkripsi envelope. Kunci lokal, yang biasa 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 membuat Secret Kubernetes baru, cluster Anda akan melakukan hal-hal berikut:

Server Kubernetes API menghasilkan DEK unik untuk Secret tersebut menggunakan generator angka acak.
Server Kubernetes API mengenkripsi Secret secara lokal dengan DEK.
Server Kubernetes API mengirimkan DEK ke Azure Key Vault untuk enkripsi.
Azure Key Vault menggunakan KEK yang telah dibuat sebelumnya untuk mengenkripsi DEK dan menampilkan DEK terenkripsi 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 saja diakses tanpa membuat kueri Azure Key Vault.

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

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

Konfigurasi Enkripsi 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 User Access Administrator Azure 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 vault kunci.

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

Anda tetap harus 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 merupakan tindakan mengubah materi kriptografi dasar yang terdapat dalam kunci enkripsi kunci (KEK). Pemicuan ini dapat dipicu secara otomatis sebagai bagian dari rotasi terjadwal, atau secara manual, biasanya setelah terjadi insiden keamanan saat kunci 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 root certificate authority (CA) 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 satu CA cluster disusupi, tidak ada CA cluster lain yang akan terpengaruh. Semua root CA memiliki masa berlaku selama 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 yang berikut ini:

Kumpulan paket yang dioptimalkan
Kernel Linux yang disesuaikan oleh Google Cloud
Akun pengguna terbatas dan login root dinonaktifkan

Panduan keamanan tambahan tersedia untuk Ubuntu, seperti berikut ini:

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 layanan cluster dan Google Cloud.

Membatasi hak istimewa proses penampung Pod

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

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

GKE default di sistem operasi node Azure, Ubuntu, menggunakan kebijakan keamanan AppArmor Docker default untuk semua container. Anda dapat melihat template profil di GitHub. Di antara 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 dalam bahasa /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 modifikasi mandiri diperlukan, Anda dapat membatasi izin dengan menginstal Pengontrol Kebijakan atau Gatekeeper di cluster dan menerapkan batasan, seperti NoUpdateServiceAccount dari library open source Gatekeeper yang menyediakan 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 pada 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 di node pool khusus

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

Isolasi workload menggunakan taint dan toleransi bukanlah tindakan keamanan yang dijamin. Hanya gunakan ini bersama tindakan hardening lainnya yang ditawarkan GKE di Azure.

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

Langkah selanjutnya

Pelajari Rotasi kunci.