Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página descreve as identidades integradas para recursos, que permitem conceder
papéis a recursos nas suas políticas de permissão do IAM.
Identidades integradas
Alguns recursos têm identidades integradas. Essas identidades permitem que os recursos atuem
como principais. Como resultado, os recursos com identidades integradas
podem fazer o seguinte:
Por exemplo, considere os parâmetros do Gerenciador de parâmetros, que têm identidades
incorporadas. Às vezes, os parâmetros precisam de acesso ao Secret Manager para
funcionar corretamente. Para permitir que um parâmetro acesse o Secret Manager, use
o identificador dele para conceder o papel de Acessador de secrets do Secret Manager
(roles/secretmanager.secretAccessor). Em seguida, o parâmetro poderá acessar
os secrets do Secret Manager em seu nome.
Não é possível usar a identidade integrada de um recurso para autenticar cargas de trabalho gerenciadas pelo cliente, como cargas de trabalho executadas em instâncias do Compute Engine. Se você
precisar autenticar uma carga de trabalho, use um dos métodos descritos em
Métodos de autenticação no Google.
Conceder papéis a recursos com identidades integradas
Se um recurso tiver uma identidade integrada, será possível conceder papéis a ele
incluindo o identificador principal dele nas políticas de permissão. Para saber
qual formato usar para cada identificador principal de recurso, consulte Identificadores
principais para recursos únicos.
O IAM também oferece identificadores para conjuntos de recursos com identidades
integradas que compartilham determinadas características, como tipo ou ancestral. É possível
usar esses identificadores nas políticas de permissão para conceder o mesmo papel a vários
recursos. Para conferir os formatos aceitos, consulte Identificadores principais para
conjuntos de recursos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
