Stay organized with collections
Save and categorize content based on your preferences.
This page describes built-in identities for resources, which let you grant
roles to resources in your IAM allow policies.
Built-in identities
Some resources have built-in identities. These identities let the resources act
like principals. As a result, resources with built-in identities
can do the following:
For example, consider Parameter Manager parameters, which have built-in
identities. Parameters sometimes need access to Secret Manager to
function properly. To let a parameter access Secret Manager, you use
its identifier to grant it the Secret Manager Secret Accessor role
(roles/secretmanager.secretAccessor). Then, the parameter can access
Secret Manager secrets on your behalf.
You can't use a resource's built-in identity to authenticate customer-managed
workloads, like workloads running on Compute Engine instances. If you
need to authenticate a workload, use one of the methods described in
Authentication methods at Google.
Granting roles to resources with built-in identities
If a resource has a built-in identity, you can grant roles to the resource by
including the resource's principal identifier in your allow policies. To see
what format to use for each resource's principal identifier, see Principal
identifiers for single resources.
IAM also offers identifiers for sets of resources with built-in
identities that share certain characteristics, such as type or ancestor. You can
use these identifiers in your allow policies to grant the same role to multiple
resources. To see what formats are supported, see Principal identifiers for
sets of resources.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 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,["This page describes built-in identities for resources, which let you grant\nroles to resources in your IAM allow policies.\n\nBuilt-in identities\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\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)."]]
