Tentang otoritas bidang kontrol GKE

Dokumen ini menjelaskan opsi yang ditawarkan Google Kubernetes Engine (GKE) untuk meningkatkan visibilitas dan kontrol Anda atas keamanan bidang kontrol terkelola. Opsi ini secara kolektif disebut sebagai otoritas bidang kontrol GKE. Dokumen ini ditujukan untuk pemimpin keamanan informasi, administrator kepatuhan, dan analis yang ingin memenuhi kebutuhan privasi dan keamanan yang ketat untuk menangani data sensitif.

Tentang fitur otoritas bidang kontrol GKE

Di GKE, Cloud de Confiance by S3NS mengelola konfigurasi keamanan bidang kontrol sepenuhnya, termasuk enkripsi penyimpanan dalam penyimpanan, dan mengonfigurasi kunci dan certificate authority (CA) yang menandatangani dan memverifikasi kredensial di cluster Anda. Node bidang kontrol untuk cluster GKE ada di project yang Cloud de Confiance dikelola. Untuk mengetahui detail tentang apa yang Cloud de Confiance dilakukan, lihat Tanggung jawab bersama GKE.

Otoritas bidang kontrol GKE adalah kumpulan kemampuan visibilitas dan kontrol opsional yang memungkinkan Anda memverifikasi dan mengelola aspek tertentu dari node bidang kontrol yang dikelola sepenuhnya ini. Kemampuan ini ideal jika Anda memiliki persyaratan seperti berikut:

  • Anda beroperasi di industri yang sangat diatur seperti keuangan, layanan kesehatan, atau pemerintah dengan persyaratan kepatuhan tertentu
  • Anda menangani data sensitif yang memiliki persyaratan keamanan dan enkripsi yang ketat
  • Anda menginginkan visibilitas yang ditingkatkan atas GKE untuk meningkatkan keyakinan Anda saat menjalankan workload penting
  • Anda harus memenuhi persyaratan kepatuhan atau audit tertentu yang terkait dengan enkripsi data, integritas software, atau logging
  • Anda memiliki workload yang sangat sensitif yang memproses data penting, dan Anda menginginkan visibilitas atas enkripsi dan akses ke data tersebut
  • Anda ingin menerapkan kebijakan keamanan kustom yang memenuhi persyaratan organisasi atau peraturan tertentu
  • Anda menginginkan tingkat transparansi dan visibilitas yang ditingkatkan ke lingkungan GKE Anda, terutama terkait tindakan yang Cloud de Confiance dilakukan di bidang kontrol

Manfaat otoritas bidang kontrol GKE

Kemampuan otoritas bidang kontrol GKE ideal di lingkungan yang sangat diatur yang memiliki kebijakan keamanan yang ketat atau persyaratan audit yang ketat. Menggunakan kemampuan ini memberikan manfaat seperti berikut:

  • Visibilitas dan kontrol yang ditingkatkan: gunakan kemampuan visibilitas, kontrol, dan enkripsi tambahan untuk bidang kontrol GKE Anda.
  • Kepatuhan yang disederhanakan: penuhi persyaratan peraturan dan industri dengan log audit mendetail dan kebijakan keamanan yang dapat disesuaikan.
  • Peningkatan kepercayaan dan transparansi: dapatkan insight tentang tindakan yang Cloud de Confiance dilakukan di bidang kontrol saat menyelesaikan kasus dukungan pelanggan.
  • Mitigasi risiko: deteksi dan respons secara proaktif terhadap potensi ancaman ke bidang kontrol terkelola dengan log yang komprehensif.
  • Pengelolaan CA dan kunci yang distandardisasi: kelola CA cluster GKE Anda menggunakan Certificate Authority Service, yang memungkinkan Anda mendelegasikan pengelolaan sertifikat ke tim tertentu dan memungkinkan Anda menerapkan kebijakan CA secara komprehensif. Selain itu, kelola kunci enkripsi disk bidang kontrol Anda menggunakan Cloud KMS untuk delegasi pengelolaan yang serupa.

Ketersediaan otoritas bidang kontrol GKE

Otoritas bidang kontrol GKE tersedia di wilayah mana pun. Cloud de Confiance Namun, untuk mengenkripsi boot disk bidang kontrol dan disk etcd dengan kunci Anda sendiri, Anda harus membuat cluster di salah satu wilayah berikut:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4

Cara kerja otoritas bidang kontrol GKE

Kemampuan yang dapat Anda gunakan dengan bidang kontrol dikategorikan berdasarkan jenis kontrol yang Anda inginkan, sebagai berikut. Anda dapat menggunakan satu atau beberapa kemampuan ini berdasarkan persyaratan spesifik Anda.

  • Pengelolaan kunci dan kredensial: kontrol kunci yang digunakan GKE untuk mengenkripsi data dalam penyimpanan di bidang kontrol dan untuk menerbitkan serta memverifikasi identitas di cluster.
  • Log akses dan log penerbitan identitas: gunakan log dari jaringan, VM, dan Transparansi Akses untuk memverifikasi akses bidang kontrol GKE menggunakan beberapa sumber. Gunakan log penerbitan identitas di Cloud KMS dan CA Service untuk melihat kapan identitas dibuat menggunakan kunci dan CA yang Anda kelola. Gunakan log penggunaan Kubernetes API mendetail untuk melacak tindakan yang dilakukan identitas tersebut di cluster.

