Permissions

A permission defines which API and CLI actions an access token can take. Permissions are chosen the same way for both kinds of token:

Permission keys

Every permission is identified by a resource:action key, such as run:create or vault:unlock.

Only permissions a token can exercise through the API or the CLI are available.

Available permissions

ResourceKeyWhat it allows
Runsrun:createTrigger new runs.
run:readView run details, logs, and task outputs.
Dispatchesdispatch:runTrigger a dispatch.
Vaultsvault:createCreate new vaults.
vault:write

Add, update, and remove secrets and vars in the vault.

vault:create_secretAdd secrets to the vault.
vault:update_secretEdit, rotate, and remove secrets in the vault.
vault:create_varAdd vars to the vault.
vault:update_varEdit and remove vars in the vault.
vault:unlock

Unlock the vault to access secrets in a run.

vault:manageManage vault settings and delete the vault.
Imagesimage:push

Push container images to a registry using rwx image push.

Captaincaptain:runSubmit test results to Captain.

Coarser permissions grant finer ones

A coarse permission automatically grants the finer permissions it implies. For example:

  • run:create grants run:read. You can't trigger a run without being able to read it.
  • vault:write grants vault:create_secret, vault:update_secret, vault:create_var, and vault:update_var.

vault:manage does not grant vault:create. A token can reconfigure and delete existing vaults without being able to add new ones.

Scoping vault permissions to specific vaults

Vault permissions can be applied to all vaults or only specific ones. A single token can have different permissions across different vaults.

You can only grant permissions you hold

A token is limited to the permissions you have yourself. Anything you don't hold isn't offered when you choose a token's permissions.

For a scoped vault permission, you can only target vaults you hold that permission on.