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 tertentu 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 diperlukan untuk menjalankan peran mereka sekaligus menjaga keamanan lingkungan air-gap Anda.

Dokumen ini ditujukan untuk audiens dalam grup administrator platform dan Operator Aplikasi (seperti admin 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 berdasarkan tiga komponen inti: anggota (siapa), peran (apa), dan cakupan resource (di mana).

Model kontrol akses

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

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

Anggota

Anggota adalah identitas yang dapat Anda beri akses ke 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. Alih-alih menyimpan akun pengguna atau sandi, GDC terhubung ke sistem login atau IdP yang ada di organisasi Anda (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 perusahaan mereka.
  • Grup: kumpulan pengguna manusia yang dikelola dalam 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 secara 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 workload otomatis dapat berinteraksi dengan API secara aman.

Karena akun layanan dikelola secara internal oleh GDC, akun tersebut tidak menggunakan awalan IdP. Sebagai gantinya, resource 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). Izin tidak dapat diberikan kepada anggota secara langsung. Sebagai gantinya, GDC menggabungkan izin ke dalam peran.

GDC menawarkan dua jenis peran:

  • Peran bawaan: paket 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: 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. Untuk membatasi atau menolak akses ke layanan tertentu di seluruh organisasi, Anda dapat menyiapkan kebijakan organisasi.

Cakupan resource

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

Anda dapat memberikan peran pada cakupan resource berikut:

  • Organisasi: container tingkat teratas untuk lingkungan Anda. Peran yang diberikan di level organisasi berlaku di seluruh organisasi, dan otomatis diwariskan ke semua project dan resource di dalamnya.
  • Project: container dalam organisasi yang digunakan untuk mengelompokkan resource bagi tim atau aplikasi tertentu. Project berfungsi sebagai batas keamanan yang ketat—peran yang diberikan di level 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 diizinkan

GDC mengelola dan mengizinkan akses terutama menggunakan model kontrol akses berbasis peran (RBAC). Dalam model RBAC, Anda tidak menetapkan izin 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 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 viewer. Saat anggota mencoba melihat virtual machine, GDC memeriksa binding peran aktifnya, mengonfirmasi bahwa peran yang ditetapkan berisi izin yang diperlukan, dan mengizinkan 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 membuat file kubeconfig.

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

Perbedaan IAM GDC dengan air gap dari 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 air-gapped.

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 dasar yang mengevaluasi dan menerapkan izin. Terutama role-based access control (RBAC) Kubernetes, tempat permintaan akses dievaluasi secara lokal oleh server API terhadap binding peran. Anda dapat menggunakan kebijakan organisasi untuk menetapkan batasan resource. Layanan Cloud IAM global Google. Mengevaluasi permintaan API secara terpusat terhadap kebijakan akses yang dilampirkan di tingkat mana pun dalam hierarki resource.
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 sepenuhnya 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 dikelola secara otomatis oleh Google atau didownload sebagai file kunci untuk melakukan autentikasi dari mana saja.
Hierarki resource Struktur container 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 diterapkan 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 bersifat global dan otomatis berlaku di semua region dan zona.
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