Platform RBAC

Platform RBAC controls what platform users and API keys can do. Platform roles (platform_admin, platform_operator, platform_viewer) are stored in the unified roles table under org_platform and use the same RBAC infrastructure as tenant roles.

Built-in Roles

Three roles are available out of the box:

Role	Description	Key Capabilities
`platform_admin`	Full platform access	All operations including user management, write impersonation, and key management
`platform_operator`	Operational access	Tenant management, full impersonation, read access to users/keys/roles
`platform_viewer`	Read-only access	View users, keys, roles, tenants, and audit logs; read-only impersonation

Built-in roles cannot be deleted or modified.

Assigning Roles

To Users

Assign roles when creating a user:

ironflow platform users create --email ops@example.com --name "Operator" \
  --role-ids role_platform_admin

Or via the API:

curl -X POST http://localhost:9123/api/v1/platform/users \
  -H "Authorization: Bearer $PLATFORM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "ops@example.com",
    "password": "secure-password",
    "name": "Operator",
    "role_ids": ["role_platform_admin"]
  }'

To API Keys

Assign roles when creating a key:

ironflow apikey create ops-key --platform

Action Reference

Platform actions control access to specific operations:

Action	Description
`platform:users:read`	List and view platform users
`platform:users:manage`	Create, update, and delete platform users
`platform:keys:read`	List and view platform API keys
`platform:keys:manage`	Create, rotate, and delete platform API keys
`platform:roles:read`	List and view platform roles and policies
`platform:roles:manage`	Create, update, and delete custom roles and policies
`platform:tenants:read`	List and view tenant organizations
`platform:tenants:manage`	Provision and delete tenant organizations
`platform:impersonate:read`	Read-only access to tenant data via impersonation
`platform:impersonate`	Write access to tenant data via impersonation (POST, PUT, DELETE)
`platform:audit:read`	Query the platform audit log

Actions by Role

Action	Admin	Operator	Viewer
`platform:users:read`	Yes	Yes	Yes
`platform:users:manage`	Yes	—	—
`platform:keys:read`	Yes	Yes	Yes
`platform:keys:manage`	Yes	—	—
`platform:roles:read`	Yes	Yes	Yes
`platform:roles:manage`	Yes	—	—
`platform:tenants:read`	Yes	Yes	Yes
`platform:tenants:manage`	Yes	Yes	—
`platform:impersonate:read`	Yes	Yes	Yes
`platform:impersonate`	Yes	Yes	—
`platform:audit:read`	Yes	Yes	Yes

Platform vs Tenant RBAC

Aspect	Platform RBAC	Tenant RBAC
Scope	Cross-tenant platform operations	Single organization
Roles	`platform_admin`, `platform_operator`, `platform_viewer`	`admin`, `developer`, `viewer`
Actions	`platform:*` namespace	`functions:`, `events:`, etc.
Custom roles	CEL policies	CEL policies
Key prefix	`ifplatform_`	`ifkey_`

Custom Roles

Create a custom role with specific policies:

ironflow platform roles create support-role --policy-ids pol_abc123

Custom roles allow fine-grained access beyond the three built-in roles. For example, a “support” role that can read tenant data and view audit logs but cannot manage users or keys.

See Custom Roles & CEL Policies for details on writing CEL policy expressions.

Next Steps

Managing Platform Users & Keys — assign roles during user/key creation
Impersonating Tenants — how impersonation permissions work in practice
Platform Roles Reference — complete role and action tables
Platform Architecture — how platform RBAC is evaluated