Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden integrierte Identitäten für Ressourcen beschrieben, mit denen Sie Ressourcen in Ihren IAM-Zulassungsrichtlinien Rollen zuweisen können.
Integrierte Identitäten
Einige Ressourcen haben integrierte Identitäten. Mit diesen Identitäten können die Ressourcen wie Hauptkonten agieren. Ressourcen mit integrierten Identitäten können daher Folgendes tun:
Auf andere Ressourcen zugreifen, ohne Dienst-Agents zu verwenden
Nehmen wir beispielsweise Parameter des Parametermanagers mit integrierten Identitäten. Damit Parameter ordnungsgemäß funktionieren, benötigen sie manchmal Zugriff auf Secret Manager. Wenn Sie einem Parameter Zugriff auf Secret Manager gewähren möchten, müssen Sie ihm über seine Kennung die Rolle „Secret Manager Secret Accessor“ (roles/secretmanager.secretAccessor) zuweisen. Anschließend kann der Parameter in Ihrem Namen auf Secret Manager-Secrets zugreifen.
Sie können die integrierte Identität einer Ressource nicht zum Authentifizieren von kundenverwalteten Arbeitslasten wie Arbeitslasten verwenden, die auf Compute Engine-Instanzen ausgeführt werden. Wenn Sie eine Arbeitslast authentifizieren müssen, verwenden Sie eine der Methoden, die unter Authentifizierungsmethoden bei Google beschrieben sind.
Ressourcen mit integrierten Identitäten Rollen zuweisen
Wenn eine Ressource eine integrierte Identität hat, können Sie der Ressource Rollen gewähren, indem Sie die Hauptkonto-ID der Ressource in Ihre Zulassungsrichtlinien aufnehmen. Informationen dazu, welches Format für die Hauptkonto-ID der einzelnen Ressourcen verwendet werden soll, finden Sie unter Hauptkonto-IDs für einzelne Ressourcen.
IAM bietet auch IDs für Ressourcengruppen mit integrierten Identitäten, die bestimmte Merkmale wie Typ oder Vorfahr gemeinsam haben. Sie können diese IDs in Ihren Zulassungsrichtlinien verwenden, um mehreren Ressourcen dieselbe Rolle zu gewähren. Informationen zu den unterstützten Formaten finden Sie unter Hauptkonto-IDs für Ressourcengruppen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
