Skip to content
Calcrivo

GCP IAM Calculator

Size a Google Cloud allow policy against the 1500-principal cap, the 250-group sub-limit and 300 custom roles per project.

Inputs

principals
groups
bindings
roles
principals

Principal Utilisation vs 1500

42.7%

Principals Remaining

860of 1500

Groups vs the 250 Sub-Limit

48.0%

Custom Roles vs 300 per Project

31.7%

Effective Principals Including Inheritance

700

Average Principals per Binding

3.6

Assessment

Within Google Cloud IAM limits

Step by step

  1. Values used

    Principals in the project allow policy = 640 principals; Of those, Google groups = 120 groups; Role bindings in the policy = 180 bindings; Custom roles in the project = 95 roles; Principals inherited from folder and organisation = 60 principals

  2. GCP IAM

    utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals.

  3. Inherited access

    effective principals = principals bound here + principals inherited from ancestor folders and the organisation.

  4. Principal Utilisation vs 1500

    = 42.7

  5. Principals Remaining

    = 860 of 1500

  6. Groups vs the 250 Sub-Limit

    = 48.0

  7. Custom Roles vs 300 per Project

    = 31.7

  8. Effective Principals Including Inheritance

    = 700

  9. Average Principals per Binding

    = 3.6

How it works

Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy. Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.

Formulas

GCP IAM

utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals.

250
How many of those principals may be Google groups
300
Custom roles per project
1500
Principals allowed in a single allow policy

Inherited access

effective principals = principals bound here + principals inherited from ancestor folders and the organisation.

inheritance
GCP allow policies are additive down the resource hierarchy and cannot be subtracted

Frequently Asked Questions

How is GCP IAM calculated?

utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals. Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy.

Why does GCP IAM matter?

Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.

What values do I need to enter?

This calculator takes 5 inputs: Principals in the project allow policy, Of those, Google groups, Role bindings in the policy, Custom roles in the project, Principals inherited from folder and organisation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

How do I reduce principals in a GCP allow policy?

Replace individual user bindings with Google group bindings, bind at folder or organisation level where the access is genuinely broad, remove bindings for deleted principals (they linger as deleted: entries), and use IAM Conditions so one binding covers cases that previously needed several.

Can a project policy take away access granted higher up?

Not with allow policies — they are purely additive, so a project cannot revoke what a folder granted. Restricting inherited access requires deny policies, which are evaluated before allow policies, or organisation policy constraints.

You might also need