Memahami kebijakan izin

Anda dapat memberikan akses ke resource Google Cloud menggunakan kebijakan izin, juga disebut sebagai kebijakan Identity and Access Management (IAM), yang terpasang ke resource. Anda hanya dapat memasang satu kebijakan izin ke setiap resource. Kebijakan izin mengontrol akses ke resourcenya sendiri, serta ke berbagai turunan resource tersebut yang mewarisi kebijakan izin.

Halaman ini menampilkan kebijakan izin dalam format JSON. Anda juga dapat menggunakan Google Cloud CLI untuk mengambil kebijakan izin dalam format YAML.

Struktur kebijakan

Kebijakan izin adalah kumpulan dari binding peran dan metadata. Binding peran menentukan akses yang harus diberikan ke resource. Binding ini mengaitkan atau mengikat satu atau lebih akun utama dengan satu peran IAM dan kondisi konteks tertentu yang mengubah cara dan waktu diberikannya peran tersebut. Metadata mencakup informasi tambahan mengenai kebijakan izin, seperti etag dan versi untuk memfasilitasi pengelolaan kebijakan.

Setiap binding peran dapat menyertakan kolom berikut:

Satu atau beberapa akun utama, juga dikenal sebagai anggota atau identitas. Ada beberapa jenis akun utama, termasuk akun pengguna, akun layanan, grup Google, dan domain. Untuk mengetahui daftar lengkap jenis utama yang didukung, lihat ID utama.
Peran, kumpulan izin yang memiliki nama. Peran memberikan kemampuan untuk melakukan tindakan pada resource Google Cloud.
Kondisi, yang merupakan ekspresi logika opsional yang lebih membatasi binding peran berdasarkan atribut tentang permintaan tersebut, seperti asalnya atau resource target. Biasanya, kondisi digunakan untuk mengontrol pemberian akses berdasarkan konteks untuk permintaan.

Jika binding peran memiliki kondisi, binding ini juga disebut sebagai binding peran bersyarat.

Beberapa layanan Google Cloud tidak menerima kondisi di kebijakan izin. Untuk daftar layanan dan jenis resource yang menerima kondisi, lihat Jenis resource yang menerima binding peran bersyarat.

Perubahan pada akses akun utama akan memiliki konsistensi yang tertunda. Artinya, diperlukan waktu agar perubahan akses dapat ditransmisikan melalui sistem. Untuk mempelajari waktu rata-rata yang diperlukan perubahan akses untuk bertransmisi, lihat Transmisi perubahan akses.

Batasan pada akun utama

Setiap kebijakan izin dapat berisi hingga 1.500 akun utama. Untuk tujuan batasan ini, IAM menghitung semua tampilan dari setiap akun utama dalam binding peran kebijakan izin, serta akun utama yang dikecualikan dari logging audit Akses Data oleh kebijakan izin. IAM tidak menghapus duplikat akun utama yang muncul dalam lebih dari satu binding peran. Misalnya, jika satu kebijakan izin hanya berisi binding peran untuk akun utama, group:my-group@example.com, dan akun utama tersebut muncul dalam 50 binding peran, Anda tetap dapat menambahkan 1.450 akun utama lain ke dalam binding peran di kebijakan izin.

Sebanyak hingga 250 akun utama dalam kebijakan izin dapat berupa domain dan grup Google. Untuk tujuan batasan ini, domain dan grup Google dihitung sebagai berikut:

Untuk domain, IAM menghitung semua tampilan dari setiap domain dalam binding peran kebijakan izin. Tindakan ini tidak menghapus duplikat domain yang muncul di lebih dari satu binding peran. Misalnya, jika kebijakan izin hanya berisi satu domain, domain:example.com, dan domain tersebut muncul dalam kebijakan izin sebanyak 10 kali, Anda dapat menambahkan 240 domain lain sebelum mencapai batasnya.
Untuk grup Google, setiap grup unik hanya dihitung sekali, terlepas dari berapa kali grup muncul dalam kebijakan izin. Misalnya, jika kebijakan izin hanya berisi satu grup, group:my-group@example.com, dan grup tersebut muncul di kebijakan izin sebanyak 10 kali, Anda tetap dapat menambahkan 249 grup yang unik lain sebelum mencapai batasan.

