-
Mariner depends on the Workspace Token Service (WTS) to access data from the commons. If WTS is not already running in your environment, deploy the WTS.
-
Add the Mariner pieces to your manifest:
- Deploy the Mariner server by running
gen3 kube-setup-mariner
-
Mariner utilizes Gen3's policy engine, Arborist, for authorization. Make sure you have the following Mariner auth scheme in your User YAML:
- Policy
- id: 'mariner_admin' description: 'full access to mariner API' resource_paths: ['/mariner'] role_ids: ['mariner_admin']
- Resource
- name: 'mariner' description: 'workflow execution service'
- Role
- id: 'mariner_admin' permissions: - id: 'mariner_access' action: service: 'mariner' method: 'access'
- Policy
-
Give the
mariner_admin
policy to those users who need it.
policies:
- mariner_admin
Right now the Mariner auth scheme is atomic - you either have access to all the API endpoints or none of them. In order for a user to interact with Mariner, that user will need to have Mariner admin privileges.
A Mariner admin can do the following:
- Run workflows
- Fetch run status via runID
- Fetch run logs and output via runID
- Cancel a run that's in-progress via runID
- Query run history (i.e., fetch a list of all your runIDs)