Access Control

Access in Governor comes from two roles. A user’s global role applies across the organization, and their role in a project applies to that project’s workflows and data sources. A user can do anything that either role allows.

Global roles

Role Configuration value Can

Role	Configuration value	Can
Member	`MEMBER`	Create, run, change and delete workflows and data sources. Sees the data sources they created and those in their projects. Can’t see other users' private workflows or manage users.
Administrator	`ADMINISTRATOR`	Everything, including user management, the license and vault settings. Can usually see and manage every project, even without being a member.
Owner	`OWNER`	Everything an Administrator can, and transfer ownership.

Member

MEMBER

Create, run, change and delete workflows and data sources. Sees the data sources they created and those in their projects. Can’t see other users' private workflows or manage users.

Administrator

ADMINISTRATOR

Everything, including user management, the license and vault settings. Can usually see and manage every project, even without being a member.

Owner

OWNER

Everything an Administrator can, and transfer ownership.

The configuration value is what you use in GOVERNOR_SECURITY_DEFAULTROLE and in SAML or LDAP role mappings. For each permission, see the permissions matrix.

Project roles

Role	Edit workflows	Edit data sources	Edit project and members	For
Viewer	No	No	No	People who only need to see the workflows and their results
Editor	Yes	No	No	People who create, run and change workflows
Admin	Yes	Yes	Yes	Team leads who manage the project
Owner	Yes	Yes	Yes	The person responsible for the project; the creator is the first owner

Role

Edit workflows

Edit data sources

Edit project and members

For

Viewer

People who only need to see the workflows and their results

Editor

Yes

People who create, run and change workflows

Admin

Yes

Team leads who manage the project

Owner

Yes

The person responsible for the project; the creator is the first owner

See Projects.

Projects and data sources

Every workflow belongs to a project.
All data sources live in one shared pool, but a workflow can use only the data sources added to its project. This keeps each project’s workflows to an approved set of data.
A user sees a data source if they created it, or if it’s in a project they belong to.
To add a data source to a project, a user needs the Admin or Owner role in the project, and permission on the data source: they created it, or they’re an Administrator.
A data source can be Read-only, so no workflow can write to it. Use this for production databases.

See Data sources in a project and Data Sources.

How roles are assigned

Method How it works

Method	How it works
In Governor	Administrators set each user’s global role under Administration, and project admins set project roles. New users get `GOVERNOR_SECURITY_DEFAULTROLE`, `MEMBER` by default. See Administration.
From SAML groups	Governor maps the user’s identity provider groups to a global role at each sign-in, and role management in the web UI becomes read-only. See SAML Group-to-Role Mapping.
From LDAP groups	Governor reads the user’s LDAP groups at sign-in and maps them to a global role. See LDAP Authorities.

In Governor

Administrators set each user’s global role under Administration, and project admins set project roles. New users get GOVERNOR_SECURITY_DEFAULTROLE, MEMBER by default. See Administration.

From SAML groups

Governor maps the user’s identity provider groups to a global role at each sign-in, and role management in the web UI becomes read-only. See SAML Group-to-Role Mapping.

From LDAP groups

Governor reads the user’s LDAP groups at sign-in and maps them to a global role. See LDAP Authorities.

When roles are managed in Governor, the first user who signs in through SAML, or the first LDAP user, becomes the OWNER. Sign in as the intended owner first.

Joiners, movers and leavers

With SSO or LDAP, manage access in your identity provider or directory. A user who is disabled or removed there can’t sign in to Governor.
With roles from SAML or LDAP groups, roles are read again at each sign-in, so moving a user to another group changes their role the next time they sign in.
Administrators can deactivate a user under Administration. A deactivated user can’t sign in. See Administration.

Access keys

Scripts and pipelines call the REST API with an access key. A key can do everything the user who created it can do, and expires after the time chosen when it was created. Create keys as a dedicated user that has access to only what the pipeline needs.

Settings that tighten access

Setting Effect

Setting	Effect
`GOVERNOR_SECURITY_DEFAULTROLE`	The global role new users get. Keep it at `MEMBER`.
`GOVERNOR_SECURITY_OWNERACCESSONLY`	When `true`, users see and access only their own workflows.
`GOVERNOR_SECURITY_SAML_AUTHORITIES_ENABLED`	Takes global roles from SAML groups.

GOVERNOR_SECURITY_DEFAULTROLE

The global role new users get. Keep it at MEMBER.

GOVERNOR_SECURITY_OWNERACCESSONLY

When true, users see and access only their own workflows.

GOVERNOR_SECURITY_SAML_AUTHORITIES_ENABLED

Takes global roles from SAML groups.

See Governor and Worker Settings.

Common setups

A team with its own data

Create a project for the team.
Add the data sources the team’s workflows need.
Add the team’s developers with the Editor role, and its lead with Admin.

Read-only access for auditors

Add the auditors to the relevant projects with the Viewer role.
Remember that the project role doesn’t remove global permissions. With the default MEMBER global role, auditors can still create and change their own workflows and data sources. See the permissions matrix.

Pipelines

Create a user for the pipeline, and add it to only the projects the pipeline runs.
Sign in as that user, and create an access key with the shortest expiry that works.
Keep the key in your CI system’s secret store.