Mengenkripsi data Anda saat dalam pengiriman di GKE dengan kunci enkripsi yang dikelola pengguna

Halaman ini menunjukkan cara mengaktifkan enkripsi data dalam pengiriman untuk komunikasi Pod di seluruh node Google Kubernetes Engine (GKE) dengan kunci enkripsi yang dikelola pengguna.

Secara default, Google mengenkripsi semua data dalam pengiriman antar-VM di level pengontrol antarmuka jaringan (NIC) untuk memastikan kerahasiaan data dalam pengiriman, terlepas dari layanan atau aplikasi apa yang berjalan di VM (termasuk GKE). Lapisan enkripsi ini berlaku untuk semua node GKE dan traffic Pod. Kunci enkripsi disediakan dan dikelola oleh Google.

Dengan enkripsi transparan antar-node untuk GKE, Google memberi Anda kontrol lebih besar atas kunci enkripsi yang digunakan untuk mengenkripsi traffic Pod di seluruh node GKE. GKE menjalankan enkripsi ini menggunakan WireGuard di GKE Dataplane V2, selain enkripsi default yang disediakan oleh NIC VM.

Memberikan kontrol langsung atas kunci enkripsi ini di GKE berguna jika Anda berada dalam industri yang teregulasi dan memiliki kebutuhan bisnis untuk kepatuhan dan audit keamanan.

Anda dapat mengaktifkan enkripsi transparan antar-node dalam lingkungan tunggal dan multi-cluster. Untuk mengetahui informasi lebih lanjut tentang cara kerja fitur ini, baca Cara kerja enkripsi transparan antar-node dengan GKE.

