Provision e6data access control programmatically - roles, groups, and bindings - so permissions live in version control instead of being clicked together in the Console, and access flows by group membership rather than per-user grants.
Workflow
- Discover available actions:
GET /api/v1/authz/resources-actions returns the resources and actions you can grant.
- Create roles and groups:
POST /api/v1/roles and POST /api/v1/groups.
- Bind them:
POST /api/v1/rolebindings attaches a role to a subject (user, group, or service account). Use POST /api/v1/rolebindings/batch to apply many bindings at once.
- Add members to groups so access flows by membership, not by per-user grants.
- Verify before relying on a grant:
POST /api/v1/check-permission confirms an effective permission. Allow a short cache-propagation window - permission changes are eventually consistent.
Access policy endpoints
Workspace-local RBAC is managed through /api/v1/governances, /api/v1/policies/{catalog}, /api/v1/roles, /api/v1/rolebindings (+/batch), /api/v1/groups, and /api/v1/service-accounts (+/keys), plus POST /api/v1/check-permission to verify an effective grant.
The built-in roles are Admin, Manager, and Viewer; create custom roles for tighter scoping.
Notes
- Binding roles to groups, then managing membership, keeps your access model small and auditable: you change one binding instead of many per-user grants.
- Permission changes and token revocations are cache-backed and can take a short time to take effect - design retries and rotations around eventual, not instant, consistency.
- A
403 response names the permission the call needs, which makes it straightforward to grant least privilege.
Last modified on September 29, 2026
