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 mengambil tanggung jawab tertentu untuk cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Tanggung jawab bersama cluster GKE.

Enkripsi data nonaktif

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

Cluster GKE di Azure menyimpan data dalam volume Disk Azure. Volume ini selalu dienkripsi saat tidak aktif menggunakan kunci Azure Key Vault. Saat membuat cluster dan node pool, Anda dapat memberikan Kunci Keyvault yang Dikelola Pelanggan untuk mengenkripsi volume Disk yang mendasarinya. Jika Anda tidak menentukan kunci, Azure akan menggunakan kunci default yang dikelola Azure 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 akan dienkripsi.

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

Anda juga dapat membuat kunci Key Vault secara manual atau menggunakan kunci Anda sendiri (BYOK) dengan modul keamanan hardware (HSM). Untuk mengetahui informasi selengkapnya, lihat Menggunakan 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:

  1. Server Kubernetes API menghasilkan DEK unik untuk Secret menggunakan a generator angka acak.

  2. Server Kubernetes API mengenkripsi Secret secara lokal dengan DEK.

  3. Server Kubernetes API mengirimkan DEK ke Azure Key Vault untuk enkripsi.

  4. Azure Key Vault menggunakan KEK yang telah dibuat sebelumnya untuk mengenkripsi DEK dan menampilkan DEK terenkripsi ke plugin Azure Key Vault server Kubernetes API.

  5. Server Kubernetes API menyimpan Secret terenkripsi dan DEK terenkripsi ke etcd. DEK teks biasa tidak disimpan ke disk.

  6. 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 membuat kueri Azure Key Vault.

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

  1. Server Kubernetes API mengambil Secret terenkripsi dan DEK terenkripsi dari etcd.

  2. Server Kubernetes API memeriksa cache untuk entri peta yang ada dan jika ditemukan, mendekripsi Secret dengan entri tersebut.

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

  4. Terakhir, server Kubernetes API menampilkan Secret yang didekripsi kepada klien.

Mengonfigurasi Enkripsi dengan Firewall Key Vault

Jika Anda meneruskan kunci publik untuk enkripsi, principal 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 principal 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 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 adalah tindakan mengubah materi kriptografi yang mendasarinya yang terdapat dalam kunci enkripsi kunci (KEK). Rotasi kunci dapat dipicu secara otomatis sebagai bagian dari rotasi terjadwal, atau secara manual, biasanya setelah insiden keamanan yang mungkin menyebabkan kunci terganggu. 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 CA satu cluster terganggu, CA 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

Ubuntu Untuk mengetahui informasi selengkapnya, lihat fitur keamanan dalam dokumentasi Ubuntu.

Cluster GKE menerapkan beberapa fitur keamanan, termasuk hal berikut:

  • Set paket yang dioptimalkan

  • Kernel Linux yang disesuaikanGoogle Cloud

  • 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 menjalankan container di cluster dan Google Cloud layanan.

Membatasi hak istimewa proses container Pod

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

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

Sistem operasi node GKE di Azure default, Ubuntu, menggunakan default kebijakan keamanan Docker AppArmor default untuk semua container. Anda dapat melihat template profil di GitHub. Selain hal lainnya, profil ini menolak kemampuan berikut pada 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 dalam 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 menetapkan node pool tertentu untuk menjalankan jenis workload tertentu. Misalnya, Anda dapat memberi tahu GKE di Azure untuk menjadwalkan workload pengguna agar tidak menggunakan 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 langkah keamanan yang dijamin. Hanya gunakan isolasi workload bersama dengan langkah-langkah penguatan lainnya yang ditawarkan GKE di Azure.

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

Langkah berikutnya