Jika Anda menggunakan IAM Conditions, atau jika Anda memberikan peran ke banyak akun utama dengan ID yang sangat panjang, IAM akan mengizinkan lebih sedikit akun utama di kebijakan izin.

Metadata kebijakan

Metadata untuk kebijakan izin mencakup kolom berikut:

Kolom etag, digunakan untuk kontrol konkurensi dan untuk memastikan bahwa kebijakan izin diupdate secara konsisten. Untuk detailnya, lihat Menggunakan etag dalam kebijakan di halaman ini.
Kolom version, menentukan versi skema untuk kebijakan izin yang diberikan. Untuk detailnya, lihat Versi kebijakan di halaman ini.

Untuk organisasi, folder, project, dan akun penagihan, kebijakan izin juga dapat berisi kolom auditConfig. Kolom ini menentukan jenis aktivitas yang menghasilkan log audit untuk setiap layanan. Untuk mempelajari cara mengonfigurasi bagian kebijakan izin ini, lihat Mengonfigurasi log audit Akses Data.

Menggunakan etag dalam kebijakan

Jika beberapa sistem mencoba untuk menulis ke kebijakan izin yang sama secara bersamaan, ada risiko bahwa sistem tersebut dapat saling menimpa perubahan. Risiko ini terjadi karena kebijakan izinkan diperbarui menggunakan pola read-modify-write, yang melibatkan beberapa operasi:

Membaca kebijakan izin yang ada
Mengubah kebijakan izin
Menulis keseluruhan kebijakan izin

Jika Sistem A membaca kebijakan izin dan Sistem B segera menulis versi kebijakan izin terbaru, Sistem A tidak akan mengetahui perubahan dari Sistem B. Saat Sistem A menulis perubahannya sendiri ke kebijakan izin, perubahan Sistem B dapat hilang.

Untuk membantu mencegah masalah ini, Identity and Access Management (IAM) mendukung kontrol konkurensi melalui penggunaan kolom etag di kebijakan izin. Setiap kebijakan izin berisi kolom etag. Nilai kolom ini akan berubah setiap kali kebijakan izin diupdate. Jika kebijakan izin berisi kolom etag, tetapi tidak ada binding peran, kebijakan izin tidak akan memberikan peran IAM apa pun.

Kolom etag berisi nilai seperti BwUjMhCsNvY=. Saat Anda mengupdate kebijakan izin, pastikan untuk menyertakan kolom etag dalam kebijakan izin terbaru. Jika kebijakan izin sudah diubah sejak Anda mengambilnya, nilai etag tidak akan sesuai. Proses update juga akan gagal. Untuk REST API, Anda akan menerima kode status HTTP 409 Conflict. Isi responsnya mirip dengan berikut ini:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Jika Anda menerima error ini, coba lagi seluruh rangkaian operasi: baca lagi kebijakan izinnya, ubah sesuai kebutuhan, dan tulis kebijakan izin terbaru. Anda harus melakukan percobaan ulang secara otomatis dengan backoff eksponensial di berbagai alat yang digunakan untuk mengelola kebijakan izin.

Contoh: Kebijakan sederhana

Pertimbangkan kebijakan izin berikut yang mengikat akun utama ke peran:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Pada contoh di atas, jie@example.com diberi peran dasar Pemilik tanpa kondisi apa pun. Peran ini memberi jie@example.com akses yang hampir tidak terbatas.

Contoh: Kebijakan dengan berbagai binding peran

