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. By contrast, Secrets Manager access policies use the same condition shape and are enforced today on getSecretValue and putSecretValue.

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.

Best practices

• Least privilege — Prefer narrow rules (specific resourceIdentities) over resources: ["*"] with permissions: ["*"].
• Separation of duties — Split create/delete from read/list across policies; use KMS encrypt/decrypt without export.
• Inherited policies — Use replicateToChildren for org-wide standards (for example, auditor read-only) pushed to all child environments; edit only on the parent.
• Service accounts over users — Bind automation to service accounts or OIDC clients, not personal users.
• Project picker — Ensure the console always shows the active project; permissions change with project context.
• Conditionals — Configure IP/time restrictions now; they will apply once platform-wide enforcement ships. Use Secrets Manager access policies today for secret-specific IP/time enforcement.

Common errors

Related documentation

• Concepts — Effective permissions and object reference
• Default policies — Built-in policy catalogue
• API reference — Endpoint summary