Penyiapan pemberian izin desain

Dokumen ini menguraikan praktik terbaik untuk desain pemberian izin di lingkungan air-gapped Google Distributed Cloud (GDC). Topik-topik berikut akan dibahas:

Meskipun desain berikut direkomendasikan, Anda tidak harus mengikutinya persis seperti yang ditentukan. Setiap semesta GDC memiliki persyaratan dan pertimbangan unik yang harus dipenuhi berdasarkan kasus per kasus.

Mengonfigurasi penyedia identitas per organisasi

Operator harus mengonfigurasi satu atau beberapa penyedia identitas per organisasi. Kemudian, administrator menghubungkan ke penyedia identitas untuk mengelola layanan autentikasi bagi aplikasi di semesta GDC.

Anda mungkin memiliki skenario di mana perusahaan Anda memiliki beberapa departemen dengan organisasi terpisah, dan setiap organisasi terhubung ke penyedia identitas yang sama untuk autentikasi. Dalam hal ini, Anda bertanggung jawab untuk memahami dan mengaudit kombinasi hak istimewa yang dimiliki pengguna di seluruh organisasi. Pastikan pengguna dengan hak istimewa di beberapa organisasi tidak melanggar persyaratan untuk memisahkan workload ke dalam organisasi yang berbeda.

Atau, Anda mungkin memiliki skenario di mana berbagai kumpulan pengguna menggunakan penyedia identitas yang berbeda untuk melakukan autentikasi dalam satu organisasi, seperti saat beberapa tim vendor bekerja sama dalam satu organisasi. Pertimbangkan apakah menggabungkan identitas pengguna ke dalam satu penyedia identitas atau mempertahankan penyedia identitas terpisah paling sesuai dengan pendekatan perusahaan Anda terhadap pengelolaan identitas.

Mengonfigurasi autentikasi multi-faktor untuk penyedia identitas Anda

GDC mengandalkan platform IAM Anda untuk autentikasi, termasuk setelan keamanan tambahan seperti autentikasi multi-faktor. Sebaiknya konfigurasikan autentikasi multi-faktor dengan kunci fisik untuk setiap pengguna yang berpotensi mengakses resource sensitif.

Membatasi layanan terkelola dan layanan marketplace

Anda mungkin lebih memilih untuk memblokir beberapa project dari layanan tertentu, baik untuk membatasi potensi permukaan serangan dalam project atau menghindari penggunaan layanan yang tidak disetujui. Secara default, layanan terkelola seperti Kecerdasan Buatan dan Machine Learning dapat digunakan di project mana pun. Dibandingkan dengan layanan terkelola, layanan marketplace harus diaktifkan terlebih dahulu untuk organisasi.

Untuk menolak akses layanan dari project, terapkan batasan Gatekeeper terhadap definisi resource kustom layanan dan daftar namespace. Pendekatan untuk menolak akses dengan Gatekeeper berlaku untuk layanan terkelola dan marketplace.

Mengelola file kubeconfig untuk beberapa cluster

Tugas operasional yang berbeda memerlukan koneksi ke cluster yang berbeda. Misalnya, Anda melakukan tugas seperti mengikat peran IAM ke project, dan tugas seperti men-deploy resource Pod Kubernetes di cluster Kubernetes.

Saat menggunakan konsol GDC, Anda tidak perlu mengetahui cluster pokok mana yang menjalankan tugas, karena konsol GDC mengabstraksi operasi tingkat rendah seperti menghubungkan ke cluster.

Namun, saat bekerja dengan gdcloud CLI atau kubectl CLI, Anda mungkin memiliki beberapa file kubeconfig untuk menyelesaikan tugas. Pastikan Anda login menggunakan kredensial kubeconfig untuk cluster yang sesuai dengan tugas Anda.

Praktik terbaik untuk akun layanan Kubernetes

Untuk akun layanan Kubernetes, otorisasi didasarkan pada token rahasia. Untuk mengurangi risiko token akun layanan, pertimbangkan praktik terbaik berikut:

  • Hindari mendownload kredensial akun layanan persisten untuk digunakan di luar GDC.
  • Waspadai jalur eskalasi Kubernetes untuk pengguna atau akun layanan yang memiliki kemampuan untuk membuat dan mengedit pod.
  • Tetapkan kolom expirationSeconds ke jangka waktu singkat untuk proyeksi token akun layanan beban kerja Anda.
  • Rotasikan kredensial akun layanan secara rutin.

Mempertimbangkan prinsip hak istimewa terendah

Pertimbangkan prinsip hak istimewa terendah (PoLP) saat memberikan binding peran kepada pengguna. Sesuai dengan PoLP, pertimbangkan untuk hanya menetapkan hak istimewa yang diperlukan untuk menyelesaikan tugas.

Misalnya, Anda memberikan peran Project IAM Admin dalam satu project kepada pengguna, sehingga pengguna ini dapat mendelegasikan otoritas untuk memberikan peran dalam project tersebut. Pengguna ini kemudian memberikan peran terperinci kepada developer lain dalam project berdasarkan layanan tertentu yang mereka gunakan. Peran Project IAM Admin harus dibatasi untuk pemimpin tepercaya karena peran ini dapat digunakan untuk meningkatkan hak istimewa, memberikan peran tambahan kepada diri sendiri atau orang lain dalam project.

Lakukan audit secara rutin untuk hak istimewa yang berlebihan

Pastikan untuk meninjau peran yang diberikan dalam organisasi Anda dan melakukan audit terhadap hak istimewa yang berlebihan. Anda harus memastikan bahwa peran yang diberikan diperlukan bagi pengguna perorangan untuk menyelesaikan pekerjaannya, dan kombinasi peran di seluruh project tidak menimbulkan risiko eskalasi atau eksfiltrasi.

Jika perusahaan Anda menggunakan beberapa organisasi, sebaiknya jangan memberikan peran dengan hak istimewa tinggi kepada pengguna perorangan di beberapa organisasi, karena hal ini dapat melanggar alasan pemisahan organisasi sejak awal.