Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan identitas bawaan untuk resource, yang memungkinkan Anda memberikan
peran ke resource dalam kebijakan izin IAM.
Identitas bawaan
Beberapa resource memiliki identitas bawaan. Identitas ini memungkinkan resource bertindak
seperti entity utama. Akibatnya, resource dengan identitas bawaan
dapat melakukan hal berikut:
Mengakses resource lain tanpa menggunakan agen layanan
Misalnya, pertimbangkan parameter Pengelola Parameter, yang memiliki identitas bawaan. Parameter terkadang memerlukan akses ke Secret Manager agar dapat berfungsi dengan baik. Agar parameter dapat mengakses Secret Manager, Anda menggunakan
ID-nya untuk memberinya peran Secret Manager Secret Accessor
(roles/secretmanager.secretAccessor). Kemudian, parameter tersebut dapat mengakses secret Secret Manager atas nama Anda.
Anda tidak dapat menggunakan identitas bawaan resource untuk mengautentikasi beban kerja yang dikelola pelanggan, seperti beban kerja yang berjalan di instance Compute Engine. Jika Anda
perlu mengautentikasi beban kerja, gunakan salah satu metode yang dijelaskan dalam
Metode autentikasi di Google.
Memberikan peran ke resource dengan identitas bawaan
Jika resource memiliki identitas bawaan, Anda dapat memberikan peran ke resource dengan
menyertakan ID akun utama resource dalam kebijakan izin Anda. Untuk melihat
format yang akan digunakan untuk setiap ID utama resource, lihat ID
utama untuk satu resource.
IAM juga menawarkan ID untuk kumpulan resource dengan identitas bawaan yang memiliki karakteristik tertentu, seperti jenis atau ancestor. Anda dapat
menggunakan ID ini dalam kebijakan izin untuk memberikan peran yang sama ke beberapa
resource. Untuk melihat format yang didukung, lihat ID utama untuk
kumpulan resource.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-21 UTC."],[[["\u003cp\u003eBuilt-in identities allow resources to act as principals, enabling them to be granted IAM roles.\u003c/p\u003e\n"],["\u003cp\u003eResources with built-in identities can access other resources without the need for service agents.\u003c/p\u003e\n"],["\u003cp\u003eYou can grant roles to resources with built-in identities by using the resource's principal identifier in your allow policies.\u003c/p\u003e\n"],["\u003cp\u003eIAM provides principal identifiers for both single resources and sets of resources with built-in identities, allowing for flexible role granting.\u003c/p\u003e\n"],["\u003cp\u003eYou can't use built-in identities for authenticating customer-managed workloads.\u003c/p\u003e\n"]]],[],null,["# Built-in identities for resources\n\nThis page describes built-in identities for resources, which let you grant\nroles to resources in your IAM allow policies.\n\nBuilt-in identities\n-------------------\n\nSome resources have built-in identities. These identities let the resources act\nlike [principals](/iam/docs/principals-overview). As a result, resources with built-in identities\ncan do the following:\n\n- Be [granted IAM roles](/iam/docs/granting-changing-revoking-access) using the [resource's\n principal identifier](/iam/docs/resources-with-built-in-identities)\n- Access other resources without using [service agents](/iam/docs/service-account-types#service-agents)\n\nFor example, consider Parameter Manager parameters, which have built-in\nidentities. Parameters sometimes need access to Secret Manager to\nfunction properly. To let a parameter access Secret Manager, you use\nits identifier to grant it the Secret Manager Secret Accessor role\n(`roles/secretmanager.secretAccessor`). Then, the parameter can access\nSecret Manager secrets on your behalf.\n\nFor a list of resources with built-in identities, see [Resources with built-in\nidentities](/iam/docs/resources-with-built-in-identities).\n\nYou can't use a resource's built-in identity to authenticate customer-managed\nworkloads, like workloads running on Compute Engine instances. If you\nneed to authenticate a workload, use one of the methods described in\n[Authentication methods at Google](/docs/authentication).\n\nGranting roles to resources with built-in identities\n----------------------------------------------------\n\nIf a resource has a built-in identity, you can grant roles to the resource by\nincluding the resource's *principal identifier* in your allow policies. To see\nwhat format to use for each resource's principal identifier, see [Principal\nidentifiers for single resources](/iam/docs/resources-with-built-in-identities#single-resources).\n\nIAM also offers identifiers for sets of resources with built-in\nidentities that share certain characteristics, such as type or ancestor. You can\nuse these identifiers in your allow policies to grant the same role to multiple\nresources. To see what formats are supported, see [Principal identifiers for\nsets of resources](/iam/docs/resources-with-built-in-identities#resource-sets)."]]