Pertimbangkan kebijakan izin berikut yang berisi lebih dari satu binding peran. Setiap binding peran memberikan peran yang berbeda:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Pada contoh di atas, Jie (jie@example.com) diberi peran bawaan Organization Admin (roles/resourcemanager.organizationAdmin) dalam binding peran pertama. Peran ini berisi izin untuk organisasi, folder, dan operasi project terbatas. Dalam binding peran kedua, Jie dan Raha (raha@example.com) diberi kemampuan untuk membuat project melalui peran Project Creator (roles/resourcemanager.projectCreator). Peran binding ini bersama-sama memberi akses terperinci untuk Jie dan Raha. Jie akan diberi lebih banyak akses daripada Raha.

Contoh: Kebijakan dengan binding peran bersyarat

Pertimbangkan kebijakan izin berikut yang mengikat akun utama ke peran bawaan dan menggunakan ekspresi kondisi untuk membatasi binding peran:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Dalam contoh ini, kolom version ditetapkan ke 3 karena kebijakan izin berisi ekspresi kondisi. Binding peran dalam kebijakan izin bersifat kondisional. Binding peran akan memberikan peran ke grup Google prod-dev@example.com dan akun layanan prod-dev-example@appspot.gserviceaccount.com, tetapi hanya berlaku hingga 1 Juli 2022.

Untuk mengetahui detail mengenai fitur yang didukung oleh setiap versi kebijakan izin, lihat Versi kebijakan di halaman ini.

Contoh: Kebijakan dengan binding peran bersyarat dan tanpa syarat

Pertimbangkan kebijakan izin berikut yang berisi binding peran bersyarat dan tanpa syarat untuk peran yang sama:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Dalam contoh ini, akun layanan serviceAccount:prod-dev-example@appspot.gserviceaccount.com disertakan dalam dua binding peran untuk peran yang sama. Binding peran pertama tidak memiliki kondisi. Binding peran kedua memiliki kondisi, yaitu hanya memberikan peran hingga 1 Juli 2022.

Kebijakan izin ini selalu memberikan peran ke akun layanan secara efektif. Di IAM, binding peran bersyarat tidak menggantikan binding peran tanpa syarat. Jika akun utama terikat dengan peran dan binding peran tidak memiliki kondisi, akun utama akan selalu memiliki peran. Menambahkan akun utama ke binding peran bersyarat untuk peran yang sama tidak akan memberikan dampak apa pun.

Sebaliknya, grup Google group:prod-dev@example.com hanya disertakan dalam binding peran bersyarat. Dengan demikian, peran tersebut hanya tersedia sebelum 1 Juli 2022.

Contoh: Kebijakan yang mengikat peran ke akun utama yang dihapus

Pertimbangkan kebijakan izin berikut. Kebijakan izin ini mengikat peran ke pengguna, donald@example.com, yang akunnya sudah dihapus. Oleh karena itu, kini ID pengguna memiliki awalan deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Jika Anda membuat pengguna baru bernama donald@example.com, binding peran kebijakan izin untuk pengguna yang dihapus tidak akan berlaku untuk pengguna baru tersebut. Perilaku ini mencegah pengguna baru mewarisi peran yang diberikan ke pengguna yang sudah dihapus. Jika Anda ingin memberikan peran kepada pengguna baru, tambahkan pengguna baru ke binding peran kebijakan izin, seperti yang ditunjukkan dalam Kebijakan dengan akun utama yang dihapus di halaman ini.

Selain itu, kini nama pengguna menyertakan awalan deleted: dan akhiran ?uid=numeric-id, dengan numeric-id adalah ID numerik unik pengguna yang dihapus. Dalam contoh ini, kebijakan izin menampilkan ID deleted:user:donald@example.com?uid=123456789012345678901, bukan user:donald@example.com.

Akun layanan dan grup memiliki perilaku yang sama dengan pengguna. Jika Anda menghapus akun layanan dan grup, lihat kebijakan izin yang menyertakan akun utama. Nama akun utama yang dihapus memiliki awalan deleted: dan akhiran ?uid=numeric-id.

