1.3.4 User Roles & Permissions

Concourse Admin

Admin is a special user attribute granted only to owners of the main team.

Admins have the ability to administrate teams using fly set-team, fly destroy-team, fly rename-team, etc.

Admins always have permission to perform any action on any team. You cannot assign actions to the admin role using the --config-rbac flag.

The following actions are also assigned to admins, and cannot be reconfigured:

- GetLogLevel
- ListActiveUsersSince
- SetLogLevel
- GetInfoCreds
- SetWall
- ClearWall

owner role

Team owners have read, write and auth management capabilities within the scope of their team, and can rename or destroy the team.

Actions assigned to the owner role by default:

owner:
- SetTeam
- RenameTeam
- DestroyTeam

member role

Team members can operate within their team in a read & write fashion, but they can not change the configuration of their team.

Actions assigned to the member role by default:

member:
- SaveConfig
- CreateBuild
- DeletePipeline
- OrderPipelines
- OrderPipelinesWithinGroup
- ExposePipeline
- HidePipeline
- RenamePipeline
- ArchivePipeline
- CreatePipelineBuild
- RegisterWorker
- LandWorker
- RetireWorker
- PruneWorker
- HeartbeatWorker
- DeleteWorker
- HijackContainer
- ReportWorkerContainers
- ReportWorkerVolumes
- CreateArtifact
- GetArtifact

pipeline-operator role

Team pipeline operators can perform pipeline operations such as triggering builds and pinning resources, however they cannot update pipeline configurations.

Actions assigned to the pipeline-operator role by default:

pipeline-operator:
- AbortBuild
- RerunJobBuild
- CreateJobBuild
- PauseJob
- UnpauseJob
- ClearTaskCache
- UnpinResource
- SetPinCommentOnResource
- CheckResource
- CheckResourceWebHook
- CheckResourceType
- EnableResourceVersion
- DisableResourceVersion
- PinResourceVersion
- PausePipeline
- UnpausePipeline
- ClearResourceCache

viewer role

Team viewers have "read-only" access to a team and its pipelines. This locks everything down, preventing users from doing a fly set-pipeline or fly intercept.

Actions assigned to the viewer role by default:

viewer:
- GetConfig
- GetCC
- GetBuild
- GetCheck
- GetBuildPlan
- ListBuilds
- BuildEvents
- BuildResources
- GetBuildPreparation
- GetJob
- ListAllJobs
- ListJobs
- ListJobBuilds
- ListJobInputs
- GetJobBuild
- GetVersionsDB
- JobBadge
- MainJobBadge
- ListAllResources
- ListResources
- ListResourceTypes
- GetResource
- ListResourceVersions
- GetResourceVersion
- ListBuildsWithVersionAsInput
- ListBuildsWithVersionAsOutput
- GetResourceCausality
- ListAllPipelines
- ListPipelines
- GetPipeline
- ListPipelineBuilds
- PipelineBadge
- ListWorkers
- DownloadCLI
- GetInfo
- ListContainers
- GetContainer
- ListDestroyingContainers
- ListVolumes
- ListDestroyingVolumes
- ListTeams
- GetTeam
- ListTeamBuilds
- ListBuildArtifacts

Action Matrix

In this table, an action is marked as customizable if it is possible to change its permissions by providing the --config-rbac flag, documented below. Assigning an action to a role that is not customizable will have no effect on its permissions.

Configuring RBAC

It is possible to promote or demote the roles to which actions are assigned by passing the --config-rbac to the concourse web command with a path to a .yml file, like the following:

concourse web --config-rbac=/path/to/rbac/config.yml

This file should be a YAML map where the keys are role names (owner, member, pipeline-operator, and viewer are valid). For each role, the value should be a list of actions. On startup, Concourse will assign each role to its associated list of actions.

For example, in the default configuration only pipeline-operators and above can abort builds. To restrict aborting builds to only members and above, you could pass this as a --config-rbac file:

member:
- AbortBuild

On the other hand, only members and above can order pipelines by default. To extend this privilege down to pipeline-operators, you can use a --config-rbac file like the following:

pipeline-operator:
- OrderPipelines

You do not need to specify a role for every possible action; if an action does not appear in the file, then the default role (as described in the sections above) will be assigned to that action. Also, please avoid specifying the same action under multiple roles in this file - it can have unpredictable results.