Pengelolaan kunci dan kredensial

Secara default, Cloud de Confiance mengelola kunci dan CA di cluster GKE Anda. Anda dapat secara opsional menggunakan Cloud KMS dan CA Service untuk menyiapkan kunci dan CA Anda sendiri, yang kemudian Anda gunakan saat membuat cluster baru.

GKE menggunakan kunci dan CA ini, bukan Cloud de Confiance default, untuk menerbitkan dan memverifikasi identitas di cluster Anda serta untuk mengenkripsi data di VM bidang kontrol Anda. Mempertahankan kontrol atas kunci penerbitan identitas dan enkripsi data dapat membantu Anda melakukan hal berikut:

  • Mematuhi peraturan kedaulatan dan privasi data yang mewajibkan kontrol eksklusif atas kunci
  • Mengontrol enkripsi data sensitif penting di Kubernetes dengan mengelola kunci enkripsi Anda sendiri
  • Menyesuaikan strategi enkripsi data berdasarkan kebijakan dan persyaratan organisasi Anda, seperti persyaratan untuk menggunakan kunci yang didukung hardware.

CA dan kunci akun layanan yang dikelola sendiri

Anda dapat mengonfigurasi bidang kontrol GKE untuk menggunakan kunci Cloud KMS dan CA Service CA yang Anda kelola. GKE menggunakan resource ini untuk menerbitkan dan memverifikasi identitas di cluster Anda. Misalnya, GKE menggunakan CA dan kunci untuk menerbitkan sertifikat klien Kubernetes dan token pembawa akun layanan Kubernetes.

Anda membuat resource berikut untuk digunakan GKE saat menerbitkan identitas:

  1. Kunci penandatanganan Akun Layanan: menandatangani token pembawa ServiceAccount Kubernetes untuk akun layanan di cluster. Token pembawa ini adalah JSON Web Token (JWT) yang memfasilitasi komunikasi Pod dengan server Kubernetes API.
  2. Kunci verifikasi Akun Layanan: memverifikasi JWT Akun Layanan Kubernetes. Kunci ini biasanya sama dengan kunci penandatanganan, tetapi dikonfigurasi secara terpisah sehingga Anda dapat merotasi kunci dengan lebih aman.
  3. CA Cluster: menerbitkan sertifikat yang ditandatangani untuk tujuan seperti permintaan penandatanganan sertifikat (CSR) dan komunikasi kubelet.
  4. CA peer etcd: Menerbitkan sertifikat yang ditandatangani untuk komunikasi antara instance etcd di cluster.
  5. CA etcd API: menerbitkan sertifikat yang ditandatangani untuk komunikasi dengan server etcd API.
  6. CA Agregasi: menerbitkan sertifikat yang ditandatangani untuk mengaktifkan komunikasi antara server Kubernetes API dan server ekstensi.

Saat GKE menerbitkan identitas di cluster, Anda akan melihat log audit yang sesuai di Cloud Logging, yang dapat Anda gunakan untuk melacak identitas yang diterbitkan selama masa aktifnya.

Untuk mempelajari lebih lanjut, lihat Menjalankan certificate authority dan kunci penandatanganan Anda sendiri di GKE.

Enkripsi boot disk dan etcd bidang kontrol

Secara default, GKE mengenkripsi boot disk VM bidang kontrol. Jika bidang kontrol menjalankan instance database etcd, GKE juga mengenkripsi hal berikut:

  • Disk yang menyimpan data etcd.
  • Cadangan operasional internal etcd. Cloud de Confiance by S3NS

Enkripsi default ini menggunakan kunci enkripsi yang Cloud de Confiance dikelola. Untuk mengetahui detail tentang enkripsi default ini, lihat Enkripsi dalam penyimpanan default.

Anda dapat secara opsional menggunakan kunci enkripsi Anda sendiri yang Anda kelola menggunakan Cloud KMS untuk mengenkripsi resource berikut:

  • Boot disk bidang kontrol: disk Compute Engine yang digunakan setiap VM bidang kontrol untuk melakukan booting.
  • Disk etcd: disk Compute Engine yang terpasang ke setiap VM bidang kontrol dan menyimpan data untuk instance etcd di cluster.

  • Cadangan operasional internal etcd: cadangan internal etcd yang digunakan untuk tujuan operasional seperti pemulihan dari bencana. Cloud de Confiance

    Cadangan ini adalah tindakan darurat internal untuk Cloud de Confiance. Jika Anda ingin mencadangkan dan memulihkan cluster, gunakan pencadangan untuk GKE sebagai gantinya.

Untuk mengetahui petunjuknya, lihat Mengenkripsi etcd dan boot disk bidang kontrol.

