Skip to content

Instantly share code, notes, and snippets.

@msteffen

msteffen/Discarded Issue: Auth for Pachyderm Commits and Branches.md

Created December 21, 2017 18:25
Show Gist options
  • Save msteffen/e1eb25575808e1cabe4f4b064368d1f8 to your computer and use it in GitHub Desktop.
Save msteffen/e1eb25575808e1cabe4f4b064368d1f8 to your computer and use it in GitHub Desktop.
Download ZIP
Discarded issue: Auth for Pachyderm Commits and Branches
Raw
Discarded Issue: Auth for Pachyderm Commits and Branches.md

Background

In the course of working on pachyderm/pachyderm#2505, JD and I ran into a conflict between that design and our auth model:

If PipelineInfo documents are stored in output repos, then e.g. ListPipeline and InspectPipeline have no way to retrieve PipelineInfos for users who don't have access to the pipeline's output repo.

This means that ListPipeline no longer returns all PipelineInfos in a DAG (and may not even return most of the PipelineInfos) in a DAG, which I believe breaks some of the assumptions in our dashboard rendering algorithm (see Alternatives Considered for some of the conceptual problems I ran into while trying to think of solutions).

While we could hack around this issue (again, see Alternatives Considered below), I think this may be an opportunity to move our auth system in the direction of a role-based auth system similar to the one in GCP, AWS and etcd.

Alternatives Considered

  • The most obvious alternative is to call the incomplete results of ListPipeline a feature: @gabrielgrant and @JoeyZwicker have been interested in restricting discoverability for a while (for large organizations with many independent teams managing roughly independent DAGs). Not returning all pipelines from ListPipeline seems like a good step in that direction.
    • The problem with this is that I couldn't come up with a definition of discoverability that made sense.
    • For example, if ListPipeline only returns a subset of pipelines, but ListRepo returns all repos, then users may see a large number of orphan repos, which is probably useless (e.g. in the context of a large organization with many independent teams). So ListRepo also needs to be restricted.
    • As well, if ListPipeline returns all pipelines such that the caller (U) has access to the pipeline's output repo, then ListPipeline may return pipelines where the caller can't list (or inspect) all of the pipeline's inputs, so whatever the discoverability criteria for repos are, ListPipeline must check that U can read the pipeline's output and discover all of the pipeline's inputs
    • ListPipeline could return pipelines where U has READER access to all of the pipeline's inputs as well as its output, but if repos are only discoverable to users who already have READER access to them, then users have no way to ask for access to new repos
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment