This page describes built-in identities for resources, which let you grantroles to resources in your IAM allow policies.

Built-in identities

Some resources have built-in identities. These identities let the resources actlikeprincipals. As a result, resources with built-in identitiescan do the following:

• Begranted IAM roles using theresource'sprincipal identifier
• Access other resources without usingservice agents

For example, consider Parameter Manager parameters, which have built-inidentities. Parameters sometimes need access to Secret Manager tofunction properly. To let a parameter access Secret Manager, you useits identifier to grant it the Secret Manager Secret Accessor role(roles/secretmanager.secretAccessor). Then, the parameter can accessSecret Manager secrets on your behalf.

For a list of resources with built-in identities, seeResources with built-inidentities.

You can't use a resource's built-in identity to authenticate customer-managedworkloads, like workloads running on Compute Engine instances. If youneed to authenticate a workload, use one of the methods described inAuthentication 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 byincluding the resource'sprincipal identifier in your allow policies. To seewhat format to use for each resource's principal identifier, seePrincipalidentifiers for single resources.

IAM also offers identifiers for sets of resources with built-inidentities that share certain characteristics, such as type or ancestor. You canuse these identifiers in your allow policies to grant the same role to multipleresources. To see what formats are supported, seePrincipal identifiers forsets of resources.