Kebijakan batas akses akun utama (PAB) memungkinkan Anda membatasi resource yang dapat diakses akun utama.
Misalnya, Anda dapat menggunakan kebijakan batas akses akun utama untuk mencegah akun utama Anda mengakses resource di organisasi lain, yang dapat membantu mencegah serangan phishing atau pemindahan data yang tidak sah.
Untuk mempelajari jenis kebijakan kontrol akses lainnya yang ditawarkan Identity and Access Management (IAM), lihat Jenis kebijakan.
Cara kerja kebijakan batas akses akun utama
Secara default, akun utama memenuhi syarat untuk mengakses resource Google Cloud apa pun. Artinya, jika akun utama memiliki izin pada resource dan tidak ditolak izin tersebut, akun utama dapat menggunakan izin tersebut untuk mengakses resource.
Dengan kebijakan batas akses akun utama, Anda dapat membatasi resource yang layak diakses oleh akun utama. Jika kebijakan batas akses akun utama membuat akun utama tidak memenuhi syarat untuk mengakses resource, aksesnya ke resource tersebut akan dibatasi, terlepas dari peran yang diberikan kepadanya.
Saat akun utama mencoba mengakses resource yang tidak memenuhi syarat untuk diakses, kebijakan batas akses akun utama dapat memblokir beberapa, tetapi tidak semua, izin Identity and Access Management (IAM). Untuk mempelajari lebih lanjut izin yang diblokir, lihat Izin yang dapat diblokir oleh batas akses akun utama.
Kebijakan batas akses akun utama terdiri dari aturan batas akses akun utama. Setiap aturan batas akses akun utama menentukan kumpulan resource yang memenuhi syarat untuk diakses oleh akun utama yang terpengaruh. Anda dapat membuat hingga 1.000 kebijakan batas akses akun utama di organisasi Anda.
Setelah membuat kebijakan batas akses akun utama, Anda membuat binding kebijakan untuk menerapkan kebijakan ke kumpulan akun utama.
Akun utama dapat tunduk pada satu atau beberapa kebijakan batas akses akun utama. Setiap akun utama hanya memenuhi syarat untuk mengakses resource yang tercantum dalam kebijakan tersebut. Untuk semua resource lainnya, akses akun utama ke resource tersebut terbatas, meskipun Anda memberikan peran ke akun utama di resource tersebut.
Karena kebijakan batas akses akun utama dikaitkan dengan akun utama, bukan dengan resource, Anda dapat menggunakannya untuk mencegah akun utama mengakses resource yang tidak Anda miliki. Misalnya, perhatikan skenario berikut:
- Kepala sekolah Tal (
tal@altostrat.com
) adalah bagian dari organisasi Google Workspacealtostrat.com
. - Tal diberi peran Storage Admin (
roles/storage.admin
) di bucket Cloud Storage di organisasi lain,cymbalgroup.com
. Peran ini berisi izinstorage.objects.get
, yang diperlukan untuk melihat objek di bucket. - Tidak ada kebijakan tolak di
cymbalgroup.com
yang mencegah Tal menggunakan izinstorage.objects.get
.
Dengan kebijakan izinkan dan tolak saja, altostrat.com
tidak dapat mencegah Tal
melihat objek di bucket eksternal ini. Tidak ada akun utama altostrat.com
yang memiliki izin untuk mengedit kebijakan izin bucket, sehingga mereka tidak dapat mencabut peran Tal. Mereka juga tidak memiliki izin untuk membuat kebijakan penolakan di
cymbalgroup.com
, sehingga mereka tidak dapat menggunakan kebijakan penolakan untuk mencegah Tal mengakses
bucket.
Namun, dengan kebijakan batas akses akun utama, administrator altostrat.com
dapat memastikan bahwa Tal tidak dapat melihat objek di bucket cymbalgroup.com
, atau bucket apa pun di luar altostrat.com
. Untuk melakukannya, administrator dapat membuat
kebijakan batas akses akun utama yang menyatakan bahwa akun utama altostrat.com
hanya
memenuhi syarat untuk mengakses resource di altostrat.com
. Kemudian, mereka dapat membuat binding kebijakan untuk melampirkan kebijakan ini ke semua akun utama di organisasi altostrat.com
. Dengan kebijakan tersebut, Tal tidak akan dapat melihat objek
di bucket cymbalgroup.com
, meskipun ia diberi peran Admin
Storage di bucket.
Evaluasi fail-open
Selama Rilis pratinjau kebijakan batas akses akun utama, kebijakan batas akses akun utama akan gagal terbuka. Artinya, jika IAM tidak dapat mengevaluasi kebijakan batas akses akun utama, IAM akan mengabaikan kebijakan batas akses akun utama dan melanjutkan untuk mengevaluasi kebijakan izin dan tolak yang relevan.
Izin yang diblokir oleh kebijakan batas akses akun utama
Saat akun utama mencoba mengakses resource yang tidak memenuhi syarat untuk diakses, kebijakan batas akses akun utama akan mencegahnya menggunakan beberapa, tetapi tidak semua, izin Identity and Access Management (IAM) untuk mengakses resource.
Jika kebijakan batas akses akun utama memblokir izin, IAM akan menerapkan kebijakan batas akses akun utama untuk izin tersebut. Dengan kata lain, kebijakan ini mencegah akun utama yang tidak memenuhi syarat untuk mengakses resource agar tidak menggunakan izin tersebut untuk mengakses resource.
Jika kebijakan batas akses akun utama tidak memblokir izin, maka kebijakan batas akses akun utama tidak akan memengaruhi apakah akun utama dapat menggunakan izin tersebut.
Misalnya, bayangkan bahwa akun utama, Lee (lee@example.com
), diberi peran Developer Dataflow (roles/dataflow.developer
). Peran ini mencakup izin dataflow.jobs.snapshot
, yang memungkinkan Lee mengambil snapshot tugas Dataflow. Lee juga tunduk pada kebijakan batas akses akun utama yang
membuat dia tidak memenuhi syarat untuk mengakses resource di luar example.com
. Namun, jika
kebijakan batas akses akun utama tidak memblokir izin dataflow.jobs.snapshot
, Lee masih dapat mengambil snapshot tugas Dataflow di
organisasi di luar example.com
.
Izin yang diblokir oleh kebijakan batas akses akun utama bergantung pada versi penegakan batas akses akun utama.
Versi penerapan batas akses akun utama
Setiap kebijakan batas akses akun utama menentukan versi penerapan, yang mengidentifikasi daftar izin IAM standar yang dapat diblokir oleh kebijakan batas akses akun utama. Anda menentukan versi penerapan saat membuat atau memperbarui kebijakan batas akses akun utama. Jika Anda tidak menentukan versi penerapan, IAM akan menggunakan versi penerapan terbaru, dan akan terus menggunakan versi tersebut hingga Anda mengupdatenya.
Secara berkala, IAM menambahkan versi penegakan batas akses akun utama baru yang dapat memblokir izin tambahan. Setiap versi baru juga dapat memblokir semua izin di versi sebelumnya.
Untuk memblokir izin dalam versi penerapan baru, Anda harus memperbarui
kebijakan batas akses akun utama untuk menggunakan versi baru. Jika Anda ingin versi penerapan
diupdate secara otomatis saat versi baru dirilis, Anda dapat menggunakan
nilai latest
saat membuat kebijakan. Namun, sebaiknya jangan gunakan nilai
ini, karena dapat menyebabkan akun utama kehilangan akses ke resource
secara tidak terduga.
Untuk mengetahui daftar lengkap izin yang diblokir oleh setiap versi penerapan, lihat Izin yang diblokir oleh kebijakan batas akses akun utama.
Mengikat kebijakan batas akses akun utama ke kumpulan akun utama
Untuk mengikat kebijakan batas akses akun utama ke kumpulan akun utama, Anda harus membuat binding kebijakan yang menentukan kebijakan batas akses akun utama yang ingin diterapkan dan kumpulan akun utama yang ingin Anda terapkan. Setelah Anda mengikat kebijakan ke set akun utama, akun utama dalam set akun utama tersebut hanya dapat mengakses resource yang disertakan dalam aturan kebijakan batas akses akun utama.
Anda dapat mengikat kebijakan batas akses akun utama ke sejumlah kumpulan akun utama. Setiap kumpulan akun utama dapat memiliki hingga 10 kebijakan batas akses utama yang terikat.
Untuk mempelajari cara mengelola kebijakan batas akses akun utama, lihat Membuat dan menerapkan kebijakan batas akses akun utama.
Set akun utama yang didukung
Tabel berikut mencantumkan jenis kumpulan akun utama yang dapat Anda ikat ke kebijakan batas akses akun utama. Setiap baris berisi hal berikut:
- Jenis akun utama yang ditetapkan
- Akun utama dalam jenis kumpulan akun utama tersebut
- Format ID untuk jenis kumpulan akun utama tersebut
- Resource Pengelola Resource (project, folder, atau organisasi) yang menjadi induk binding kebijakan untuk jenis akun utama yang ditetapkan
Kumpulan akun utama | Detail | Resource induk binding kebijakan |
---|---|---|
Kumpulan identitas tenaga kerja |
Berisi semua identitas dalam workforce identity pool yang ditentukan.
Format: |
Organisasi yang berisi kumpulan identitas tenaga kerja |
Workload identity pool |
Berisi semua identitas dalam workload identity pool yang ditentukan.
Format: |
Project yang berisi workload identity pool |
Domain Google Workspace |
Berisi semua identitas di domain Google Workspace yang ditentukan.
Format: Anda dapat menemukan ID ruang kerja menggunakan metode berikut:
|
Organisasi yang terkait dengan domain Google Workspace |
Kumpulan akun utama project |
Berisi semua akun layanan dan workload identity pool dalam project yang ditentukan.
Format: |
Project |
Kumpulan akun utama folder |
Berisi semua akun layanan dan semua workload identity pool dalam project apa pun di folder yang ditentukan.
Format: |
Folder |
Kumpulan akun utama organisasi |
Berisi identitas berikut:
Format: |
Organisasi |
Binding kebijakan bersyarat untuk kebijakan batas akses akun utama
Anda dapat menggunakan ekspresi kondisi dalam binding kebijakan untuk kebijakan batas akses akun utama guna lebih memfilter akun utama yang menjadi sasaran kebijakan.
Ekspresi kondisi untuk binding kebijakan terdiri dari satu atau beberapa pernyataan
yang digabungkan dengan maksimal 10 operator
logis (&&
, ||
, atau !
). Setiap pernyataan menyatakan aturan kontrol
berbasis atribut yang berlaku untuk binding kebijakan, dan pada akhirnya menentukan
apakah kebijakan berlaku.
Anda dapat menggunakan atribut principal.type
dan principal.subject
dalam
kondisi untuk binding kebijakan. Tidak ada atribut lain yang didukung dalam kondisi
untuk binding kebijakan.
Atribut
principal.type
menunjukkan jenis akun utama dalam permintaan—misalnya, akun layanan, atau identitas dalam workload identity pool. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol jenis akun utama mana yang akan diterapkan kebijakan batas akses akun utama.Misalnya, jika Anda menambahkan ekspresi kondisi berikut ke binding untuk kebijakan batas akses akun utama, kebijakan tersebut hanya berlaku untuk akun layanan:
principal.type == 'iam.googleapis.com/ServiceAccount'
Atribut
principal.subject
menunjukkan identitas akun utama dalam permintaan—misalnya,cruz@example.com
. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol dengan tepat akun utama mana yang tunduk pada kebijakan batas akses akun utama.Misalnya, jika Anda menambahkan ekspresi kondisi berikut ke binding untuk kebijakan batas akses akun utama, kebijakan tersebut tidak akan berlaku untuk pengguna
special-admin@example.com
:principal.subject != 'special-admin@example.com'
Untuk mempelajari lebih lanjut nilai yang dapat Anda gunakan untuk kondisi ini, lihat referensi atribut kondisi.
Contoh: Menggunakan kondisi untuk mengurangi resource yang memenuhi syarat untuk diakses oleh akun utama
Salah satu cara Anda dapat menggunakan kondisi dalam binding kebijakan batas akses akun utama adalah dengan mengurangi resource yang memenuhi syarat untuk diakses oleh satu akun utama.
Bayangkan Anda memiliki akun layanan, dev-project-service-account
, dengan alamat email dev-project-service-account@dev-project.
. Akun layanan ini tunduk pada
kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses semua resource
di organisasi example.com
. Kebijakan ini dilampirkan ke
kumpulan akun utama organisasi example.com
.
Anda memutuskan bahwa Anda tidak ingin dev-project-service-account
memenuhi syarat untuk
mengakses semua resource di example.com
—Anda hanya ingin dev-project-service-account
memenuhi syarat untuk
mengakses resource di dev-project
. Namun, Anda tidak ingin mengubah
resource yang memenuhi syarat untuk diakses oleh akun utama lain dalam kumpulan akun utama example.com
.
Untuk melakukan perubahan ini, Anda mengikuti prosedur untuk mengurangi resource yang layak diakses oleh akun utama, tetapi Anda menambahkan kondisi ke binding kebijakan, bukan menghapusnya:
- Anda mengonfirmasi bahwa satu-satunya kebijakan batas akses akun utama yang
diikuti
dev-project-service-account
adalah kebijakan yang membuat akun utama memenuhi syarat untuk mengakses semua resource diexample.com
. Anda membuat kebijakan batas akses akun utama baru yang membuat akun utama memenuhi syarat untuk mengakses resource di
dev-project
dan melampirkannya ke akun utama yang ditetapkan untukdev-project
. Anda menggunakan kondisi berikut dalam binding kebijakan untuk memastikan bahwa kebijakan hanya diterapkan untukdev-project-service-account
:"condition": { "title": "Only dev-project-service-account", "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.'" }
Anda mengecualikan
dev-project-service-account
dari kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses semua resource diexample.com
. Untuk melakukannya, tambahkan kondisi berikut ke binding kebijakan yang melampirkan kebijakan batas akses akun utama tersebut ke kumpulan akun utama organisasi:"condition": { "title": "Exempt dev-project-service-account", "expression": "principal.subject != 'dev-project-service-account@dev-project.' || principal.type != 'iam.googleapis.com/ServiceAccount'" }
Untuk mempelajari cara memperbarui kebijakan batas akses akun utama yang ada, lihat Mengedit kebijakan batas akses akun utama.
Setelah Anda menambahkan kondisi ini ke binding kebijakan,
dev-project-service-account
tidak lagi memenuhi syarat untuk mengakses semua resource di
example.com
—sebaliknya, dev-project-service-account
hanya memenuhi syarat untuk mengakses resource di
dev-project
.
Interaksi kebijakan
IAM mengevaluasi setiap kebijakan batas akses akun utama bersama dengan kebijakan izin dan tolak, serta dengan kebijakan batas akses akun utama lainnya. Semua kebijakan ini digunakan untuk menentukan apakah akun utama dapat mengakses resource.
Interaksi dengan jenis kebijakan lain
Saat akun utama mencoba mengakses resource, IAM mengevaluasi semua kebijakan batas akses akun utama, izinkan, dan tolak yang relevan untuk melihat apakah akun utama diizinkan untuk mengakses resource. Jika salah satu kebijakan ini menunjukkan bahwa akun utama tidak boleh mengakses resource, IAM akan mencegah akses.
Akibatnya, jika kebijakan batas akses akun utama akan mencegah akun utama mengakses resource, IAM akan mencegahnya mengakses resource tersebut, terlepas dari kebijakan izin dan tolak yang dilampirkan ke resource.
Selain itu, kebijakan batas akses akun utama saja tidak memberi akun utama akses ke resource. Meskipun kebijakan batas akses akun utama dapat membuat akun utama memenuhi syarat untuk mengakses resource, hanya kebijakan izin yang benar-benar dapat memberikan akses ke resource kepada akun utama.
Untuk mempelajari evaluasi kebijakan IAM lebih lanjut, lihat Evaluasi kebijakan.
Interaksi antara kebijakan batas akses akun utama
Jika kebijakan batas akses akun utama membuat akun utama memenuhi syarat untuk mengakses resource, akun utama tersebut memenuhi syarat untuk mengakses resource tersebut, terlepas dari kebijakan batas akses akun utama lainnya yang berlaku untuk akun utama tersebut. Akibatnya, jika akun utama sudah tunduk pada kebijakan batas akses akun utama, Anda tidak dapat menambahkan kebijakan batas akses akun utama untuk mengurangi akses akun utama.
Misalnya, bayangkan bahwa akun utama, Dana (dana@example.com
), tunduk pada
satu kebijakan batas akses akun utama, prod-projects-policy
. Kebijakan ini
membuat akun utama memenuhi syarat untuk mengakses resource di prod-project
. Dana tunduk
pada kebijakan ini karena terikat dengan kumpulan akun utama organisasinya.
Anda membuat kebijakan batas akses akun utama baru, dev-staging-projects-policy
, yang
membuat akun utama memenuhi syarat untuk mengakses resource di dev-project
dan
staging-project
, lalu mengikatkannya ke kumpulan akun utama organisasi.
Sebagai akibat dari kebijakan batas akses akun utama ini, Dana memenuhi syarat untuk mengakses
resource di dev-project
, staging-project
, dan prod-project
.
Jika ingin mengurangi resource yang memenuhi syarat untuk diakses Dana, Anda harus mengubah atau menghapus kebijakan batas akses akun utama yang berlaku untuk Dana.
Misalnya, Anda dapat mengedit dev-staging-projects-policy
sehingga tidak
membuat akun utama memenuhi syarat untuk mengakses resource di dev-project
. Kemudian, Dana hanya akan
memenuhi syarat untuk mengakses resource di staging-project
dan prod-project
.
Atau, Anda dapat menghapus prod-projects-policy
dengan menghapus binding kebijakan yang mengikat akun utama ke kumpulan akun utama organisasi. Kemudian, Dana hanya
akan memenuhi syarat untuk mengakses resource di dev-project
dan staging-project
.
Namun, perubahan ini tidak hanya memengaruhi Dana—perubahan ini juga memengaruhi akun utama lain yang tunduk pada kebijakan dan binding batas akses akun utama yang diubah. Jika Anda ingin mengurangi resource yang dapat diakses oleh satu akun utama, gunakan binding kebijakan bersyarat.
Pewarisan kebijakan
Kebijakan batas akses akun utama dilampirkan ke set akun utama, bukan resource Resource Manager. Akibatnya, kebijakan tersebut tidak diwariskan melalui hierarki resource dengan cara yang sama seperti kebijakan izin dan tolak.
Namun, set akun utama untuk resource induk Pengelola Resource—yaitu, folder dan organisasi—selalu menyertakan semua akun utama dalam set akun utama turunannya. Jadi, misalnya, jika akun utama disertakan dalam set akun utama project, akun utama tersebut juga disertakan dalam set akun utama dari folder atau organisasi induk.
Misalnya, pertimbangkan organisasi, example.com
. Organisasi ini
dikaitkan dengan domain example.com
, dan memiliki resource Resource Manager
berikut:
- Organisasi,
example.com
- Project,
project-1
, yang merupakan turunan dari organisasi - Folder,
folder-a
, yang merupakan turunan dari organisasi - Dua project,
project-2
danproject-3
, yang merupakan turunan darifolder-a
Kumpulan akun utama resource ini berisi identitas berikut:
Kumpulan akun utama | Identitas Google Workspace di domain example.com |
Kumpulan workforce identity federation di example.com |
Akun layanan dan workload identity pool di project-1 |
Akun layanan dan workload identity pool di project-2 |
Akun layanan dan workload identity pool di project-3 |
---|---|---|---|---|---|
Prinsipal ditetapkan untuk example.com |
|||||
Prinsipal ditetapkan untuk folder-a |
|||||
Prinsipal ditetapkan untuk project-1 |
|||||
Prinsipal ditetapkan untuk project-2 |
|||||
Prinsipal ditetapkan untuk project-3 |
Akibatnya, akun utama berikut terpengaruh oleh kebijakan batas akses akun utama berikut:
Identitas Google Workspace di domain
example.com
berada dalam kumpulan akun utama untukexample.com
dan akan terpengaruh oleh kebijakan batas akses utama yang terikat dengan kumpulan akun utama tersebut.Akun layanan di
project-1
berada dalam kumpulan akun utama untukproject-1
danexample.com
dan akan terpengaruh oleh kebijakan batas akses utama yang terikat ke salah satu kumpulan akun utama tersebut.Akun layanan di
project-3
berada dalam kumpulan akun utama untukproject-3
,folder-a
, danexample.com
, dan akan terpengaruh oleh kebijakan batas akses akun utama yang terikat ke salah satu kumpulan akun utama tersebut.
Kebijakan batas akses akun utama dan resource yang di-cache
Layanan Google Cloud tertentu menyimpan cache resource yang dapat dilihat oleh publik. Misalnya, Cloud Storage menyimpan objek dalam cache yang dapat dibaca secara publik.
Apakah batas akses akun utama dapat mencegah akun utama yang tidak memenuhi syarat untuk melihat resource yang terlihat secara publik bergantung pada apakah resource di-cache:
- Jika resource di-cache, batas akses akun utama tidak dapat mencegah akun utama melihat resource
- Jika resource tidak di-cache, batas akses akun utama akan mencegah akun utama yang tidak memenuhi syarat melihat resource
Dalam semua kasus, kebijakan batas akses akun utama mencegah akun utama yang tidak memenuhi syarat untuk mengubah atau menghapus resource yang terlihat secara publik.
Struktur kebijakan batas akses akun utama
Kebijakan batas akses akun utama adalah kumpulan metadata dan detail kebijakan batas akses akun utama. Metadata memberikan informasi seperti nama kebijakan dan kapan kebijakan dibuat. Detail kebijakan menentukan fungsi kebijakan—misalnya, resource yang memenuhi syarat untuk diakses oleh akun utama yang terpengaruh.
Misalnya, kebijakan batas akses akun utama berikut membuat akun utama yang
tunduk pada kebijakan tersebut memenuhi syarat untuk mengakses resource di organisasi
dengan ID 0123456789012
.
{
"name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
"uid": "puid_0123456789012345678",
"etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
"displayName": "Example policy",
"annotations": {
"example-key": "example-value"
},
"createTime": "2024-01-02T15:01:23Z",
"updateTime": "2024-01-02T15:01:23Z",
"details": {
"rules": [
{
"description": "Example principal access boundary policy rule",
"resources": [
"//cloudresourcemanager.googleapis.com/organizations/0123456789012"
],
"effect": "ALLOW"
}
],
"enforcementVersion": "1"
}
}
Bagian berikut menjelaskan kolom dalam metadata dan detail kebijakan batas akses utama.
Metadata
Kebijakan batas akses akun utama berisi metadata berikut:
name
: Nama kebijakan batas akses akun utama. Nama ini memiliki formatorganizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID
, denganORGANIZATION_ID
adalah ID numerik organisasi tempat kebijakan batas akses akun utama dibuat danPAB_POLICY_ID
adalah ID alfanumerik kebijakan batas akses akun utama.uid
: ID unik yang ditetapkan untuk kebijakan batas akses akun utama.etag
: ID untuk status kebijakan saat ini. Nilai ini berubah saat Anda memperbarui kebijakan. Untuk mencegah update yang bertentangan, nilaietag
harus cocok dengan nilai yang disimpan di IAM. Jika nilaietag
tidak cocok, permintaan akan gagal.displayName
: Nama yang dapat dibaca manusia untuk kebijakan batas akses akun utama.annotations
: Opsional. Daftar key-value pair yang ditentukan pengguna. Anda dapat menggunakan anotasi ini untuk menambahkan metadata tambahan ke kebijakan—misalnya, siapa yang membuat kebijakan, atau apakah kebijakan di-deploy oleh pipeline otomatis. Untuk mengetahui informasi selengkapnya tentang anotasi, lihat Anotasi.createTime
: Waktu saat kebijakan batas akses akun utama dibuat.updateTime
: Waktu saat kebijakan batas akses akun utama terakhir diperbarui.
Detail
Setiap kebijakan batas akses akun utama berisi kolom details
. Kolom ini berisi
versi penerapan dan aturan batas akses utama:
rules
: Daftar aturan batas akses akun utama, yang menentukan resource yang layak diakses oleh akun utama yang terpengaruh. Setiap aturan berisi kolom berikut:description
: Deskripsi aturan yang dapat dibaca manusia.resources
: Daftar resource Resource Manager (project, folder, dan organisasi) yang Anda inginkan agar dapat diakses oleh akun utama. Setiap prinsipal yang tunduk pada kebijakan ini memenuhi syarat untuk mengakses resource ini.Setiap kebijakan batas akses akun utama dapat mereferensikan maksimal 500 resource di semua aturan dalam kebijakan.
effect
: Hubungan yang dimiliki akun utama dengan resource yang tercantum di kolomresources
. Satu-satunya efek yang dapat Anda tentukan dalam aturan batas akses akun utama adalah"ALLOW"
. Hubungan ini membuat akun utama memenuhi syarat untuk mengakses resource yang tercantum dalam aturan.
enforcementVersion
: Versi penegakan yang digunakan IAM saat menerapkan kebijakan. Versi kebijakan batas akses akun utama menentukan izin yang dapat diblokir oleh kebijakan batas akses akun utama.Untuk mengetahui informasi selengkapnya tentang versi kebijakan batas akses akun utama, lihat Versi penerapan batas akses akun utama di halaman ini.
Struktur binding kebijakan
Binding kebijakan untuk kebijakan batas akses akun utama berisi nama kebijakan, nama akun utama yang ditetapkan untuk mengikat kebijakan, dan metadata yang menjelaskan binding kebijakan. Kebijakan ini juga dapat berisi kondisi yang mengubah akun utama yang menjadi sasaran kebijakan.
Misalnya, binding kebijakan berikut mengikat kebijakan example-policy
ke
semua akun utama di organisasi example.com
, yang memiliki ID
0123456789012
. Binding kebijakan juga berisi kondisi yang mencegah
kebijakan diterapkan untuk akun utama super-admin@example.com
.
{
"name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
"uid": "buid_01234567890123456789",
"etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
"displayName": "Example policy binding",
"annotations": {
"example-key": "example-value"
},
"target": {
"principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
},
"policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
"policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
"policyUid": "puid_0123456789012345678",
"condition": {
"title": "Exempt principal",
"description": "Don't enforce the policy for super-admin@example.com",
"expression": "principal.subject != 'super-admin@example.com'"
},
"createTime": "2024-01-02T17:00:16Z",
"updateTime": "2024-01-02T17:00:16Z"
}
Setiap binding kebijakan berisi kolom berikut:
name
: Nama binding kebijakan. Nama ini memiliki formatRESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID
, denganRESOURCE_TYPE/RESOURCE_ID
adalah jenis dan ID resource induk binding kebijakan danBINDING_ID
adalah ID alfanumerik binding kebijakan.uid
: ID unik yang ditetapkan untuk binding kebijakan.etag
: ID untuk status kebijakan saat ini. Nilai ini berubah saat Anda memperbarui kebijakan. Untuk mencegah update yang bertentangan, nilaietag
harus cocok dengan nilai yang disimpan di IAM. Jika nilaietag
tidak cocok, permintaan akan gagal.displayName
: Nama yang dapat dibaca manusia untuk binding kebijakan.annotations
: Opsional. Daftar key-value pair yang ditentukan pengguna. Anda dapat menggunakan anotasi ini untuk menambahkan metadata tambahan ke binding kebijakan—misalnya, siapa yang membuat binding kebijakan, atau apakah binding kebijakan di-deploy oleh pipeline otomatis. Untuk mengetahui informasi selengkapnya tentang anotasi, lihat Anotasi.target
: Entitas utama yang ditetapkan untuk mengikat kebijakan. Nilai ini memiliki format{"principalSet": PRINCIPAL_SET}
, denganPRINCIPAL_SET
adalah ID kumpulan akun utama yang ingin Anda ikat dengan kebijakan.Setiap target dapat memiliki hingga 10 kebijakan yang terikat dengannya.
policyKind
: Jenis kebijakan yang dirujuk oleh binding kebijakan. Untuk binding kebijakan untuk kebijakan batas akses akun utama, nilai ini selaluPRINCIPAL_ACCESS_BOUNDARY
.policy
: Kebijakan batas akses akun utama untuk mengikat ke kumpulan akun utama target.policyUid
: ID unik yang ditetapkan untuk kebijakan batas akses akun utama yang dirujuk di kolompolicy
.condition
: Opsional. Ekspresi logika yang memengaruhi akun utama yang akan dikenai kebijakan IAM. Jika kondisi bernilai benar atau tidak dapat dievaluasi, Identity and Access Management akan menerapkan kebijakan untuk akun utama yang membuat permintaan. Jika kondisi bernilai salah (false), Identity and Access Management tidak akan menerapkan kebijakan untuk akun utama. Untuk informasi selengkapnya, lihat Batasan dan kondisi akses akun utama di halaman ini.createTime
: Waktu saat binding kebijakan dibuat.updateTime
: Waktu saat binding kebijakan terakhir diperbarui.
Kasus penggunaan
Berikut adalah situasi umum saat Anda mungkin ingin menggunakan kebijakan batas akses akun utama, dan contoh kebijakan batas akses akun utama serta binding kebijakan yang dapat Anda buat dalam setiap situasi. Untuk mempelajari cara membuat kebijakan batas akses akun utama dan mengikatnya ke kumpulan akun utama, lihat Membuat dan menerapkan kebijakan batas akses akun utama.
Membatasi akun utama ke resource di organisasi Anda
Anda dapat menggunakan kebijakan batas akses akun utama untuk memastikan bahwa akun utama di organisasi Anda hanya memenuhi syarat untuk mengakses resource dalam organisasi Anda.
Misalnya, bayangkan Anda ingin memastikan bahwa semua akun utama di
organisasi example.com
hanya memenuhi syarat untuk mengakses resource dalam
example.com
. Akun utama yang ada di example.com
mencakup semua identitas
di domain example.com
, semua kumpulan identitas tenaga kerja di
example.com
, dan semua akun layanan dan kumpulan identitas beban kerja di
project apa pun di example.com
.
Anda tidak memiliki kebijakan batas akses akun utama yang berlaku untuk akun utama apa pun di organisasi Anda. Akibatnya, semua akun utama memenuhi syarat untuk mengakses semua resource.
Agar akun utama tidak memenuhi syarat untuk mengakses resource di luar example.com
, Anda
harus membuat kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses
resource di example.com
:
{
"name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
"displayName": "Boundary for principals in example.org",
"details": {
"rules": [
{
"description": "Principals are only eligible to access resources in example.org",
"resources": [
"//cloudresourcemanager.googleapis.com/organizations/0123456789012"
],
"effect": "ALLOW"
}
],
"enforcementVersion": "1"
}
}
Kemudian, Anda membuat binding kebijakan untuk mengikat kebijakan ini ke kumpulan akun utama:
{
"name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
"displayName": "Bind policy to all principals in example.com",
"target": {
"principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
},
"policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
"policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}
Sekarang, semua akun utama di example.com
hanya memenuhi syarat untuk mengakses resource di
example.com
. Akun utama tersebut dicegah untuk menggunakan izin yang diblokir oleh
kebijakan batas akses akun utama untuk mengakses resource di luar
example.com
, meskipun akun utama tersebut memiliki izin tersebut di resource tersebut.
Membatasi akun layanan ke resource dalam satu project
Anda dapat menggunakan kebijakan batas akses akun utama untuk memastikan bahwa akun layanan dalam project tertentu hanya memenuhi syarat untuk mengakses resource dalam project tersebut.
Misalnya, bayangkan Anda memiliki project, example-dev
. Anda ingin memastikan bahwa akun layanan di example-dev
hanya memenuhi syarat untuk mengakses resource di example-dev
.
Anda memiliki kebijakan batas akses akun utama yang membuat semua akun utama di organisasi, termasuk akun layanan di example-dev
, memenuhi syarat untuk mengakses resource di example.com
. Untuk melihat tampilan jenis kebijakan ini,
lihat Membatasi akun utama ke resource di organisasi Anda.
Agar akun layanan di example-dev
tidak memenuhi syarat untuk mengakses resource di luar example-dev
, Anda harus membuat kebijakan batas akses akun utama terlebih dahulu yang membuat akun utama memenuhi syarat untuk mengakses resource di example-dev
{
"name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
"displayName": "Boundary for principals in example-dev",
"details": {
"rules": [
{
"description": "Principals are only eligible to access resources in example-dev",
"resources": [
"//cloudresourcemanager.googleapis.com/projects/example-dev"
],
"effect": "ALLOW"
}
],
"enforcementVersion": "1"
}
}
Kemudian, Anda membuat binding kebijakan untuk mengikat kebijakan ini ke semua akun utama di
example-dev
, dan menambahkan kondisi agar binding kebijakan hanya berlaku untuk
akun layanan:
{
"name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
"displayName": "Bind policy to all service accounts in example-dev",
"target": {
"principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
},
"policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
"policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
"condition": {
"title": "Only service accounts",
"description": "Only enforce the policy if the principal in the request is a service account",
"expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
}
}
Namun, kebijakan ini sendiri tidak membatasi kelayakan akun layanan. Hal ini karena ada kebijakan batas akses akun utama yang
membuat semua akun utama di example.com
memenuhi syarat untuk mengakses semua resource di
example.com
. Kebijakan batas akses akun utama bersifat
aditif, sehingga akun layanan di example-dev
masih memenuhi syarat untuk mengakses semua resource di example.com
.
Untuk memastikan bahwa akun layanan di example-dev
hanya memenuhi syarat untuk mengakses
resource di example-dev
, Anda perlu menambahkan kondisi ke binding kebijakan
untuk kebijakan batas akses akun utama yang ada yang mencegahnya diterapkan
untuk akun layanan di example-dev
:
{
"name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
"displayName": "Bind policy to all principals in example.com",
"target": {
"principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
},
"policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
"policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
"condition": {
"title": "Exempt example-dev service accounts",
"description": "Don't enforce the policy for service accounts in the example-dev project",
"expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.')"
}
}
Sekarang, akun layanan di example-dev
hanya memenuhi syarat untuk mengakses resource
di example-dev
. Akun utama tersebut dicegah untuk menggunakan izin yang diblokir oleh
kebijakan batas akses akun utama untuk mengakses resource di luar
example-dev
, meskipun akun utama tersebut memiliki izin tersebut pada resource tersebut.
Langkah selanjutnya
- Pelajari cara membuat dan menerapkan kebijakan batas akses akun utama.
- Tinjau izin yang diblokir oleh setiap versi penerapan kebijakan batas akses akun utama.