Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describen las identidades integradas para los recursos, que te permiten otorgar roles a los recursos en tus políticas de permisos de IAM.
Identidades integradas
Algunos recursos tienen identidades integradas. Estas identidades permiten que los recursos actúen
como principales. Como resultado, los recursos con identidades integradas pueden hacer lo siguiente:
Por ejemplo, considera los parámetros del Administrador de parámetros, que tienen identidades integradas. A veces, los parámetros necesitan acceso a Secret Manager para
funcionar correctamente. Para permitir que un parámetro acceda a Secret Manager, debes usar
su identificador para otorgarle el rol de descriptor de acceso a secretos de Secret Manager
(roles/secretmanager.secretAccessor). Luego, el parámetro puede acceder
a los secretos de Secret Manager en tu nombre.
No puedes usar la identidad integrada de un recurso para autenticar cargas de trabajo que administra el cliente, como las que se ejecutan en instancias de Compute Engine. Si necesitas autenticar una carga de trabajo, usa uno de los métodos descritos en Métodos de autenticación de Google.
Otorga roles a recursos con identidades integradas
Si un recurso tiene una identidad integrada, puedes otorgarle roles si
incluyes el identificador principal del recurso en tus políticas de permisos. Para ver qué formato usar para el identificador principal de cada recurso, consulta Identificadores principales de recursos individuales.
IAM también ofrece identificadores para conjuntos de recursos con identidades integradas que comparten ciertas características, como el tipo o el ancestro. Puedes usar estos identificadores en tus políticas de permisos para otorgar el mismo rol a varios recursos. Para ver qué formatos se admiten, consulta Identificadores principales para conjuntos de recursos.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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)."]]