Batasan

  • Fitur ini sendiri tidak menjamin bahwa Google tidak dapat mengakses kunci enkripsi yang disimpan dalam memori node GKE. Di beberapa lingkungan atau wilayah hukum yang diatur, atau untuk memenuhi persyaratan kepatuhan tertentu, sebaiknya Anda mengenkripsi kunci ini lebih lanjut dan mengontrol akses. Untuk melakukannya, sebaiknya gunakan enkripsi transparan antarnode dengan Confidential GKE Node yang menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Confidential GKE Node yang menggunakan CMEK mengenkripsi konten memori node dengan kunci yang Anda kelola.

  • Enkripsi transparan antar-node untuk GKE hanya didukung di cluster GKE Dataplane V2.

  • Autopilot GKE tidak didukung.

  • Enkripsi transparan antar-node untuk GKE menggunakan WireGuard. WireGuard tidak sesuai dengan FIPS.

  • Kunci enkripsi tidak dirotasi secara dinamis. Rotasi kunci perlu ditangani secara manual dengan memulai ulang node.

  • Enkripsi transparan antar-node beserta Confidential GKE Node hanya berfungsi di Container-Optimized OS (COS) dan Ubuntu, bukan di Windows.

  • Enkripsi transparan antarnode tidak mengenkripsi traffic jaringan yang dimulai oleh node GKE atau Pod menggunakan hostNetwork.

  • Enkripsi transparan antarnode tidak mengenkripsi traffic jaringan yang dikirim ke Pod yang diekspos pada port node. Meskipun ExternalTrafficPolicy: Cluster dikonfigurasi di Service, traffic yang diteruskan dari node pertama yang menerima traffic dari klien ke Pod backend tidak dienkripsi.

  • Jumlah maksimum node yang didukung dengan enkripsi transparan antarnode yang diaktifkan untuk konfigurasi cluster tunggal atau multi-cluster adalah 500.

  • Enkripsi transparan antar-node dapat menyebabkan node disubscribe terlalu banyak. Anda mungkin memperkirakan peningkatan CPU sebesar rata-rata 15% pada node n2-standard-8 menggunakan Ubuntu OS dengan throughput 2 Gbps.

    Peningkatan pemakaian CPU tidak diatribusikan dengan Pod mana pun karena tidak diketahui oleh kube-scheduler. Pod dengan traffic yang meningkat mungkin menggunakan semua resource CPU pada node. Hal ini dapat mencegah Pod lain mendapatkan resource CPU yang diperlukan, meskipun telah dikonfigurasi dengan benar. Hal ini dapat menyebabkan masalah bagi Pod yang mencoba menjalankan beban kerja yang sensitif atau yang harus dapat merespons permintaan dengan cepat. Sebagai solusinya, Anda dapat membuat sejumlah besar CPU tidak dijadwalkan pada node yang telah mengaktifkan enkripsi transparan antar-node. Atau, Anda dapat menjadwalkan Pod dengan PriorityClass rendah yang memiliki permintaan CPU besar, tetapi tidak pernah menggunakan CPU ini.

  • Enkripsi transparan antarnode menimbulkan latensi 150 mikrodetik pada dua node di zona yang sama yang tidak menggunakan Confidential GKE Node.

  • Saat Anda mengaktifkan enkripsi transparan antar-node, fitur kemampuan observasi traffic yang digunakan untuk melacak traffic di Pod mungkin tidak berfungsi seperti yang diharapkan karena data dalam pengiriman dienkripsi dengan kunci yang tidak dapat diakses ke infrastruktur Google yang mendasarinya.

  • Jika Anda mengaktifkan enkripsi transparan antar-node, alamat IP Pod tidak akan terlihat di VPC. Fitur yang bergantung pada inspeksi paket, seperti Duplikasi Paket dan aturan firewall VPC berbasis CIDR Pod, tidak kompatibel dengan enkripsi transparan antar-node.

  • Saat mengaktifkan enkripsi transparan antarnode di seluruh cluster yang terpasang ke subnet VPC yang berbeda, Anda harus membuat aturan firewall secara manual untuk memungkinkan komunikasi antara node cluster.

  • Enkripsi transparan antar-node menonaktifkan beberapa kemampuan Lapisan 7 dari GKE Dataplane V2. Akibatnya, Anda tidak dapat mengaktifkan kebijakan jaringan FQDN dan enkripsi transparan antar-node secara bersamaan.

  • Anda tidak dapat mengaktifkan fitur ini bersamaan dengan visibilitas intranode.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu initialize gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

  • Ikuti petunjuk untuk Mengaktifkan GKE Enterprise.

  • Enkripsi transparan antar-node GKE hanya didukung di Google Cloud CLI versi 458.0.0 dan yang lebih baru, serta versi GKE berikut:

    • 1.26.10-gke.1024000 atau yang lebih baru
    • 1.27.7-gke.1506000 atau yang lebih baru
    • 1.28.2-gke.1098000 atau yang lebih baru

Mengaktifkan enkripsi transparan antar-node dengan GKE

Anda dapat mengaktifkan enkripsi transparan antar-node dengan GKE pada satu cluster atau di lingkungan multi-cluster.

Mengaktifkan enkripsi transparan antar-node di cluster baru

  1. Untuk mengaktifkan enkripsi transparan antarnode di cluster baru:

    gcloud container clusters create CLUSTER_NAME \
    --region=REGION
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent

    Ganti kode berikut:

    • CLUSTER_NAME dengan nama cluster Anda.
    • REGION dengan region komputasi cluster Anda.

  2. Untuk memverifikasi konfigurasi, gunakan perintah berikut untuk memeriksa status enkripsi:

    kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption

    Outputnya mirip dengan hal berikut ini:

    Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]

Mengaktifkan enkripsi transparan antar-node pada cluster yang ada

  1. Untuk mengaktifkan enkripsi transparan antar-node pada cluster yang ada:

    gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent
  --region=REGION

    Ganti kode berikut:

    • CLUSTER_NAME dengan nama cluster Anda.
    • REGION dengan region komputasi cluster Anda.

  2. Untuk memeriksa apakah perintah Google Cloud CLI berhasil diselesaikan :

    gcloud container clusters describe CLUSTER_NAME \
    --region=REGION
    --format json | jq .status

    Ganti kode berikut:

    • CLUSTER_NAME dengan nama cluster Anda.
    • REGION dengan region komputasi cluster Anda.

    Tunggu hingga status menampilkan "RUNNING". Mengaktifkan enkripsi antar-node di GKE akan otomatis memulai ulang node. Mungkin perlu waktu beberapa jam agar node dimulai ulang dan agar node baru menerapkan kebijakan.

  3. Untuk memastikan bahwa node telah dimulai ulang:

    kubectl get nodes

    Periksa kolom AGE di setiap node dan lanjutkan jika kolom AGE mencerminkan node baru.

  4. Untuk memverifikasi konfigurasi, Anda dapat menggunakan perintah berikut guna memeriksa status enkripsi:

    kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption

    Outputnya mirip dengan hal berikut ini:

    Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]

    Pastikan jumlah pembanding kurang dari jumlah node di cluster Anda. Misalnya, dalam sebuah cluster dengan 24 node, jumlah peer harus 23. Jika jumlah pembanding tidak kurang dari jumlah node dalam cluster, mulai ulang agen anetd di node Anda lagi.

Mengaktifkan enkripsi transparan antar-node di seluruh cluster

Enkripsi transparan antar-node tidak didukung di cluster Autopilot. Jika armada Anda menyertakan cluster Autopilot, mereka tidak akan dapat berkomunikasi dengan cluster Standar yang mengaktifkan enkripsi.

Untuk mengaktifkan enkripsi transparan antar-node dalam lingkungan multi-cluster:

  1. Aktifkan enkripsi transparan antarnode pada cluster baru atau di cluster yang ada.

  2. Daftarkan cluster Anda ke fleet.

  3. Aktifkan enkripsi transparan antar-node untuk fleet:

    gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID

    Ganti PROJECT_ID dengan project ID Anda.

  4. Verifikasi status di semua node:

    kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status

    Outputnya mirip dengan hal berikut ini:

    ...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...

Nonaktifkan enkripsi transparan antar-node

Dalam beberapa kasus, Anda mungkin ingin menonaktifkan enkripsi transparan antar-node di cluster GKE untuk meningkatkan performa atau memecahkan masalah konektivitas untuk aplikasi Anda. Sebelum melanjutkan operasi ini, pertimbangkan hal berikut:

  • Enkripsi transparan antarnode diaktifkan untuk seluruh cluster dan Anda tidak dapat menonaktifkannya sebagian di resource Kubernetes individual seperti namespace atau Pod.

  • Jalankan operasi ini selama masa pemeliharaan karena operasi ini akan mengganggu traffic Pod Anda.

Di satu cluster

Untuk menonaktifkan enkripsi transparan antarnode pada satu cluster:

gcloud container clusters update CLUSTER_NAME \
    --region=REGION
    --in-transit-encryption none

Ganti kode berikut:

  • CLUSTER_NAME: dengan nama cluster Anda.

  • REGION: dengan region komputasi cluster Anda.

Nonaktifkan di cluster yang merupakan bagian dari fleet

Anda dapat menonaktifkan enkripsi untuk cluster dalam fleet menggunakan salah satu dari dua opsi berikut:

  • Untuk sepenuhnya menghapus cluster dari fleet, batalkan pendaftaran cluster Anda.

  • Atau, simpan cluster di fleet, tetapi nonaktifkan enkripsi:

    gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID

    Ganti PROJECT_ID dengan project ID Anda.

    Menonaktifkan enkripsi dengan perintah ini akan memulai penghapusan node jarak jauh dari daftar rekan Wireguard di setiap cluster. Proses ini dapat memerlukan waktu hingga beberapa menit, bergantung pada jumlah cluster dan node yang terlibat. Untuk melihat jumlah pembanding yang diperbarui, Anda harus memuat ulang daftar pembanding WireGuard secara manual pada setiap cluster. Anda dapat menggunakan alat pengelolaan cluster atau perintah berikut:

    kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption

