Use access rights to restrict pipeline access

[JeanMertz]

Building on top of #19.

Once people can/have to authenticate themselves, it becomes possible to segregate people into groups with different access rights.

Similar to the linked issue, this is not about keeping outside people out, it's about having a simple way to give people within your organisation access to the exact pipelines they need, or keep some of the more destructive pipelines limited to a small part of the organisation.

The goal is to make it easy to restrict people from having access to one or more pipelines (denied list), or the reverse, to give them access to a subset of pipelines (allowed list).

For this to work, there needs to be a common type to base these access rights on.

One option would be to allow adding tags to pipelines, which can then be used in these allow/deny lists for access control.

I don't know what the right solution is, but I do think it's important to keep it as simple as possible, but also give us some flexibility for the future (that's why tags could be a solution, as it allows more useful patterns in the future based on these primitives).

[JeanMertz]

Some more thoughts on this (also based on the thoughts in #39).

• Tasks can have one or more labels attached to them.
• A label is a string matching [a-z0-9_]+.
• A session record in the database can be associated with one or more labels.
• For a session, these are called privileges.
• If a session record has a privilege associated with it, any task that implements at least that name as its label can be run by anyone using that session in their client of choice.
• There is no such thing as "global" or "default" labels, if you want to have a privilege/label apply to every session or every task, make sure your scripts (or clients) to create new tasks/sessions automatically add said label.
• (optional, tbd.) You can use a simple wildcard at the end of a privilege as a catch-all pattern: team_a_* will match both team_a_task_1 and team_a_task_2 labels (in this case, the string pattern for privileges (not labels) becomes [a-z0-9_]+\*?). _{(I don't think the added complexity makes sense, as you can just as easily add a second label team_a to all the relevant tasks)}
• When fetching a session with a given token, the server returns the privileges attached to that session.
• The client caches those privileges for the duration of the running application, checking them against the required task labels.
• When fetching task details via the API, the labels applied to those tasks are also returned.
• All GraphQL queries are accessible without authentication.
• All GraphQL mutations require authentication (except creating jobs).
  • Each mutation has its own special label (currently mutation_create_task, mutation_create_job_from_task, mutation_create_global_variable and mutation_create_session)
  • These can also be assigned to sessions, to allow running these mutations either via a client, or using the GraphQL playground
  • All mutation_* and query_* labels are reserved for future use, and cannot be assigned to tasks (but can be assigned to sessions as privileges).
• Other than what's listed above, there are no constraints on the privileges you can assign to a session, or labels to tasks. Meaning, you can add a privilege hello_world to a session, even if there are no tasks that have a label matching that name.
• If a future task does add that label, existing privileges matching that label take effect immediately.

[JeanMertz]

This has been implemented in bf9ffe4.