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-Kontingente. Kontingente für die Mitarbeiteridentitätsföderation gelten für Organisationen.
| Standardkontingente | |
|---|---|
| IAM API | |
| Leseanfragen (z. B. zum Abrufen einer Richtlinie) | 6.000 pro Minute |
| Schreibanfragen (z. B. zum Aktualisieren einer Richtlinie) | 600 pro Minute |
| Identitätsföderation von Arbeitslasten | |
| 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 (Vorschau) | |
| 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 |
| Pools der Mitarbeiteridentitätsföderation pro Organisation | 100 |
| Service Account Credentials API | |
| Anfragen zum Erstellen von Anmeldedaten | 60.000 pro Minute |
| Anfragen zum Signieren eines JSON-Webtokens (JWT) oder Blobs | 60.000 pro Minute |
| Security Token Service API | |
| Tauschen Sie Tokenanfragen aus (Nicht-Workforce-Identitätsföderation) | 6.000 pro Minute |
| Token-Anfragen austauschen (workforce Identity-Föderation) (Vorschau) | 60.000 pro Organisation und Minute |
| Dienstkonten | |
| Anzahl von Dienstkonten | 100 |
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 |
| Domains und Google-Gruppen in allen Rollenbindungen innerhalb einer einzelnen Zulassungsrichtlinie2 | 250 |
| Gesamtzahl der Hauptkonten (einschließlich Domains und Google-Gruppen) in allen Rollenbindungen und Audit-Logging-Ausnahmen innerhalb einer einzelnen Richtlinie3 | 1.500 |
| 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 Ressource4 | 500 |
| Gesamtzahl der Hauptkonten (einschließlich Domains und Google-Gruppen) in allen Ablehnungsrichtlinien einer Ressource4 | 2.500 |
| Regeln in einer einzelnen Ablehnungsrichtlinie ablehnen | 500 |
| Logische Operatoren im Bedingungsausdruck einer Ablehnungsregel | 12 |
| Dienstkonten | |
| Dienstkonto-ID | 30 Byte |
| Anzeigename des Dienstkontos | 100 Byte |
| Dienstkontoschlüssel für ein Dienstkonto | 10 |
| Mitarbeiteridentitätsföderation (Vorschau) | |
| Anbieter von Workforce Identity-Pools pro Pool | 200 |
| Betreffzeilen der gelöschten Mitarbeiteridentität pro Pool | 100.000 |
| Attributföderation von Arbeitslasten und der Mitarbeiteridentitätsföderation (Vorschau) | |
| 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 Zugriffstokens5 |
3.600 Sekunden (1 Stunde) |
1 Wenn Sie auf der Projektebene benutzerdefinierte Rollen erstellen, zählen diese nicht zum Limit auf der Organisationsebene.
2 Für dieses Limit werden Domains und Google-Gruppen so gezählt:
-
Für Domains zählt IAM alle Vorkommen jeder Domain in den Rollenbindungen der zulässigen Richtlinie. Hauptkonten, die in mehreren Rollenbindungen vorkommen, werden nicht dedupliziert. Wenn eine Berechtigungsrichtlinie beispielsweise nur eine Domain (
domain:example.com) enthält und die Domain zehnmal in der Zulassungsliste enthalten ist, können Sie weitere 240 Domains hinzufügen, bevor Sie das Limit erreichen. -
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. Wenn eine 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 eindeutige Gruppen hinzufügen, bevor Sie das Limit erreichen.
3
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 Hauptkonto group:my-group@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.
Wenn Sie IAM Conditions verwenden oder vielen Hauptkonten mit unüblich langen Kennzeichnungen Rollen zuweisen, erlaubt IAM möglicherweise weniger Hauptkonten in der Richtlinie.
4 IAM zählt alle Vorkommen eines Hauptkontos in allen angehängten Ablehnungsrichtlinien. zu einer Ressource. 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:alice@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.