RBAC as code

Manage e6data roles, groups, and bindings programmatically over the Management API, so access is version-controlled and flows by group membership.

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

1. Discover available actions: GET /api/v1/authz/resources-actions returns the resources and actions you can grant.
2. Create roles and groups: POST /api/v1/roles and POST /api/v1/groups.
3. 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.
4. Add members to groups so access flows by membership, not by per-user grants.
5. 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.