Skip to main content
Access policies declare who can do what within your org. Each policy lists a set of members (users, service users, or teams) and a set of grants (role + resource). Ryvn compiles the cross-product into role bindings — one per (member × grant) — that drive authorization checks across the product.
On sync, Ryvn resolves every member and every grant’s resource reference against the live org. Unknown users, missing resources, or unsupported role/type combinations fail the sync with a per-entry error so you can fix exactly what’s broken.

Properties

name

string — required Unique identifier for the policy within the org. Lowercase alphanumeric with hyphens, up to 63 characters. Used in logs, events, and dashboard listings.

description

string — optional Human-readable description of the policy’s purpose. Up to 256 characters. Helpful for teammates auditing who has what access.

members

array — required, minimum 1 entry Who the policy applies to. Each entry is a kind:identifier string. Members must already exist in the org. An unresolved user or service user fails the sync.

grants

array — required, minimum 1 entry What access members receive. Each entry is a role:resourceType[:name] string.
  • role — one of admin, billing_admin, developer, operator, viewer.
  • resourceType — one of org, environment, service, blueprint.
  • name — the resource name, or * for a type-scoped wildcard. Omit the segment for org grants.
Referenced resources must exist at sync time — a grant pointing at a missing environment, service, or blueprint fails the policy. Wildcard (*) grants match any resource of the given type, including resources created later.

Roles

Not every role is meaningful on every resource type — for example, billing_admin only applies at the org level. The sync rejects unsupported combinations. Roles also decide who may request and approve temporary cluster access: developer and operator on an environment can both request access and decide someone else’s request, viewer can only read the record, and only admin can author the permission sets those requests name. See Just-in-time kubectl access for the full request-and-approve workflow.

Last-admin protection

Ryvn prevents the org from losing its last admin:org binding. Updates that would drop to zero org admins (across all policies) are rejected with a LastAdminProtection error. You can always remove admins as long as at least one admin remains somewhere in the org.

Examples

Per-environment developer access

Grant the platform team full developer access to staging but read-only access to production:

Service-scoped operators

Give the on-call team operator access to a specific service across all environments:

Deploy bot

A service user with narrow permissions for CI/CD:

Org admins

A small policy granting org-level admin to founders: