Halaman ini diterjemahkan oleh Cloud Translation API.

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

Standard

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

Secara default, Google mengenkripsi semua data dalam pengiriman antara VM di pengontrol antarmuka jaringan (NIC) untuk memastikan kerahasiaan data selama pengiriman, apa pun bentuknya layanan atau aplikasi yang berjalan di VM (termasuk GKE). Ini enkripsi ini berlaku untuk semua node GKE kemacetan. Kunci enkripsi disediakan dan dikelola oleh Google.

Dengan enkripsi transparan antar-node untuk GKE, Google memberi Anda lebih banyak kontrol atas kunci enkripsi yang digunakan untuk mengenkripsi traffic Pod dalam Node GKE. GKE melakukan enkripsi ini menggunakan WireGuard di GKE Dataplane V2, di selain enkripsi {i>default<i} yang disediakan oleh VM NIC.

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

Anda dapat mengaktifkan enkripsi transparan antar-node dalam cluster tunggal dan multi-cluster lingkungan fleksibel App Engine. Untuk informasi selengkapnya tentang cara kerja fitur ini, lihat Cara enkripsi transparan antar node berfungsi 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 kepatuhan tertentu persyaratan, Anda mungkin ingin mengenkripsi kunci ini lebih lanjut dan mengontrol akses. Untuk melakukannya, kami sarankan Anda menggunakan transparan antar-node enkripsi dengan Confidential GKE Node yang menggunakan kunci enkripsi yang dikelola pelanggan (Customer-Managed Encryption Key/CMEK). Confidential GKE Node yang menggunakan CMEK mengenkripsi isi memori ke node dengan kunci yang Anda kelola.
Enkripsi transparan antar-node untuk GKE hanya didukung pada cluster GKE Dataplane V2.
Autopilot GKE tidak didukung.
Enkripsi transparan antar-node untuk GKE menggunakan WireGuard. WireGuard tidak FIPS mematuhi kebijakan.
Kunci enkripsi tidak dirotasi secara dinamis. Rotasi kunci harus ditangani secara manual dengan memulai ulang node.
Enkripsi transparan antar-node beserta Confidential GKE Node hanya berfungsi pada Container-Optimized OS (COS) dan Ubuntu, dan bukan pada Windows.
Enkripsi transparan antarnode tidak mengenkripsi traffic jaringan yang dimulai oleh node GKE atau Pod menggunakan hostNetwork.
Enkripsi transparan antar-node tidak mengenkripsi traffic jaringan yang dikirim ke Pod diekspos pada port node. Meskipun ExternalTrafficPolicy: Cluster adalah dikonfigurasikan pada Layanan, traffic yang diteruskan dari node pertama penerimaan traffic dari klien ke Pod backend tidak dienkripsi.
Jumlah maksimum node yang didukung dengan enkripsi transparan antar-node diaktifkan untuk konfigurasi cluster tunggal atau multi-cluster adalah 500.
Enkripsi transparan antar {i>node<i} mungkin menyebabkan {i>node<i} yang kelebihan langganan. Anda mungkin mengharapkan peningkatan CPU rata-rata sebesar 15% pada n2-standard-8 dengan OS Ubuntu dengan throughput 2 Gbps.

Peningkatan pemakaian CPU tidak dikaitkan dengan Pod mana pun karena tidak diketahui oleh {i>kube-scheduler<i}. Pod dengan traffic yang meningkat mungkin menggunakan semua resource CPU pada node. Hal ini dapat mencegah Pod lain mendapatkan yang dibutuhkan, bahkan jika telah dikonfigurasi dengan benar. Hal ini dapat menimbulkan masalah bagi Pod yang mencoba menjalankan workload sensitif atau yang harus dapat merespons permintaan dengan cepat. Sebagai solusinya, Anda dapat menjaga sejumlah besar CPU tidak terjadwal pada node yang memiliki enkripsi transparan diaktifkan. Atau, Anda dapat menjadwalkan Pod dengan PriorityClass rendah yang memiliki permintaan CPU besar tetapi tidak pernah menggunakan CPU ini.
Enkripsi transparan antar-node menimbulkan latensi 150 mikrodetik pada dua node di zona yang sama yang tidak menggunakan Confidential GKE Node.
Saat Anda mengaktifkan enkripsi transparan antarnode, kemampuan observasi traffic fitur 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 antarnode, alamat IP Pod tidak terlihat di VPC. Fitur yang bergantung pada inspeksi paket seperti Duplikasi Paket dan VPC berbasis CIDR Pod aturan firewall tidak kompatibel dengan enkripsi transparan antar-node.
Saat Anda mengaktifkan enkripsi transparan antarnode di seluruh cluster yang dilampirkan ke subnet VPC yang berbeda, Anda perlu membuat aturan firewall untuk mengizinkan komunikasi antara node cluster.
Enkripsi transparan antar-node menonaktifkan beberapa kemampuan Lapisan 7 dari GKE Dataplane V2. Oleh karena itu, Anda tidak dapat mengaktifkan kebijakan jaringan FQDN dan enkripsi transparan antar-node secara bersamaan.
Anda tidak dapat mengaktifkan fitur ini secara bersamaan dengan visibilitas intranode.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

Aktifkan Google Kubernetes Engine API.

Mengaktifkan Google Kubernetes Engine API

Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region dan compute/zone. Dengan menyetel lokasi default, Anda dapat menghindari error di gcloud CLI yang seperti ini: One of [--zone, --region] must be supplied: Please specify location.

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 Versi GKE:
- 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 antarnode dengan GKE

Anda dapat mengaktifkan enkripsi transparan antarnode dengan GKE pada dalam satu cluster atau dalam lingkungan multi-cluster.

Mengaktifkan enkripsi transparan antarnode di cluster baru

Untuk mengaktifkan enkripsi transparan antarnode pada 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.
Catatan: Sebaiknya Anda membuat cluster baru dengan enkripsi antarnode alih-alih membuatnya dengan enkripsi antar-node dinonaktifkan dan kemudian mengaktifkannya. Mengaktifkan enkripsi antar-node di lain waktu dapat menyebabkan kumpulan node dimulai ulang.
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)]
```
Catatan: Pastikan jumlah pembanding satu lebih sedikit dari jumlah node dalam cluster Anda. Misalnya, dalam sebuah cluster dengan 24 {i>node<i}, jumlah rekan sejawatnya seharusnya 23. Jika jumlah {i>peer-to-peer<i} tidak kurang dari jumlah dalam cluster, mulai ulang agen anetd di node Anda.

Mengaktifkan enkripsi transparan antarnode pada cluster yang ada

Untuk mengaktifkan enkripsi transparan antarnode 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.
Catatan: Sebaiknya lakukan operasi ini selama pemeliharaan karena operasi ini dapat mengganggu traffic ke Pod Anda. Tujuan pembaruan cluster dan penginstalan jaringan enkripsi antar {i>node<i} dapat proses ini memerlukan waktu beberapa jam.
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 antarnode di GKE akan memulai ulang node secara otomatis. Mungkin diperlukan beberapa jam hingga {i>node<i} dimulai ulang dan {i>node<i} baru harus menegakkan kebijakan.
Untuk mengonfirmasi bahwa node telah dimulai ulang:
```
kubectl get nodes
```
Periksa kolom AGE dari setiap node dan lanjutkan jika kolom AGE mencerminkan node baru.
Untuk memverifikasi konfigurasi, Anda dapat menggunakan 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)]
```
Verifikasi bahwa jumlah peer lebih sedikit dari jumlah node di . Misalnya, dalam cluster dengan 24 node, jumlah peer harus menjadi 23 tahun. Jika jumlah peer tidak kurang dari jumlah {i>node<i} dalam cluster, mulai ulang agen anetd di node Anda.

Mengaktifkan enkripsi transparan antarnode di seluruh cluster

Enkripsi transparan antarnode tidak didukung di Autopilot klaster. Jika armada Anda menyertakan klaster {i>Autopilot<i}, mereka tidak akan dapat berkomunikasi dengan cluster Standar yang mengaktifkan enkripsi.

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

