Access control

Workspace resource permissions, use dependencies, execution identities and least privilege.

VegaFlow authorization has two levels: permissions on a resource family and permissions on a specific object. Grants can target users, groups, roles and service principals.

Use platform access management to set up identities and assignments before granting product permissions.

Protected resources

Permission APIs are available for:

connections;
compute environments;
QuickFlows;
pipeline projects;
Git integrations;
pipeline execution identities.

Each family has collection-level permission endpoints and /{object_id}/permissions endpoints for a specific resource.

Permission API pattern

POST   /vegaflow/connections/{connection_id}/permissions
DELETE /vegaflow/connections/{connection_id}/permissions

GET /vegaflow/connections/{connection_id}/permissions/users
GET /vegaflow/connections/{connection_id}/permissions/groups
GET /vegaflow/connections/{connection_id}/permissions/roles
GET /vegaflow/connections/{connection_id}/permissions/service-principals

The assignment/removal body identifies the subject and permissions. Subject-specific GET routes show direct and derived access. A response can identify access derived from a role or group; clients should not display it as a direct user grant.

Dependency checks

Permission to execute a flow is not enough by itself. The execution principal must also be allowed to:

use the selected compute environment;
use every referenced connection;
resolve the required secret references;
read the project and immutable version;
use the configured execution identity;
write to the selected destination according to its own authorization.

Dependencies are resolved again when a run prepares. Revoking connection access therefore prevents a later run even when the QuickFlow definition has not changed.

Execution identities

A pipeline execution identity is the workload identity used for runtime access. Grant it only the connections, storage prefixes, VegaDB objects and external operations required by that environment. Keep production execution identities separate from interactive developer identities.

Recommended role layout

Role	Typical access
Flow viewer	Read definitions, versions, status and approved logs.
Flow operator	Start, cancel and retry approved flows; use assigned compute and connections.
Flow developer	Create project revisions, development sessions and non-production versions.
Flow deployer	Approve/publish/deploy into selected environments.
Connection administrator	Create/validate connections and bind managed secrets.
Platform administrator	Manage compute policy, organization integrations and permission policy.

Separate deployer from developer for regulated production workflows. Use groups and roles for stable policy and object-level grants for exceptions.

Secret access

Permission to read a connection does not reveal its credentials. Runtime secret resolution is a separate authorized operation, and APIs return references or redacted metadata only. Do not grant direct secret administration merely so a user can run an already-approved flow.