Otorisasi dan kontrol akses

Identity and Access Management (IAM) di Google Distributed Cloud (GDC) dengan air gap 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 membantu Anda mengelola akses secara efektif, memastikan anggota memiliki izin yang mereka butuhkan untuk menjalankan peran mereka sekaligus menjaga keamanan lingkungan dengan air gap Anda.

Dokumen ini ditujukan untuk audiens dalam grup administrator platform dan operator aplikasi (seperti administrator IT, engineer keamanan, atau developer aplikasi) yang ingin memahami otorisasi dan kontrol akses di GDC dengan air gap. Dokumen ini juga membantu operator infrastruktur membangun pemahaman dasar tentang konsep kontrol akses. Untuk mengetahui informasi selengkapnya, lihat Audiens untuk dokumentasi GDC dengan air gap.

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 siapa Anda (autentikasi) dan menentukan apa yang dapat Anda lakukan (otorisasi):

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

Anggota

Anggota adalah identitas yang dapat Anda berikan 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 terhubung ke sistem login yang ada di organisasi Anda, atau IdP (seperti Active Directory, LDAP, atau Okta), menggunakan protokol gabungan identitas standar seperti OpenID Connect (OIDC) atau SAML 2.0.

Ada dua jenis identitas manusia:

  • Pengguna: pengguna manusia individual yang login ke sistem menggunakan kredensial perusahaan mereka.
  • Grup: kumpulan pengguna manusia yang dikelola dalam IdP organisasi Anda. Memberikan peran kepada 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 antara IdP untuk memastikan Anda memberikan akses kepada orang yang tepat.

Saat mengelola akses, GDC 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, GDC IAM 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) untuk memungkinkan aplikasi, skrip, atau workload otomatis berinteraksi dengan API secara aman.

Karena akun layanan dikelola secara internal oleh GDC, akun layanan tidak menggunakan awalan IdP. Sebagai gantinya, akun layanan 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 otoritas untuk melakukan tindakan tertentu pada resource (misalnya, membuat VM atau menghapus database). Anda tidak memberikan izin kepada anggota secara langsung. Sebagai gantinya, GDC menggabungkan izin ke dalam peran.

GDC menawarkan dua jenis peran:

  • Peran bawaan: kumpulan izin bawaan yang dibuat dan dikelola oleh GDC. GDC menyediakan library 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: kumpulan izin yang ditentukan pengguna yang dapat Anda buat jika peran bawaan yang ada tidak memenuhi kebutuhan organisasi Anda.

Izin yang diberikan melalui peran IAM 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. Untuk membatasi atau menolak akses ke layanan tertentu di seluruh organisasi Anda, Anda dapat menyiapkan kebijakan organisasi.

Cakupan resource

Anda selalu memberikan akses pada tingkat hierarki resource GDC tertentu. Cakupan menentukan resource mana yang dapat diakses anggota. Di lingkungan multi-zona, peran yang ditetapkan pada cakupan mana pun akan otomatis berlaku di semua zona secara default.

Anda dapat memberikan peran pada cakupan resource berikut:

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

Untuk mengetahui informasi selengkapnya, lihat Hierarki resource dan Kontrol izin untuk universe multi-zona.

Cara akses diotorisasi

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 workload 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 kumpulan izin tertentu.
  • IAMRoleBinding: menautkan anggota (pengguna manusia, grup, atau akun layanan) ke IAMRole pada 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 pada cakupan project tersebut yang menautkan identitas anggota ke peran viewer. Saat anggota mencoba melihat virtual machine, GDC akan memeriksa binding peran aktifnya, mengonfirmasi bahwa peran yang ditetapkan berisi izin yang diperlukan, dan mengotorisasi permintaan tersebut.

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 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 dengan air gap.

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 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 yang mendasarinya yang mengevaluasi dan menerapkan izin. Terutama kontrol akses berbasis peran (RBAC) Kubernetes, tempat permintaan akses dievaluasi secara lokal oleh server API terhadap binding peran. Anda dapat menggunakan kebijakan organisasi untuk menetapkan batasan resource restrictions. 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 (aturan penolakan dapat dikonfigurasi secara terpisah melalui kebijakan organisasi). 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 yang dikelola secara terpusat oleh Google. Kredensial dapat di kelola secara otomatis oleh Google atau didownload sebagai file kunci untuk melakukan autentikasi 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
Cakupan izin multi-zona Cara izin dievaluasi dan disebarkan di seluruh zona ketersediaan atau region. Menggunakan RBAC Kubernetes yang dikelola oleh server API global, yang mengoordinasikan dan mereplikasi binding peran di seluruh server API zona sehingga akses berlaku di semua zona secara default. Menggunakan layanan IAM global yang terkelola sepenuhnya. Izin yang ditetapkan di tingkat resource mana pun secara inheren bersifat global dan berlaku di semua region dan zona secara otomatis.
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 gcloud atau endpoint REST/gRPC menggunakan kredensial terpusat (gcloud auth login) yang berlaku secara global di semua layanan tanpa memerlukan login khusus cluster.

Langkah berikutnya