Mengaktifkan enkripsi transparan antarnode di cluster baru atau dalam cluster yang sudah ada.
Mendaftarkan cluster menjadi sebuah armada.
Aktifkan enkripsi transparan antarnode untuk fleet:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Ganti PROJECT_ID dengan project ID Anda.
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)]
...
```
Catatan: Pastikan jumlah pembanding satu lebih sedikit dari jumlah node semua cluster yang terdaftar. Misalnya, dalam cluster dengan 24 node, jumlah rekan sejawat seharusnya 23. Jika jumlah pembanding tidak kurang dari jumlah node di cluster, mulai ulang agen anetd di node Anda.

Nonaktifkan enkripsi transparan antarnode

Dalam beberapa kasus, Anda mungkin ingin menonaktifkan enkripsi cluster GKE Anda untuk peningkatan performa, atau untuk 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.
Lakukan operasi ini selama masa pemeliharaan karena operasi ini akan dan dapat mengganggu traffic Pod.

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

Menonaktifkan di cluster yang merupakan bagian dari fleet

Anda dapat menonaktifkan enkripsi untuk cluster di suatu fleet menggunakan salah satu dua opsi berikut:

Untuk menghapus cluster sepenuhnya dari fleet, batalkan pendaftaran cluster.
Atau, pertahankan cluster dalam 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 peer Wireguard di setiap cluster. Proses ini dapat memakan waktu hingga beberapa menit hingga selesai, tergantung pada jumlah klaster dan {i>node<i} yang terlibat. Untuk melihat jumlah pembanding yang diperbarui, Anda harus memuat ulang secara manual daftar peer WireGuard pada setiap cluster. Anda dapat menggunakan 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 antarnode dalam fleet:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Ganti PROJECT_ID dengan project ID Anda.
Untuk menonaktifkan enkripsi transparan antarnode dan menghapus API yang sekarang tidak digunakan, menonaktifkan 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.

Catatan: API ini bertanggung jawab atas enkripsi transparan antar-node untuk armada Anda. Pastikan Anda memverifikasi bahwa API ini tidak digunakan perangkat lain sebelum Anda menonaktifkannya untuk menghindari hal-hal perilaku model.

Untuk mengelola cluster secara efisien dengan nama yang sama dan memastikan multi-cluster aktivasi enkripsi, ikuti langkah-langkah berikut:
1. Membatalkan pendaftaran cluster lama dari armada sebelum membuat yang baru dengan nama yang sama.
2. Daftarkan ulang paket dikelompokkan saat dibuat ulang.
3. Jika Anda lupa untuk membatalkan pendaftaran membuat cluster baru, menghapus keanggotaan lama, dan membuat ulang cluster baru dengan keanggotaan baru.
Ketidakpatuhan terhadap langkah-langkah ini dapat menyebabkan enkripsi multi-cluster diaktifkan di cluster baru sampai keanggotaan fleet dibuat ulang.

Cara kerja enkripsi transparan antar node dengan GKE

Bagian berikut menjelaskan cara kerja enkripsi transparan antar node saat Anda mengaktifkannya dalam cluster:

Enkripsi traffic jaringan antara dua Pod pada node yang berbeda

Dengan enkripsi transparan antar-node yang diaktifkan, GKE Dataplane V2 mengenkripsi Traffic Pod-ke-Pod jika Pod berada di node berbeda, terlepas dari cluster yang di mana semua node tersebut berada. Ketika semua cluster merupakan bagian dari fleet, keduanya milik jaringan domain enkripsi.

Cluster dengan konfigurasi enkripsi transparan antarnode yang berbeda dapat berdampingan dalam armada yang sama. Jika Anda memiliki lingkungan multi-cluster di mana beberapa cluster saja yang menggunakan enkripsi transparan antarnode, pertimbangan berlaku:

Komunikasi Pod-ke-Pod antar-node di cluster yang sama dienkripsi menggunakan pasangan kunci publik/pribadi.
Komunikasi pod ke Pod antara node dalam cluster yang memiliki inter-node enkripsi transparan diaktifkan, dan {i>node<i} dalam cluster yang tidak memiliki Enkripsi transparan antarnode yang diaktifkan akan gagal.

Pembuatan dan penggunaan kunci enkripsi

Saat fitur ini diaktifkan, setiap node GKE di cluster secara otomatis membuat pasangan kunci publik/pribadi yang dikenal sebagai .

Kunci pribadi disimpan di memori (bukan di disk) dan tidak pernah meninggalkan {i>node<i}. Menggunakan Rahasia GKE Node lebih lanjut mengurangi risiko penyusupan kunci karena memori {i>node<i} juga dienkripsi (dengan kunci yang berbeda).
Kunci publik dibagikan dengan node lain menggunakan kontrol GKE Dataplane V2 dan dapat diakses oleh semua {i> node<i} dalam domain enkripsi yang sama.

Setelah kunci dipertukarkan, setiap {i>node<i} dapat membuat terowongan WireGuard dengan {i>node<i} lain yang berada di domain enkripsi yang sama. Setiap tunnel bersifat unik untuk setiap sepasang node.

Pertimbangkan hal berikut ketika berhadapan dengan pasangan kunci pribadi atau publik dan kunci sesi:

Pasangan kunci pribadi/publik:
- Kunci publik didistribusikan di dalam cluster dan semua node di dalam cluster akses ke kunci publik tersebut.
- Pasangan kunci dirotasi saat node dimulai ulang. GKE dan tidak merotasi kunci secara berkala. Untuk memicu kunci secara manual rotasi, menguras dan memulai ulang node. Tindakan ini akan membatalkan 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.