Skip to main content

Documentation Index

Fetch the complete documentation index at: https://ryvn.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

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. 
# platform-devs.accesspolicy.yaml
# yaml-language-server: $schema=https://api.ryvn.app/v1/schemas/resources.json
kind: AccessPolicy
metadata:
  name: platform-devs
spec:
  description: Platform team developers — full access to staging, read-only elsewhere
  members:
    - user:alice@company.com
    - user:bob@company.com
    - service-user:deploy-bot
  grants:
    - developer:environment:staging
    - viewer:service:*
    - viewer:environment:*
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. 
name: platform-devs

​
description

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

​
members

array — required, minimum 1 entry Who the policy applies to. Each entry is a kind:identifier string.
KindIdentifierExample
userEmail address of an existing org memberuser:alice@company.com
service-userName of an existing service userservice-user:deploy-bot
teamTeam name (reserved for future use)team:backend
Members must already exist in the org. An unresolved user or service user fails the sync. 
members:
  - user:alice@company.com
  - service-user:deploy-bot

​
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.
grants:
  - admin:org                        # full org admin
  - billing_admin:org                # billing-only admin
  - developer:environment:staging    # developer on one environment
  - operator:service:api             # operator on one service
  - viewer:service:*                 # read-only on every service
  - viewer:blueprint:*               # read-only on every blueprint
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

RoleTypical use
adminFull control. admin:org is the highest privilege — Ryvn refuses to compile a change that would leave the org with zero admin:org bindings.
billing_adminManage billing and subscriptions. Scoped to org.
developerConfigure services and installations, deploy releases.
operatorOperate deployed workloads (restart, rollback, inspect) without changing configuration.
viewerRead-only access.
Not every role is meaningful on every resource type — for example, billing_admin only applies at the org level. The sync rejects unsupported combinations.

​
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: 
kind: AccessPolicy
metadata:
  name: platform-staging-devs
spec:
  members:
    - user:alice@company.com
    - user:bob@company.com
  grants:
    - developer:environment:staging
    - viewer:environment:production
    - viewer:service:*

​
Service-scoped operators

Give the on-call team operator access to a specific service across all environments: 
kind: AccessPolicy
metadata:
  name: api-oncall
spec:
  description: On-call engineers — operate the api service
  members:
    - user:oncall-1@company.com
    - user:oncall-2@company.com
  grants:
    - operator:service:api
    - viewer:environment:*

​
Deploy bot

A service user with narrow permissions for CI/CD: 
kind: AccessPolicy
metadata:
  name: ci-deploy-bot
spec:
  members:
    - service-user:deploy-bot
  grants:
    - developer:service:*
    - viewer:environment:*

​
Org admins

A small policy granting org-level admin to founders: 
kind: AccessPolicy
metadata:
  name: founders
spec:
  members:
    - user:founder-1@company.com
    - user:founder-2@company.com
  grants:
    - admin:org