Cette page répertorie les quotas et limites qui s'appliquent à Identity and Access Management (IAM). Les quotas et les limites peuvent restreindre le nombre de requêtes que vous pouvez envoyer ou le nombre de ressources que vous pouvez créer. Les limites peuvent également restreindre les attributs d'une ressource, tels que la longueur de son identifiant.
Si un quota n'est pas suffisant pour répondre à vos besoins, vous pouvez utiliser Google Cloud Console pour demander une augmentation de quota pour votre projet. Si vous ne pouvez pas demander la modification d'un quota spécifique via la console Google Cloud, contactez l'assistance Google Cloud.
Les limites ne peuvent pas être modifiées.
Quotas
Par défaut, les quotas IAM suivants s'appliquent à chaque projet Google Cloud, à l'exception des quotas de fédération d'identité de personnel. Les quotas de fédération d'identité de personnel s'appliquent aux organisations.
| Quotas par défaut | |
|---|---|
| API IAM | |
| Requêtes de lecture (par exemple, obtention d'une stratégie) | 6 000 par minute |
| Requêtes d'écriture (par exemple, mise à jour d'une stratégie) | 600 par minute |
| Fédération d'identité de charge de travail | |
| Requêtes de lecture (par exemple, obtention d'un pool d'identités de charge de travail) | 600 par projet et par minute 6 000 par client et par minute |
| Requêtes d'écriture (par exemple, mise à jour d'un pool d'identités de charge de travail) | 60 par projet et par minute 600 par client et par minute |
| Fédération d'identité de personnel (bêta) | |
| Requêtes de création/suppression/annulation de suppression | 60 par organisation et par minute |
| Requêtes de lecture (par exemple, obtention d'un pool d'identités de personnel) | 120 par organisation et par minute |
| Demandes de mise à jour (par exemple, mise à jour d'un pool d'identités de personnel) | 120 par organisation et par minute |
| Demandes de suppression/d'annulation de suppression (par exemple, suppression d'un objet de pool d'identités de personnel) | 60 par organisation et par minute |
| Pools d'identités de personnel par organisation | 100 |
| API Service Account Credentials | |
| Requêtes de génération d'identifiants | 60 000 par minute |
| Requêtes de signature d'un jeton Web JSON (JWT) ou d'un blob | 60 000 par minute |
| API Security Token Service | |
| Requêtes de jeton d'échange (fédération d'identité autre) | 6 000 par minute |
| Requêtes de jeton d'échange (fédération d'identité de personnel) (Bêta) | 60 000 par organisation et par minute |
| Comptes de service | |
| Nombre de comptes de service | 100 |
Limites
IAM applique les limites suivantes sur les ressources. Ces limites ne peuvent pas être modifiées.
| Limites | |
|---|---|
| Rôles personnalisés | |
| Rôles personnalisés pour une organisation1 | 300 |
| Rôles personnalisés pour un projet1 | 300 |
| ID d'un rôle personnalisé | 64 octets |
| Titre d'un rôle personnalisé | 100 octets |
| Description d'un rôle personnalisé | 300 octets |
| Autorisations dans un rôle personnalisé | 3 000 |
| Taille totale pour le titre, la description et les noms d'autorisations d'un rôle personnalisé | 64 ko |
| Autoriser les stratégies et les liaisons de rôles | |
| Autoriser les règles par ressource | 1 |
| Domaines et groupes Google dans toutes les liaisons de rôles au sein d'une même stratégie d'autorisation2 | 250 |
| Nombre total de comptes principaux (y compris les domaines et les groupes Google) dans toutes les liaisons de rôles et exceptions de journalisation d'audit au sein d'une seule stratégie3 | 1,500 |
| Opérateurs logiques dans une expression de condition de liaison de rôle | 12 |
| Les liaisons de rôle dans une stratégie d'autorisation qui inclut le même rôle et le même compte principal, mais différentes expressions de condition. | 20 |
| Règles et stratégies de refus | |
| Stratégies de refus par ressource | 500 |
| Règles de refus par ressource | 500 |
| Domaines et groupes Google dans toutes les stratégies de refus d'une ressource4 | 500 |
| Nombre total de comptes principaux (y compris les domaines et les groupes Google) dans toutes les stratégies de refus d'une ressource4 | 2500 |
| Règles de refus dans une seule stratégie de refus | 500 |
| Opérateurs logiques dans une expression de condition de règle de refus | 12 |
| Comptes de service | |
| ID du compte de service | 30 octets |
| Nom à afficher du compte de service | 100 octets |
| Clés de compte de service pour un compte de service | 10 |
| Fédération d'identité de personnel (bêta) | |
| Fournisseurs de pools d'identités de personnel par pool | 200 |
| Objets de pool d'identités de personnel supprimés par pool | 100,000 |
| Fédération d'identité de charge de travail et fédération d'identité de personnel (bêta) | |
| Sujet mappé | 127 octets |
| Nom à afficher de l'utilisateur du pool d'identités de personnel | 100 octets |
| Taille totale des attributs mappés | 8192 octets |
| Nombre de mappages d'attributs personnalisés | 50 |
| Identifiants de courte durée | |
| Règles limitant les accès définies dans une limite d'accès aux identifiants | 10 |
| Durée de vie maximale d'un jeton d'accès5 |
3 600 secondes (1 heure) |
1 Si vous créez des rôles personnalisés au niveau du projet, ceux-ci ne sont pas pris en compte dans la limite définie au niveau de l'organisation.
2 Dans le cadre de cette limite, les domaines et les groupes Google sont comptabilisés comme suit :
-
Pour les domaines, IAM comptabilise toutes les apparitions de chaque domaine dans les liaisons de rôle de la stratégie d'autorisation. Les comptes principaux qui apparaissent dans plusieurs liaisons de rôles ne sont pas supprimés. Par exemple, si une règle d'autorisation ne contient qu'un seul domaine,
domain:example.com, et que le domaine apparaît 10 fois dans la règle d'autorisation, vous pouvez ajouter 240 domaines supplémentaires avant d'atteindre la limite. -
Pour les groupes Google, chaque groupe unique n'est comptabilisé qu'une seule fois, quel que soit le nombre de fois où il apparaît dans la stratégie d'autorisation. Par exemple, si une stratégie d'autorisation ne contient qu'un seul groupe,
group:[email protected], et que le groupe apparaît dans la règle d'autorisation 10 fois, vous pouvez ajouter 249 groupes uniques avant d'atteindre la limite.
3 Pour respecter cette limite, Cloud IAM comptabilise toutes les apparitions de chaque compte principal dans les liaisons de rôle de la stratégie d'autorisation, ainsi que les comptes principaux que la stratégie d'autorisation exclut de l'accès aux journaux d'audit des accès aux données. Les comptes principaux qui apparaissent dans plusieurs liaisons ne sont pas supprimés. Par exemple, si une stratégie d'autorisation ne contient que des liaisons de rôles pour le compte principal group:[email protected] et que ce compte principal apparaît dans 50 liaisons de rôles, vous pouvez ajouter 1 450 comptes principaux aux liaisons de rôles dans la stratégie d'autorisation.
Si vous utilisez des conditions IAM ou si vous attribuez des rôles à de nombreux comptes principaux avec des identifiants particulièrement longs, il se peut qu'IAM autorise moins de comptes principaux dans la stratégie.
4 IAM compte toutes les apparitions de chaque compte principal dans toutes les stratégies de refus associées à une ressource. Les comptes principaux qui apparaissent dans plusieurs règles de refus ou stratégies de refus ne sont pas dédupliqués. Par exemple, si les stratégies de refus associées à une ressource ne contiennent que des règles de refus pour le compte principal user:[email protected] et que ce compte principal apparaît dans 20 règles de refus, vous pouvez ajouter 2 480 autres comptes principaux aux stratégies de refus de la ressource.
5 Vous pouvez prolonger la durée de vie maximale des jetons d'accès pour OAuth 2.0 à 12 heures (43 200 secondes). Pour ce faire, identifiez les comptes de service qui ont besoin de jetons à durée de vie prolongée, puis ajoutez-les à une règle d'administration qui comprend la contrainte de liste constraints/iam.allowServiceAccountCredential.