Kebijakan default

Semua resource yang menerima kebijakan izin dibuat dengan kebijakan izin default. Sebagian besar resource kebijakan izin default kosong. Namun, beberapa resource kebijakan izin default secara otomatis berisi binding peran. Misalnya, saat Anda membuat project baru, kebijakan izin untuk project tersebut akan otomatis memiliki binding peran yang memberikan Anda peran Pemilik (roles/owner) project tersebut.

Binding peran ini dibuat oleh sistem, sehingga pengguna tidak memerlukan izin getIamPolicy atau setIamPolicy pada resource untuk binding peran yang akan dibuat.

Untuk mengetahui resource yang dibuat dengan kebijakan izin, baca dokumentasi resource.

Pewarisan kebijakan dan hierarki resource

Resource Google Cloud diatur secara hierarkis dengan node organisasi merupakan node root dalam hierarki, lalu folder (opsional), setelahnya adalah project. Sebagian besar resource lain dibuat dan dikelola dalam project. Setiap resource pasti memiliki satu induk, kecuali organisasi. Organisasi, sebagai node root dalam hierarki, tidak memiliki induk. Untuk informasi selengkapnya, lihat topik Hierarki Resource.

Hierarki resource penting untuk dipertimbangkan saat menetapkan kebijakan izin. Saat menetapkan kebijakan izin di level yang lebih tinggi dalam hierarki, seperti di level organisasi, level folder, atau level project, cakupan akses yang diberikan mencakup level resource tempat kebijakan izin ini dipasang, serta mencakup semua resource dalam level tersebut. Misalnya, kebijakan izin yang ditetapkan di level organisasi berlaku untuk organisasi dan semua resource dalam organisasi tersebut. Demikian juga dengan kebijakan izin yang ditetapkan di level project. Kebijakan tersebut berlaku untuk project dan semua resource dalam project.

Pewarisan kebijakan adalah istilah mengenai cara kebijakan izin diterapkan pada resource di bawah levelnya dalam hierarki resource. Kebijakan efektif adalah istilah mengenai cara semua induk kebijakan izin dalam hierarki resource diwariskan untuk suatu resource. Kebijakan ini adalah gabungan dari:

Kebijakan izin yang ditetapkan pada resource
Kebijakan izin yang ditetapkan pada semua ancestry resource di level resource dalam hierarki

Setiap binding peran baru (diwariskan dari resource induk) yang memengaruhi resource kebijakan izin efektif dievaluasi secara independen. Permintaan akses tertentu ke resource akan diberikan jika binding peran dengan level yang lebih tinggi memberikan akses ke permintaan.

Jika binding peran baru diperkenalkan pada level kebijakan izin yang diwariskan ke resource, cakupan pemberian akses akan meningkat.

Contoh: Pewarisan kebijakan

Untuk memahami pewarisan kebijakan izin, pertimbangkan skenario saat Anda memberikan seorang pengguna, Raha, dua peran IAM yang berbeda pada dua level yang berbeda dalam hierarki resource.

Untuk memberi Raha peran di tingkat organisasi, Anda menetapkan kebijakan izin berikut di organisasi Anda:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Kebijakan izin ini memberi Raha peran Storage Object Viewer (roles/storage.objectViewer) yang berisi izin get dan list untuk project dan objek Cloud Storage. Karena Anda menetapkan kebijakan izin di organisasi, Raha dapat menggunakan izin ini untuk semua project dan semua objek Cloud Storage dalam organisasi Anda.

Untuk memberi Raha peran di level project, Anda harus menetapkan kebijakan izin berikut di project myproject-123:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Kebijakan izin ini memberi Raha peran Storage Object Creator (roles/storage.objectCreator) yang memungkinkannya membuat objek Cloud Storage. Karena Anda menetapkan kebijakan izin pada myproject-123, Raha dapat membuat objek Cloud Storage hanya dalam myproject-123.