Nonaktifkan untuk seluruh fleet cluster

  • Untuk menonaktifkan enkripsi transparan antar-node dalam suatu fleet:

    gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID

    Ganti PROJECT_ID dengan project ID Anda.

  • Untuk menonaktifkan enkripsi transparan antar-node dan menghapus API yang sekarang tidak digunakan, nonaktifkan GKE Dataplane V2 API di level fleet. Tindakan ini akan menonaktifkan pengontrol GKE Dataplane V2 yang berjalan di fleet Anda.

    gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID

    Ganti PROJECT_ID dengan project ID Anda.

    Untuk mengelola cluster dengan nama yang sama secara efisien dan memastikan aktivasi enkripsi multi-cluster, ikuti langkah-langkah berikut:

    1. Batalkan pendaftaran cluster lama dari fleet sebelum membuat yang baru dengan nama yang sama.

    2. Daftarkan ulang cluster baru saat pembuatan ulang.

    3. Jika Anda lupa membatalkan pendaftaran cluster, hapus keanggotaan lama, dan buat ulang cluster baru dengan keanggotaan baru.

    Jika langkah-langkah ini tidak diikuti, enkripsi multi-cluster dapat tidak diaktifkan di cluster baru hingga keanggotaan fleet dibuat ulang.

Cara kerja enkripsi transparan antarnode dengan GKE

Bagian berikut menjelaskan cara kerja enkripsi transparan antarnode saat Anda mengaktifkannya di cluster:

Enkripsi traffic jaringan antara dua Pod pada node yang berbeda

Dengan mengaktifkan enkripsi transparan antar-node, GKE Dataplane V2 akan mengenkripsi traffic Pod-to-Pod jika Pod berada di node yang berbeda, terlepas dari cluster yang mencakup node tersebut. Jika merupakan bagian dari fleet yang sama, cluster akan berada dalam domain enkripsi yang sama.

Cluster dengan konfigurasi enkripsi transparan antar-node yang berbeda dapat berdampingan dalam fleet yang sama. Jika Anda memiliki lingkungan multi-cluster tempat hanya beberapa cluster yang menggunakan enkripsi transparan antar-node, hal-hal berikut akan berlaku:

  • Komunikasi Pod-to-Pod antar-node dalam cluster yang sama dienkripsi menggunakan pasangan kunci publik/pribadi.

  • Komunikasi Pod-to-Pod antara node dalam cluster yang mengaktifkan enkripsi transparan antarnode dan node dalam cluster yang tidak mengaktifkan enkripsi transparan antar-node akan gagal.

Pembuatan dan penggunaan kunci enkripsi

Saat fitur ini diaktifkan, setiap node GKE dalam cluster akan otomatis menghasilkan pasangan kunci publik/pribadi yang disebut dengan kunci enkripsi.

  • Kunci pribadi disimpan dalam memori (bukan di disk) dan tidak pernah dikirim ke luar node. Menggunakan GKE Confidential Node akan lebih mengurangi risiko kunci disusupi karena memori node juga dienkripsi (dengan kunci yang berbeda).

  • Kunci publik dibagikan kepada node lain menggunakan bidang kontrol GKE Dataplane V2 dan dapat diakses oleh semua node di domain enkripsi yang sama.

Setelah kunci dipertukarkan, setiap node dapat membuat tunnel WireGuard dengan node lain dalam domain enkripsi yang sama. Setiap tunnel bersifat unik untuk pasang node tertentu.

Pertimbangkan hal berikut saat menangani pasangan kunci pribadi atau publik dan kunci sesi:

  • Pasangan kunci pribadi/publik:

    • Kunci publik didistribusikan dalam cluster dan semua node dalam cluster tersebut dapat mengakses kunci publik.

    • Pasangan kunci diputar saat node dimulai ulang. GKE tidak merotasi kunci secara berkala. Untuk memicu rotasi kunci secara manual, kuras dan mulai ulang node. Tindakan ini akan membatalkan pasangan kunci asli dan menghasilkan pasangan kunci baru.

  • Kunci sesi:

    • Kunci ini tidak dapat dikonfigurasi.

    • Kunci ini dirotasi secara berkala setiap dua menit.

    • Kunci sesi bersifat eksklusif untuk node yang terlibat dalam tunnel.

Langkah selanjutnya