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 ein Kontingent für Ihre Anforderungen nicht ausreicht, können Sie in der Google Cloud -Konsole eine Kontingentanpassung für Ihr Projekt anfordern. Wenn Sie in derGoogle Cloud Console keine Änderung für ein bestimmtes Kontingent anfordern können, 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 jedesGoogle Cloud -Projekt mit Ausnahme der Kontingente für Workforce Identity Federation und Privileged Access Manager. Kontingente für die Mitarbeiteridentitätsföderation gelten für Organisationen.
Privileged Access Manager-Kontingente gelten sowohl für Projekte als auch für Organisationen und werden je nach Ziel des Aufrufs so berechnet:
- Für Projekte, die nicht zu einer Organisation gehören, 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 Anruf wird abgelehnt, wenn eines der beiden Kontingente ausgeschöpft ist.
- Für Anrufe an Ordner oder Organisationen wird eine Einheit des Organisationskontingents berechnet.
Standardkontingente | |
---|---|
IAM v1 API | |
Leseanfragen (z. B. zum Abrufen einer Zulassungsrichtlinie) | 6.000 pro Projekt und Minute |
Schreibanfragen (z. B. zum Aktualisieren einer „allow”-Richtlinie) | 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 Mitarbeiter | |
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 |
CreateServiceAccount -Anfragen |
Variiert je nach Projekt. Wenn Sie das Kontingent für ein Projekt aufrufen möchten, rufen Sie die Kontingente Ihres Projekts in der Google Cloud Console auf und suchen Sie nach Anfragen zum Erstellen von Dienstkonten nach Anmeldedaten pro Minute. |
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 in 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 Mitarbeiter | |
Workforce-OAuth-Clients pro Projekt | 100 |
OAuth-Clientanmeldedaten für Arbeitskonten pro Client | 10 |
Attributzuordnung für die Identitätsföderation von Arbeitslasten und die 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 Zulassungsrichtlinie sowie die Hauptkonten, die die Zulassungsrichtlinie 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 jede Domain oder Google-Gruppe im Hinblick auf diese Beschränkung als ein 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 davon, wie Gruppen für die Beschränkung der Gesamtzahl der Hauptkonten in einer „allow“-Richtlinie gezählt werden. Bei dieser Beschränkung wird jedes Vorkommen einer Gruppe auf die Beschränkung 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. Es werden keine Domains oder Konten dedupliziert, die in mehreren Rollenbindungen vorkommen.
Wenn Ihre Berechtigungsrichtlinie beispielsweise nur eine Gruppe (group:my-group@example.com
) enthält und die Gruppe zehnmal in der Richtlinie zum Zulassen 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 Berechtigungsrichtlinie 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 an eine Ressource angehängt sind. Es werden keine Hauptkonten dedupliziert, die in mehr als einer Ablehnungsregel oder ‑richtlinie 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-Zugriffstoken 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.