Enkripsi opsional tambahan ini ideal jika Anda harus memenuhi persyaratan peraturan atau kepatuhan tertentu yang terkait dengan pengendalian cara enkripsi di bidang kontrol cluster Anda. Anda dapat menggunakan kunci Anda sendiri secara terpisah untuk mengenkripsi boot disk dan disk penyimpanan node pekerja di cluster Anda. Untuk mengetahui detailnya, lihat Menggunakan kunci enkripsi yang dikelola pelanggan (CMEK).

Saat Anda menggunakan otoritas bidang kontrol GKE untuk mengenkripsi boot disk bidang kontrol, VM bidang kontrol GKE akan otomatis menggunakan Mode rahasia untuk Hyperdisk Balanced di boot disk. Konfigurasi ini tidak mengubah boot disk default node pekerja Anda.

Rotasi kredensial yang dikelola pelanggan

Dengan otoritas bidang kontrol GKE, Anda dapat mengonfigurasi cluster untuk menggunakan CA dan kunci yang dikelola pelanggan, bukan resource yang dikelola Google yang digunakan GKE secara default. Rotasi kredensial adalah operasi yang Anda lakukan untuk memperbarui satu atau beberapa resource ini di cluster. Anda mungkin melakukan rotasi kredensial karena alasan seperti menghindari masa berlaku CA berakhir atau mematuhi persyaratan pengelolaan kredensial organisasi Anda.

Untuk melakukan rotasi kredensial untuk cluster yang menggunakan otoritas bidang kontrol GKE, Anda membuat CA, kunci penandatanganan, dan kunci enkripsi baru. Kemudian, Anda mengupdate cluster untuk menggunakan resource baru tersebut.

Untuk informasi lebih lanjut, lihat halaman berikut:

Log akses dan log penerbitan identitas

Anda dapat melihat log di Logging untuk semua peristiwa terkait akses dan identitas di bidang kontrol, termasuk peristiwa berikut:

  • Akses langsung: log terkait upaya akses langsung (seperti SSH) ke node bidang kontrol GKE memungkinkan Anda memverifikasi bahwa log SSH VM dan koneksi jaringan VM cocok dengan catatan SSH di log Transparansi Akses.
  • Penerbitan dan verifikasi identitas: log terkait identitas yang diterbitkan menggunakan CA dan kunci yang Anda kelola di CA Service dan Cloud KMS.
  • Penggunaan identitas di Kubernetes: log terkait tindakan yang dilakukan identitas tertentu terhadap server Kubernetes API.
  • Transparansi Akses: log terkait koneksi yang dibuat ke bidang kontrol dan tindakan yang dilakukan pada bidang kontrol oleh Cloud de Confiance personel. Jika Persetujuan Akses Tambahan diaktifkan, Anda akan mendapatkan granularitas yang ditingkatkan untuk kontrol akses, termasuk detail perintah SSH dalam log Transparansi Akses dan untuk permintaan Persetujuan Akses. Untuk mengetahui informasi selengkapnya tentang kelayakan dan pendaftaran, hubungi tim akun Cloud de Confiance by S3NS Anda.

Log ini dapat membantu Anda melakukan hal berikut:

  • Mempertahankan jalur audit komprehensif dari semua peristiwa akses dan identitas bidang kontrol untuk kepatuhan dan keamanan.
  • Selain perlindungan Google bawaan, Anda dapat membuat pemantauan sendiri untuk mengidentifikasi dan menyelidiki aktivitas mencurigakan dalam bidang kontrol.
  • Memastikan bahwa hanya entity yang diotorisasi yang mengakses dan berinteraksi dengan cluster GKE Anda, yang meningkatkan postur keamanan Anda.
  • Melihat kapan identitas dibuat menggunakan kunci dan CA yang Anda kelola dengan menggunakan log penerbitan identitas di Cloud KMS dan CA Service. Gunakan log penggunaan Kubernetes API mendetail untuk melacak tindakan yang dilakukan identitas tersebut di cluster.

Dokumen berikut menunjukkan cara melihat dan memproses berbagai jenis log bidang kontrol:

Referensi tambahan tentang keamanan bidang kontrol

Bagian ini menjelaskan metode lain yang dapat Anda gunakan untuk meningkatkan keyakinan Anda terhadap keamanan bidang kontrol. Anda tidak perlu menggunakan otoritas bidang kontrol GKE untuk menggunakan resource berikut:

  • Integritas image VM bidang kontrol: GKE menambahkan log mendetail untuk peristiwa pembuatan dan booting VM node ke Cloud Logging. Selain itu, kami memublikasikan VSA SLSA di GitHub yang sesuai dengan image mesin node pekerja dan bidang kontrol. Anda dapat memverifikasi bahwa VM Anda menggunakan image OS yang memiliki VSA yang sesuai dan memverifikasi integritas booting setiap VM bidang kontrol.

    Untuk melakukan verifikasi integritas VM, lihat Memverifikasi integritas VM bidang kontrol GKE.

  • Tindakan keamanan bidang kontrol bawaan: GKE melakukan berbagai tindakan penguatan pada bidang kontrol terkelola. Untuk mempelajari lebih lanjut, lihat Keamanan bidang kontrol.

Langkah berikutnya