Kini, ada dua binding peran yang memberikan Raha akses ke objek Cloud Storage target dalam myproject-123. Dengan demikian, berlaku kebijakan izin berikut:

Kebijakan izin di level organisasi memberikan kemampuan untuk mencantumkan dan mendapatkan semua objek Cloud Storage dalam organisasi ini.
Kebijakan izin di level project, untuk project myproject-123, memberikan kemampuan untuk membuat objek dalam project tersebut.

Tabel di bawah ini merangkum kebijakan efektif Raha:

Izin diberikan melalui peran "storage.objectViewer" di level organisasi	Izin diberikan melalui peran "storage.objectCreator" di "myproject-123"	Cakupan pemberian yang efektif untuk Raha dalam "myproject-123"
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list	resourcemanager.projects.get resourcemanager.projects.list storage.objects.create	resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create

Versi kebijakan

Seiring waktu, IAM dapat menambahkan fitur baru yang menambahkan atau mengubah kolom secara signifikan dalam skema kebijakan izin. Agar tidak merusak integrasi yang ada, serta yang mengandalkan konsistensi dalam struktur kebijakan izin, perubahan tersebut diperkenalkan dalam versi skema kebijakan izin baru.

Jika Anda pertama kali berintegrasi dengan IAM, sebaiknya gunakan versi skema kebijakan izin terbaru yang tersedia saat ini. Di bawah ini, kami akan membahas berbagai versi yang tersedia dan cara menggunakannya. Kami juga akan menjelaskan cara menentukan versi yang diinginkan dan memandu Anda melalui beberapa skenario pemecahan masalah.

Setiap kebijakan izin yang ada menentukan kolom version sebagai bagian dari metadata kebijakan izin. Perhatikan bagian yang ditandai di bawah ini:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Kolom ini menentukan versi skema sintaksis kebijakan izin. Setiap versi kebijakan izin berisi skema sintaksis tertentu yang dapat digunakan oleh binding peran. Versi yang lebih baru dapat berisi binding peran dengan skema sintaksis yang lebih baru. Skema sintaksis pada versi ini tidak didukung oleh versi sebelumnya. Kolom ini tidak bertujuan selain untuk mengontrol skema sintaksis pada kebijakan izin.

Versi kebijakan yang valid

Kebijakan izin dapat digunakan untuk versi kebijakan izin berikut:

Versi	Deskripsi
`1`	Versi pertama skema sintaksis IAM untuk kebijakan. Mendukung binding satu peran ke satu atau beberapa akun utama. Tidak mendukung binding peran bersyarat.
`2`	Tersedia untuk penggunaan internal.
`3`	Memperkenalkan kolom `condition` dalam binding peran yang membatasi binding peran melalui aturan berbasis konteks dan berbasis atribut. Untuk informasi selengkapnya, lihat ringkasan IAM Conditions.

Menentukan versi kebijakan saat mendapatkan kebijakan

Untuk REST API dan library klien, saat Anda mendapatkan kebijakan izin, sebaiknya tentukan versi kebijakan izin dalam permintaan. Saat permintaan menentukan versi kebijakan izin, IAM berasumsi bahwa pemanggil mengetahui fitur dalam versi kebijakan izin tersebut dan dapat menanganinya dengan benar.

Jika permintaan tidak menentukan versi kebijakan izin, IAM akan berasumsi bahwa pemanggil menginginkan kebijakan izin versi 1.

Saat Anda mendapatkan kebijakan izin, IAM akan memeriksa versi kebijakan izin dalam permintaan, atau versi default jika permintaan tidak menentukan versi kebijakan. IAM juga akan memeriksa kebijakan izin untuk kolom yang tidak didukung dalam kebijakan izin versi 1. Informasi ini digunakan untuk memutuskan jenis respons yang akan dikirim:

