Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page décrit les identités intégrées pour les ressources, qui vous permettent d'attribuer des rôles aux ressources dans vos stratégies d'autorisation IAM.
Identités intégrées
Certaines ressources disposent d'identités intégrées. Ces identités permettent aux ressources d'agir comme des principaux. Par conséquent, les ressources avec des identités intégrées peuvent effectuer les opérations suivantes:
Prenons l'exemple des paramètres du Gestionnaire de paramètres, qui disposent d'identités intégrées. Les paramètres ont parfois besoin d'accéder à Secret Manager pour fonctionner correctement. Pour autoriser un paramètre à accéder à Secret Manager, vous devez utiliser son identifiant pour lui attribuer le rôle "Accesseur de secrets" de Secret Manager (roles/secretmanager.secretAccessor). Le paramètre peut ensuite accéder aux secrets de Secret Manager en votre nom.
Vous ne pouvez pas utiliser l'identité intégrée d'une ressource pour authentifier les charges de travail gérées par le client, comme les charges de travail exécutées sur des instances Compute Engine. Si vous devez authentifier une charge de travail, utilisez l'une des méthodes décrites dans la section Méthodes d'authentification chez Google.
Attribuer des rôles aux ressources avec des identités intégrées
Si une ressource dispose d'une identité intégrée, vous pouvez lui attribuer des rôles en incluant son identifiant principal dans vos règles d'autorisation. Pour connaître le format à utiliser pour l'identifiant principal de chaque ressource, consultez la section Identifiants principaux pour les ressources individuelles.
IAM propose également des identifiants pour des ensembles de ressources avec des identités intégrées qui partagent certaines caractéristiques, telles que le type ou l'ancêtre. Vous pouvez utiliser ces identifiants dans vos règles d'autorisation pour attribuer le même rôle à plusieurs ressources. Pour connaître les formats acceptés, consultez la section Identifiants principaux pour les ensembles de ressources.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/21 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
