Otorisasi dan kontrol akses

Identity and Access Management (IAM) di perangkat air-gapped Google Distributed Cloud (GDC) memungkinkan Anda mengontrol siapa yang memiliki akses ke resource mana dan tindakan apa yang dapat mereka lakukan pada resource tersebut.

Memahami cara kerja IAM di GDC akan membantu Anda mengelola akses secara efektif, memastikan anggota memiliki izin yang mereka butuhkan untuk menjalankan peran mereka sekaligus menjaga keamanan lingkungan yang terisolasi dari internet.

Model kontrol akses

GDC menyusun akses di sekitar tiga komponen inti: anggota (siapa), peran (apa), dan cakupan resource (di mana).

Model kontrol akses

Kontrol akses terdiri dari dua tahap berbeda—membuktikan identitas Anda (autentikasi) dan menentukan hal yang dapat Anda lakukan (otorisasi):

  • Autentikasi: GDC tidak menyimpan akun atau sandi pengguna. GDC dapat memanfaatkan penyedia identitas (IdP) Keycloak yang disertakan atau terhubung ke IdP organisasi Anda sehingga Anda dapat login dengan kredensial Anda.
  • Otorisasi: setelah Anda melakukan autentikasi, GDC IAM akan memeriksa peran yang ditetapkan kepada Anda untuk menentukan resource yang dapat Anda akses dan tindakan yang dapat Anda lakukan.

Anggota

Anggota adalah identitas yang dapat Anda beri akses resource. GDC mengelompokkan anggota ke dalam dua kategori utama berdasarkan tempat Anda mengelolanya: identitas manusia dan identitas non-manusia.

Identitas manusia

Identitas manusia adalah pengguna dan grup yang login ke GDC. Daripada menyimpan akun atau sandi pengguna, GDC dapat memanfaatkan IdP Keycloak yang disertakan atau terhubung ke sistem login organisasi Anda yang sudah ada (seperti Active Directory, LDAP, atau Okta), menggunakan protokol federasi identitas standar seperti OpenID Connect (OIDC) atau SAML 2.0.

Ada dua jenis identitas manusia:

  • Pengguna: pengguna manusia perorangan yang login ke sistem menggunakan kredensial mereka.
  • Grup: kumpulan pengguna manusia yang dikelola dalam Keycloak atau IdP organisasi Anda. Memberikan peran ke grup akan otomatis memberikannya kepada semua anggota grup tersebut.

GDC menggunakan IdP untuk mengidentifikasi identitas manusia secara unik. Karena lingkungan Anda dapat terhubung ke beberapa IdP (misalnya, jika departemen yang berbeda menggunakan sistem login yang berbeda), GDC membedakan IdP untuk memastikan Anda memberikan akses kepada orang yang tepat.

Saat mengelola akses, GDC akan otomatis menambahkan awalan IdP unik ke semua nama pengguna dan grup eksternal:

  • Format: idpprefix-username@domain.com (atau idpprefix-group-name untuk grup).
  • Contoh: Jika IdP organisasi Anda dikonfigurasi dengan awalan agency-a, dan Anda login sebagai alice@example.com, IAM GDC akan mengenali Anda sebagai agency-a-alice@example.com.

Identitas non-manusia

Identitas non-manusia disebut identitas layanan (atau akun layanan). Anda membuat dan mengelolanya langsung dalam GDC (sebagai resource ProjectServiceAccount) agar aplikasi, skrip, atau beban kerja otomatis dapat berinteraksi dengan API secara aman.

Karena akun layanan dikelola secara internal oleh GDC, akun layanan tidak menggunakan awalan IdP. Sebagai gantinya, resource tersebut diidentifikasi berdasarkan project dan namanya (misalnya, serviceAccount:projectName:serviceAccountName saat menggunakan gdcloud CLI).

Untuk mengetahui informasi selengkapnya, lihat Mengamankan kunci akun layanan.

Izin dan peran

Izin adalah otorisasi untuk melakukan tindakan tertentu pada resource (misalnya, membuat VM atau menghapus database). Anda tidak memberikan izin kepada anggota secara langsung. Sebagai gantinya, GDC mengelompokkan izin ke dalam peran.

GDC menawarkan dua jenis peran:

  • Peran bawaan: kumpulan izin bawaan yang dibuat dan dikelola oleh GDC. GDC menyediakan kumpulan lengkap peran bawaan yang disesuaikan dengan fungsi dan layanan pekerjaan tertentu (mulai dari peran luas seperti Project Viewer hingga peran layanan terperinci seperti Bucket Project Admin atau KMS Viewer).
  • Peran khusus: paket izin yang ditentukan pengguna yang dapat Anda buat jika peran bawaan yang ada tidak memenuhi kebutuhan organisasi Anda.

Izin yang diberikan melalui peran IAM sepenuhnya bersifat tambahan; izin tersebut memberikan akses, tetapi tidak menyertakan aturan penolakan. Saat Anda memberikan beberapa peran kepada anggota, anggota tersebut akan menerima gabungan semua izin dalam peran tersebut.

Cakupan resource

Anda selalu memberikan akses pada tingkat hierarki resource GDC tertentu. Cakupan menentukan resource mana yang dapat diakses anggota.

