Permission rules and bindings

Permission rules

Each rule grants permissions on one or more resource types:

{
  "resources": ["cloud_vpc"],
  "resourceIdentities": [],
  "permissions": ["read", "list"],
  "note": "VPC read access for network team"
}

Service-specific permissions

Assignable resource types include (non-exhaustive): project, cloud_vpc, kubernetes_cluster, dbaas_db_cluster, kms_key, secret, dns_zone, container_registry, object_storage_bucket, iam_policy, iam_policy_binding, and others. Use GET /v1/projects/iam/policies/resources for the authoritative list.

When a rule lists specific resource types with an empty resource-identity list, it applies to all instances of those types in scope.

Policy bindings

Bindings attach exactly one principal per binding:

Bindings inherit the policy’s rules (and conditionals, when enforced). Multiple bindings on one policy give the same permissions to multiple principals.

Access conditions

Optional IP and time rules apply to the whole policy (not per rule or per binding). The condition shape matches Secrets Manager access policies and IAM policy conditionals elsewhere on the platform.

{
  "allowed": [
    { "type": "ip", "ips": ["10.0.0.0/8", "192.168.0.0/16"] },
    {
      "type": "time",
      "time": { "startHour": 8, "endHour": 18, "timezone": "Europe/Amsterdam" }
    }
  ],
  "denied": [
    { "type": "ip", "ips": ["203.0.113.50"] }
  ]
}

Evaluation semantics

1. Denied conditions are checked first — any match blocks access.
2. If allowed conditions are present, at least one must match.
3. No conditionals (or empty lists) → no extra restriction from conditions.

IP conditions accept a single IP or CIDR (IPv4/IPv6) in ips. Time conditions use hours 0–23 (inclusive range). If endHour < startHour, the window wraps midnight (for example, 20:00–08:00). Timezone is IANA (defaults to UTC).

Note: Conditionals are stored and validated on create/update and replicate with policies. Runtime enforcement on general API access via IAM policy conditionals is planned.

Policy replication to child projects

Set replicateToChildren: true at policy create. This flag cannot be changed later.

Changes on the source (rules, bindings, conditionals, metadata) sync automatically to all descendant projects. Replicas share the same slug as the source.

In the console, inherited policies appear as view-only with “Inherited from {parent project}” and a link to edit on the source.

Built-in (system) policies

Every project automatically receives system IAM policies that mirror the platform’s organisation default role templates. See the default policies catalogue for the full list.

The default admin policy slug grants full access (resources: ["*"], permissions: ["*"]). Project creators are automatically bound to it. System policy rules are periodically synced from platform templates.

Policy lifecycle

    flowchart TD
    A[Create policy] --> B[Add permission rules]
    A --> C[Create bindings]
    A --> D[Optionally set access conditions]
    A --> E[Optionally replicateToChildren]
    E --> F[Read-only replicas on descendants]
    G[Update custom policies] --> H[Metadata + conditionals via PUT]
    G --> I[Add/remove rules]
    G --> J[Add/remove/update bindings]
    K[Delete custom policy] --> L[Rules and bindings removed]
    K --> M[Replicas cascade-deleted if source]
  

Immutable after create: name, slug, replicateToChildren.

Not mutable: system policies (system: true) and inherited replicas (isReadOnly: true).

Access control on IAM policy APIs

IAM policy management itself is gated by permissions on resources iam_policy and iam_policy_binding. The project admin policy includes these permissions by default.

Related documentation

• API authorization — How endpoints evaluate organisation vs project bindings
• Concepts — Effective permissions and object reference
• Default policies — Built-in policy catalogue
• API reference — Endpoint summary