Jika kebijakan izin tidak berisi kondisi apa pun, IAM akan selalu menampilkan kebijakan izin versi 1, terlepas dari nomor versi dalam permintaan.
Jika kebijakan izin berisi kondisi, serta pemanggil meminta kebijakan izin 3, IAM akan menampilkan kebijakan izin versi 3 yang menyertakan kondisi tersebut. Untuk contohnya, lihat skenario 1 di halaman ini.
Jika kebijakan izin berisi kondisi, serta pemanggil meminta kebijakan izin versi 1 atau tidak menentukan versi kebijakan, IAM akan menampilkan kebijakan izin versi 1.

Untuk binding peran yang menyertakan kondisi, IAM menambahkan string _withcond_ ke nama peran, diikuti dengan nilai hash. Contohnya, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. Kondisinya sendiri tidak ada. Sebagai contoh, lihat skenario 2 di halaman ini.

Skenario 1: Versi kebijakan yang sepenuhnya mendukung IAM Conditions

Misalkan Anda memanggil metode REST API berikut guna mendapatkan kebijakan izin untuk suatu project:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Isi permintaan akan berisi teks berikut:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

Responsnya berisi project dari kebijakan izin. Jika kebijakan izin berisi setidaknya satu binding peran bersyarat, kolom version ini ditetapkan ke 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Jika kebijakan izin tidak berisi binding peran bersyarat, kolom version ini ditetapkan ke 1, meskipun permintaan menentukan versi 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Skenario 2: Kebijakan izin dengan dukungan terbatas untuk IAM Conditions

Misalkan Anda memanggil metode REST API berikut guna mendapatkan kebijakan izin untuk suatu project:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Isi permintaan kosong dan tidak ditentukan nomor versi. Oleh karena itu, IAM menggunakan kebijakan izin default, 1.

Kebijakan izin berisi binding peran bersyarat. Karena versi kebijakan izin adalah 1, kondisi tidak muncul dalam respons. Untuk menunjukkan bahwa binding peran menggunakan kondisi, IAM menambahkan string _withcond_ ke nama peran, diikuti oleh nilai hash:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Menentukan versi kebijakan saat menetapkan kebijakan

Saat Anda menetapkan kebijakan izin, sebaiknya tentukan versi kebijakan izin dalam permintaan. Saat permintaan menentukan versi kebijakan izin, IAM berasumsi bahwa pemanggil mengetahui fitur dalam versi kebijakan izin tersebut dan dapat menanganinya dengan benar.

Jika permintaan tidak menentukan versi kebijakan izin, IAM hanya akan menerima kolom yang dapat muncul dalam kebijakan izin versi 1. Sebagai praktik terbaik, jangan mengubah binding peran bersyarat dalam kebijakan izin versi 1. Kebijakan izin ini tidak menampilkan kondisi untuk setiap binding peran, sehingga Anda tidak akan tahu waktu atau tempat binding peran benar-benar diberikan. Sebagai gantinya, dapatkan representasi versi 3 dari kebijakan izin yang menampilkan kondisi untuk setiap binding peran. Gunakan representasi tersebut untuk mengupdate binding peran.

Skenario: Versi kebijakan dalam permintaan dan respons

Misalkan Anda menggunakan REST API untuk mendapatkan kebijakan izin, serta menentukan versi 3 dalam permintaan. Respons akan berisi kebijakan izin yang menggunakan versi 3 seperti berikut:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Anda memutuskan bahwa raha@example.com harus memiliki peran Storage Admin (roles/storage.admin) sepanjang minggu, bukan hanya pada hari kerja. Anda menghapus kondisi dari binding peran dan mengirim permintaan REST API untuk menetapkan kebijakan izin. Sekali lagi, Anda menentukan versi 3 dalam permintaan:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Respons berisi kebijakan izin terbaru:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

Kebijakan izin dalam respons menggunakan versi 1, meskipun permintaan tersebut menentukan versi 3, karena kebijakan izin hanya menggunakan kolom yang didukung di kebijakan izin versi 1.

Kebijakan dengan akun utama yang dihapus

