An Access Policy is a reusable document of permission rules. You attach it to IAM Users (via the user's Access Policies field) to allow or deny specific operations on specific cloud resource types.

If you only need standard roles, attach one of the precreated policies (read-only, read-write, read-write-delete) instead of writing your own — see the IAM overview.

The policy document

spec.content is a YAML document: a format_version (currently "1.0.0") and a list of entries. Each entry has:

• description — optional free text

• effect — allow or deny

• for_actions — a list of action patterns the entry covers. Omit it to match every action

• for_resources — a list of resource matchers (each with of_type / not_of_type / when). Omit it to match every resource

Actions

An action is named <Product>:<Operation> in PascalCase — for example Compute:GetVm, Compute:CreateVm, Compute:DeleteVm, S3:CreateS3Bucket, Network:GetVpc. The verbs are Get, List, Create, Edit, Delete (not "Read"). Patterns use * as a wildcard and must match the whole action string, so "*:Get*" means "any read on any product", "Compute:*" means "everything on Compute", and "*" means everything.

Resources and of_type

A resource type is named <Product>:<Type>, e.g. Compute:Vm, Network:Vpc, Support:SupportPlan. of_type selects the types an entry applies to and not_of_type excludes some (both are *-wildcard patterns matched against the whole string). of_type: "*" means all types; not_of_type: "Support:SupportPlan|Billing:BillingAccount" excludes those two.

How allow and deny combine

Evaluation is default-deny: an operation is permitted only when some entry explicitly allows it and no entry denies it. Deny always wins — if any matching entry has effect: deny, the request is refused even when another entry allows it. With no matching allow, the request is refused. (This is also how the automatic system deny policy fences off platform internals regardless of what you grant.)

The when condition

A resource matcher may carry a when — a Python boolean expression evaluated for each candidate resource. The entry applies to that resource only when when is truthy; omitted, it defaults to True. Exactly two objects are in scope:

• caller — the acting user: caller.id, caller.name, caller.folder.id, caller.folder.name

• resource — the resource being accessed: resource.id, resource.name, resource.folder.id, resource.folder.name

Only identity and folder are exposed (there is no request, time, or label context). Supported operators are ==, !=, and, or, not, parentheses, and dotted attribute access; a folder is None when unset. For example, scope an entry to a single folder with when: resource.folder.id == "01J…", or to resources the caller owns by name with when: resource.name == caller.name.

Usage

Follow the principle of least privilege: grant only the actions needed. A policy is standalone — it takes effect once you attach it to a user through that user's Access Policies field.

Content — example YAML value:

Examples

Terraform

Python SDK

kc CLI

---

Related pages

Resource docs

• User resource docs
• Folder resource docs

More in this section

• User Token

Reference

• Kvindo provider on the Terraform Registry
• Interactive API reference (Swagger)