Anda dapat memberikan peran pada cakupan resource berikut:

  • Organisasi: penampung tingkat teratas untuk lingkungan Anda. Peran yang diberikan di tingkat organisasi berlaku di seluruh organisasi, dan secara otomatis diwarisi oleh semua project dan resource di dalamnya.
  • Project: sebuah penampung dalam organisasi yang digunakan untuk mengelompokkan resource bagi tim atau aplikasi tertentu. Project berfungsi sebagai batas keamanan yang ketat—peran yang diberikan di tingkat project hanya berlaku untuk project tertentu tersebut dan resource-nya (seperti virtual machine, database, dan cluster Kubernetes).

Cara akses diizinkan

GDC mengelola dan mengotorisasi akses terutama menggunakan model kontrol akses berbasis peran (RBAC). Dalam model RBAC, Anda tidak menetapkan izin secara langsung kepada pengguna atau beban kerja individual. Sebagai gantinya, Anda menetapkan peran kepada anggota pada cakupan resource tertentu untuk menentukan akses.

GDC menerapkan RBAC menggunakan resource kustom Kubernetes berikut:

  • IAMRole: menentukan paket izin tertentu.
  • IAMRoleBinding: menautkan anggota (pengguna manusia, grup, atau akun layanan) ke IAMRole di cakupan organisasi atau project.

Untuk memberikan akses ke resource organisasi atau project, Anda dapat membuat IAMRoleBinding menggunakan konsol GDC, gdcloud CLI, atau dengan menerapkan manifes resource kustom (file YAML) menggunakan kubectl CLI.

Misalnya, untuk mengizinkan anggota tim melihat virtual machine dalam project, Anda dapat membuat IAMRoleBinding di cakupan project tersebut yang menautkan identitas anggota ke peran pelihat. Saat anggota mencoba melihat virtual machine, GDC akan memeriksa binding peran aktifnya, mengonfirmasi bahwa peran yang ditetapkan berisi izin yang diperlukan, dan mengizinkan permintaan.

Meskipun konsol GDC dan gdcloud CLI terhubung ke resource Anda secara otomatis, akses API langsung menggunakan kubectl CLI memerlukan autentikasi ke cluster Kubernetes atau server API tertentu yang menghosting resource tersebut dengan membuat file kubeconfig. Untuk mengetahui detailnya, lihat Login dan buat file kubeconfig.

Untuk mengetahui informasi selengkapnya tentang cara mengelola binding peran, lihat Memberikan dan mencabut akses.

Perbedaan IAM GDC dengan air gap dan Google Cloud

Jika Anda memiliki pengalaman mengelola akses di Google Cloud, GDC menggunakan konsep serupa, tetapi menerapkannya secara berbeda untuk beroperasi dalam infrastruktur berbasis Kubernetes yang terisolasi.

Tabel berikut memberikan perbandingan antara IAM di GDC dan Google Cloud:

Fitur Deskripsi GDC dengan air gap Google Cloud
Identitas pengguna (autentikasi) Sistem identitas yang digunakan untuk mengautentikasi pengguna manusia. Digabungkan dengan IdP eksternal Anda atau dikelola dengan IdP Keycloak yang disertakan, menggunakan awalan IdP yang diperlukan (misalnya, idpprefix-user@domain.com). Akun Google (seperti Gmail) atau identitas perusahaan yang digabungkan melalui Cloud Identity atau Google Workspace.
Mesin otorisasi Sistem pokok yang mengevaluasi dan menerapkan izin. Terutama role-based access control (RBAC) Kubernetes, tempat permintaan akses dievaluasi secara lokal oleh server API terhadap binding peran. Layanan Cloud IAM global Google. Mengevaluasi permintaan API secara terpusat terhadap kebijakan akses yang dilampirkan di tingkat hierarki resource mana pun.
Binding peran Cara anggota dipetakan ke peran pada resource tertentu. Resource kustom IAMRoleBinding individual. Setiap binding adalah objek yang menautkan anggota ke satu peran. Izin peran IAM bersifat tambahan. Satu kebijakan akses IAM yang dilampirkan ke setiap resource, folder, atau organisasi. Berisi beberapa binding yang memetakan anggota ke peran, dan mendukung aturan bersyarat atau aturan penolakan.
Akun layanan Identitas non-manusia yang digunakan oleh aplikasi dan workload otomatis. Akun layanan lokal yang dibuat di dalam project tertentu (ProjectServiceAccount). Kunci publik disimpan di cluster, sedangkan kunci pribadi dikelola dan diamankan secara lokal oleh klien. Identitas global dikelola secara terpusat oleh Google. Kredensial dapat dikelola secara otomatis oleh Google atau didownload sebagai file kunci untuk mengautentikasi dari mana saja.
Hierarki resource Struktur penampung yang digunakan untuk mengatur resource dan mewarisi izin. Hierarki dua tingkat: organisasi > project Hierarki multi-tingkat: organisasi > folder > project
Alat klien Antarmuka utama, alat CLI, dan API yang digunakan untuk mengelola akses. Konsol GDC, gdcloud CLI, dan KRM API. Google Cloud konsol, gcloud CLI, dan REST atau gRPC API.
Akses API langsung Cara alat dan skrip melakukan autentikasi untuk mengelola resource secara langsung menggunakan API. Akses API langsung menggunakan kubectl CLI memerlukan autentikasi ke cluster Kubernetes atau server API tertentu yang menghosting resource tersebut dengan membuat file kubeconfig. (Konsol GDC dan gdcloud CLI terhubung ke resource secara otomatis.) Akses API langsung menggunakan endpoint gcloud atau REST/gRPC menggunakan kredensial terpusat (gcloud auth login) yang berlaku secara global di semua layanan tanpa memerlukan login khusus cluster.

Langkah berikutnya