Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive le identità predefinite per le risorse, che ti consentono di concedere ruoli alle risorse nei criteri di autorizzazione IAM.
Identità integrate
Alcune risorse hanno identità integrate. Queste identità consentono alle risorse di comportarsi come entità. Di conseguenza, le risorse con identità integrate possono:
Ad esempio, considera i parametri di Parameter Manager, che hanno identità predefinite. A volte i parametri devono accedere a Secret Manager per funzionare correttamente. Per consentire a un parametro di accedere a Secret Manager, utilizza il suo identificatore per concedergli il ruolo Secret Manager Secret Accessor (roles/secretmanager.secretAccessor). In questo modo, il parametro potrà accedere ai secret di Secret Manager per tuo conto.
Non puoi utilizzare l'identità integrata di una risorsa per autenticare i workload gestiti dal cliente, ad esempio i workload in esecuzione sulle istanze Compute Engine. Se devi autenticare un carico di lavoro, utilizza uno dei metodi descritti in Metodi di autenticazione di Google.
Assegnare ruoli alle risorse con identità integrate
Se una risorsa ha un'identità integrata, puoi concedere i ruoli alla risorsa includendo l'identificatore dell'entità della risorsa nei criteri di autorizzazione. Per sapere quale formato utilizzare per l'identificatore principale di ogni risorsa, consulta Identificatori principali per singole risorse.
IAM offre anche identificatori per insiemi di risorse con identità predefinite che condividono determinate caratteristiche, come il tipo o l'antenato. Puoi
utilizzare questi identificatori nei criteri di autorizzazione per concedere lo stesso ruolo a più
risorse. Per scoprire quali formati sono supportati, consulta Identificatori principali per
insiemi di risorse.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
