Auf dieser Seite sind die Kontingente und Limits für Identity and Access Management (IAM) aufgeführt. Die Anzahl der Anfragen, die Sie senden können, sowie die Anzahl der erstellbaren Ressourcen können durch Kontingente und Limits eingeschränkt sein. Limits können auch die Attribute einer Ressource wie etwa die Länge der Ressourcen-ID beschränken.
Wenn das verfügbare Kontingent für Ihr Projekt nicht ausreicht, können Sie in der Google Cloud Console ein höheres Kontingent anfordern. Wenn die Google Cloud Console keine Anfrage für ein bestimmtes Kontingent zulässt, wenden Sie sich an den Google Cloud-Support.
Limits können nicht geändert werden.
Kontingente
Standardmäßig gelten die folgenden IAM-Kontingente für jedes Google Cloud-Projekt mit Ausnahme der Workforce Identity Federation- und Privileged Access Manager-Kontingente. Kontingente für die Mitarbeiteridentitätsföderation gelten für Organisationen.
Die Kontingente für Privileged Access Manager gelten sowohl für Projekte als auch für Organisationen. Die Abrechnung erfolgt je nach Ziel des Aufrufs so:
- Bei Projekten, die keiner Organisation zugewiesen sind, wird für einen Aufruf eine Einheit des Projektkontingents berechnet.
- Bei Projekten, die zu einer Organisation gehören, werden für einen Aufruf jeweils eine Einheit des Projekt- und des Organisationskontingents berechnet. Ein Aufruf wird abgelehnt, wenn eines der beiden Kontingente aufgebraucht ist.
- Für Aufrufe von Ordnern oder Organisationen wird ein Organisationskontingent in Anspruch genommen.
| Standardkontingente | |
|---|---|
| IAM v1 API | |
| Leseanfragen (z. B. zum Abrufen einer Zulassungsrichtlinie) | 6.000 pro Projekt und Minute |
| Schreibanfragen (z. B. zum Aktualisieren einer Zulassungsrichtlinie) | 600 pro Projekt und Minute |
| IAM v2 API | |
| Leseanfragen (z. B. zum Abrufen einer Ablehnungsrichtlinie) | 5 pro Projekt und Minute |
| Schreibanfragen (z. B. zum Aktualisieren einer Ablehnungsrichtlinie) | 5 pro Projekt und Minute |
| IAM v3 API | |
| Leseanfragen (z. B. zum Abrufen einer Principal Access Boundary-Richtlinie) | 5 pro Projekt und Minute |
| Schreibanfragen (z. B. zum Aktualisieren einer Principal Access Boundary-Richtlinie) | 5 pro Projekt und Minute |
| Workload Identity-Föderation | |
| Leseanfragen (z. B. zum Abrufen eines Workload-Identity-Pools) | 600 pro Projekt und Minute 6.000 pro Client und Minute |
| Schreibanfragen (z. B. Aktualisieren eines Workload-Identity-Pools) | 60 pro Projekt und Minute 600 pro Client und Minute |
| Mitarbeiteridentitätsföderation | |
| Anfragen erstellen/löschen/wiederherstellen | 60 pro Organisation und Minute |
| Leseanfragen (z. B. zum Abrufen eines Workforce-Identity-Pools) | 120 pro Organisation und Minute |
| Anfragen aktualisieren (z. B. Aktualisierung eines workforce identity pools) | 120 pro Organisation und Minute |
| Anfragen zum Löschen/Wiederherstellen von Themen (z. B. Löschen eines workforce identity pool-Themas) | 60 pro Organisation und Minute |
| Anzahl der workforce identity pools | 100 pro Organisation. |
| OAuth-Anwendungen für die Mitarbeiterverwaltung | |
| Anfragen erstellen/lesen/aktualisieren/löschen/wiederherstellen | 60 pro Projekt und Minute |
| Service Account Credentials API | |
| Anfragen zum Erstellen von Anmeldedaten | 60.000 pro Projekt und Minute |
| Anfragen zum Signieren eines JSON-Webtokens (JWT) oder Blobs | 60.000 pro Projekt und Minute |
| Security Token Service API | |
| Tauschen Sie Tokenanfragen aus (Nicht-Workforce-Identitätsföderation) | 6.000 pro Projekt und Minute |
| Tokenanfragen austauschen (Workforce Identity-Föderation) | 1.000 pro Organisation und Minute |
| Dienstkonten | |
| Anzahl von Dienstkonten | 100 pro Projekt |
| Privileged Access Manager API | |
| Schreibanfragen für Berechtigungen (z. B. zum Erstellen, Aktualisieren oder Löschen einer Berechtigung) | 100 pro Projekt und Minute 100 pro Organisation und Minute |
CheckOnboardingStatus-Anfragen |
300 pro Projekt und Minute 900 pro Organisation und Minute |
ListEntitlements-Anfragen |
600 pro Projekt und Minute 1.800 pro Organisation und Minute |
SearchEntitlements-Anfragen |
600 pro Projekt und Minute 1.800 pro Organisation und Minute |
GetEntitlement-Anfragen |
3.000 pro Projekt und Minute 9.000 pro Organisation und Minute |
ListGrants-Anfragen |
600 pro Projekt und Minute 1.800 pro Organisation und Minute |
SearchGrants-Anfragen |
600 pro Projekt und Minute 1.800 pro Organisation und Minute |
GetGrant-Anfragen |
3.000 pro Projekt und Minute 9.000 pro Organisation und Minute |
CreateGrant-Anfragen |
200 pro Projekt und Minute 600 pro Organisation und Minute |
ApproveGrant-Anfragen |
200 pro Projekt und Minute 600 pro Organisation und Minute |
DenyGrant-Anfragen |
200 pro Projekt und Minute 600 pro Organisation und Minute |
RevokeGrant-Anfragen |
300 pro Projekt und Minute 900 pro Organisation und Minute |
GetOperation-Anfragen |
600 pro Projekt und Minute 1.800 pro Organisation und Minute |
ListOperations-Anfragen |
300 pro Projekt und Minute 900 pro Organisation und Minute |
Limits
IAM erzwingt die folgenden Ressourcenlimits. Diese Limits können nicht geändert werden.
| Limits | |
|---|---|
| Benutzerdefinierte Rollen | |
| Benutzerdefinierte Rollen für eine Organisation1 | 300 |
| Benutzerdefinierte Rollen für ein Projekt1 | 300 |
| ID einer benutzerdefinierten Rolle | 64 Byte |
| Titel einer benutzerdefinierten Rolle | 100 Byte |
| Beschreibung einer benutzerdefinierten Rolle | 300 Byte |
| Berechtigungen in einer benutzerdefinierten Rolle | 3.000 |
| Gesamtgröße des Titels, der Beschreibung und des Berechtigungsnamens für eine benutzerdefinierte Rolle | 64 KB |
| Richtlinien und Rollenbindungen zulassen | |
| Richtlinien pro Ressource zulassen | 1 |
| Gesamtzahl der Hauptkonten (einschließlich Domains und Google-Gruppen) in allen Rollenbindungen und Audit-Logging-Ausnahmen innerhalb einer einzelnen Richtlinie2 | 1.500 |
| Domains und Google-Gruppen in allen Rollenbindungen innerhalb einer einzelnen Zulassungsrichtlinie3 | 250 |
| Logische Operatoren im Bedingungsausdruck einer Rollenbindung | 12 |
| Rollenbindungen in einer Zulassungsrichtlinie, die dieselbe Rolle und dasselbe Hauptkonto, aber unterschiedliche Bedingungsausdrücke beinhalten | 20 |
| Ablehnungsrichtlinien und Ablehnungsregeln | |
| Ablehnungsrichtlinien pro Ressource | 500 |
| Ablehnungsregeln pro Ressource | 500 |
| Domains und Google-Gruppen in allen Ablehnungsrichtlinien einer Ressource 4 | 500 |
| Gesamtzahl der Hauptkonten (einschließlich Domains und Google-Gruppen) in allen Ablehnungsrichtlinien einer Ressource 4 | 2.500 |
| Regeln in einer einzelnen Ablehnungsrichtlinie ablehnen | 500 |
| Logische Operatoren im Bedingungsausdruck einer Ablehnungsregel | 12 |
| Principal Access Boundary-Richtlinien | |
| Regeln in einer einzelnen Principal Access Boundary-Richtlinie | 500 |
| Ressourcen in allen Regeln einer einzelnen Principal Access Boundary-Richtlinie | 500 |
| Anzahl der Principal Access Boundary-Richtlinien, die an eine Ressource gebunden werden können | 10 |
| Principal Access Boundary-Richtlinien pro Organisation | 1000 |
| Logische Operatoren im Bedingungsausdruck einer Richtlinienbindung | 10 |
| Dienstkonten | |
| Dienstkonto-ID | 30 Byte |
| Anzeigename des Dienstkontos | 100 Byte |
| Dienstkontoschlüssel für ein Dienstkonto | 10 |
| Mitarbeiteridentitätsföderation | |
| Anbieter von Workforce Identity-Pools pro Pool | 200 |
| Betreffzeilen der gelöschten Mitarbeiteridentität pro Pool | 100.000 |
| OAuth-Anwendungen für die Mitarbeiterverwaltung | |
| Workforce-OAuth-Clients pro Projekt | 100 |
| OAuth-Clientanmeldedaten für Workforce pro Kunde | 10 |
| Attributföderation von Arbeitslasten und der Mitarbeiteridentitätsföderation | |
| Zugeordnetes Thema | 127 byte |
| Anzeigename des zugeordneten Workforce-Identitätspool-Nutzers | 100 Byte |
| Gesamtgröße der zugeordneten Attribute | 8,192 byte |
| Anzahl der benutzerdefinierten Attributzuordnungen. | 50 |
| Kurzlebige Anmeldedaten | |
| Regeln zur Zugriffsgrenze in einer Zugriffsgrenze für Anmeldedaten | 10 |
| Maximale Lebensdauer eines Zugriffstokens 5 |
3.600 Sekunden (1 Stunde) |
1 Wenn Sie auf der Projektebene benutzerdefinierte Rollen erstellen, zählen diese nicht zum Limit auf der Organisationsebene.
2 Im Hinblick auf diese Grenze zählt IAM alle Darstellungen jedes Hauptkontos in den Rollenbindungen der Zulassungs-Richtlinie sowie die Hauptkonten, die die Zulassungs-Richtlinie vom Audit-Logging des Datenzugriffs ausnimmt. Hauptkonten, die in mehreren Rollenbindungen vorkommen, werden nicht dedupliziert. Wenn eine Zulassungsrichtlinie beispielsweise nur Rollenbindungen für das Hauptkontouser:my-user@example.com enthält und dieses Hauptkonto in 50 Rollenbindungen enthalten ist, können Sie den Rollenbindungen in der Zulassungsrichtlinie weitere 1.450 Hauptkonten hinzufügen.
Außerdem wird im Hinblick auf diese Grenze jedes Vorkommen einer Domain oder Google-Gruppe als einzelnes Hauptkonto gezählt, unabhängig von der Anzahl der einzelnen Mitglieder in der Domain oder Gruppe.
Wenn Sie IAM Conditions verwenden oder vielen Hauptkonten mit unüblich langen Kennzeichnungen Rollen zuweisen, erlaubt IAM möglicherweise weniger Hauptkonten in der Zulassungsrichtlinie.
3 Für dieses Limit werden Cloud Identity-Domains, Google Workspace-Konten und Google-Gruppen so gezählt:
- Bei Google-Gruppen wird jede eindeutige Gruppe nur einmal gezählt, unabhängig davon, wie oft die Gruppe in der Richtlinie zum Zulassen angezeigt wird. Das unterscheidet sich von der Zählung von Gruppen für die Beschränkung der Gesamtzahl der Hauptkonten in einer „allow“-Richtlinie. Bei dieser Beschränkung wird jede Gruppe auf das Limit angerechnet.
- Für Cloud Identity-Domains oder Google Workspace-Konten zählt IAM alle Vorkommen jeder Domain oder jedes Kontos in den Rollenbindungen der zulässigen Richtlinie. Hauptkonten, die in mehreren Rollenbindungen vorkommen, werden nicht dedupliziert.
Wenn Ihre Zulassungsrichtlinie beispielsweise nur eine Gruppe (group:my-group@example.com) enthält und die Gruppe zehnmal in der Zulassungsrichtlinie enthalten ist, können Sie weitere 249 Cloud Identity-Domains, Google Workspace-Konten oder eindeutige Gruppen hinzufügen, bevor Sie das Limit erreichen.
Wenn Ihre Zulassungsliste beispielsweise nur eine Domain (domain:example.com) enthält und die Domain zehnmal in der Zulassungsliste enthalten ist, können Sie weitere 240 Cloud Identity-Domains, Google Workspace-Konten oder eindeutige Gruppen hinzufügen, bevor Sie das Limit erreichen.
4
IAM zählt alle Vorkommen eines Hauptkontos in allen Ablehnungsrichtlinien, die mit einer Ressource verknüpft sind. Es werden keine Hauptkonten dedupliziert, die in mehr als einer Ablehnungsregel oder Ablehnungsrichtlinie erscheinen. Wenn die mit einer Ressource verknüpften Ablehnungsrichtlinien beispielsweise nur Ablehnungsregeln für das Hauptkonto user:my-user@example.com enthalten und dieses Hauptkonto in 20 Ablehnungsregeln enthalten ist, können Sie den Ablehnungsrichtlinien der Ressource weitere 2.480 Hauptkonten hinzufügen.
5
Die maximale Lebensdauer für OAuth 2.0-Zugriffstokens kann auf 12 Stunden (43.200 Sekunden) ausgeweitet werden. Identifizieren Sie die Dienstkonten, die eine längere Lebensdauer für Tokens benötigen, um die maximale Lebensdauer zu verlängern. Fügen Sie diese Dienstkonten dann einer Organisationsrichtlinie hinzu, die die Listeneinschränkung constraints/iam.allowServiceAccountCredential enthält.