Jika binding peran dalam kebijakan izin menyertakan akun utama yang dihapus, dan Anda menambahkan binding peran untuk akun utama baru dengan nama yang sama, binding peran akan selalu diterapkan ke akun utama baru.

Misalnya, pertimbangkan kebijakan izin berikut yang menyertakan binding peran ke pengguna yang dihapus, donald@example.com, dan akun layanan yang dihapus, my-service-account@project-id.iam.gserviceaccount.com. Oleh karena itu, ID untuk setiap akun utama memiliki awalan deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Misalkan Anda membuat pengguna baru yang juga bernama donald@example.com, serta ingin memberikan peran Project Creator (roles/resourcemanager.projectCreator) yang memungkinkan akun utama untuk membuat project Google Cloud, kepada pengguna baru. Untuk memberikan peran kepada pengguna baru, update kebijakan izin seperti yang ditunjukkan dalam contoh ini:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Untuk mempermudah audit kebijakan izin IAM, Anda juga dapat menghapus pengguna yang dihapus dari binding peran ke peran Pemilik:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Praktik terbaik kebijakan

Praktik terbaik berikut berlaku untuk organisasi yang memiliki banyak pengguna Google Cloud:

Saat mengelola beberapa akun pengguna dengan konfigurasi akses yang sama, gunakan grup Google. Masukkan setiap akun pengguna perorangan dan berikan peran yang dimaksud ke grup, bukan ke akun pengguna perorangan.
Izin yang diberikan di level organisasi: Pertimbangkan akun utama yang akan diberi izin akses di level organisasi dengan cermat. Untuk sebagian besar organisasi, hanya beberapa tim tertentu (seperti tim Keamanan dan Jaringan) yang dapat diberi akses pada level hierarki resource ini.
Izin yang diberikan di level folder: Pertimbangkan struktur operasi organisasi Anda menggunakan tingkatan folder. Setiap folder induk/turunan dapat dikonfigurasi dengan kumpulan pemberian akses yang berbeda dan sesuai dengan kebutuhan bisnis dan operasi. Misalnya, folder induk dapat mencerminkan departemen, salah satu turunannya dapat mencerminkan akses resource dan operasi berdasarkan grup, serta folder turunan lainnya dapat mencerminkan tim kecil. Kedua folder ini dapat berisi project untuk kebutuhan operasi tim mereka. Menggunakan folder dengan cara ini dapat memastikan pemisahan akses yang tepat sekaligus mematuhi kebijakan izin yang diwariskan dari folder induk dan organisasi. Praktik ini memerlukan lebih sedikit pemeliharaan kebijakan izin saat membuat atau mengelola resource Google Cloud.
Izin yang diberikan di level project: Berikan binding peran di level project jike diperlukan untuk mengikuti prinsip hak istimewa terendah. Misalnya, jika akun utama memerlukan akses ke 3 dari 10 project dalam satu folder, Anda harus memberikan akses ke masing-masing dari 3 project tersebut satu per satu. Sebaliknya, jika Anda memberikan peran pada folder tersebut, akun utama akan mendapatkan askes yang tidak diperlukan ke 7 project lainnya.

Anda juga dapat menggunakan IAM Conditions untuk memberikan akses di level organisasi atau folder, tetapi hanya untuk sebagian folder atau project.

Langkah selanjutnya

Pelajari cara memecahkan masalah kebijakan izin yang berisi string withcond dalam nama peran.
Cari tahu cara mengelola binding peran dalam kebijakan izin.
Dapatkan ringkasan IAM Conditions yang menggunakan kebijakan izin versi 3.
Pelajari tentang alat Policy Intelligence yang dapat membantu Anda memahami dan mengelola kebijakan izin untuk meningkatkan konfigurasi keamanan.
Gunakan Cloud Asset API untuk menelusuri kebijakan izin.
Gunakan Cloud Asset API untuk menampilkan kebijakan izin efektif.