Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow limiting via access #1

Closed
wants to merge 1 commit into from

Conversation

drubin
Copy link

@drubin drubin commented Jan 15, 2018

Thank you @bufferoverflow for this epic work! This is something I actually have been wanting to implement for a while

I am trying to allow limit access to the repositories via the same gitlab Authentication, I managed to very hackily copy and paste the allow_publish.

I know this is less than ideal but what I am trying to do is the following.

Figure out how we can allow publish to user's that have master access to groups. Allow view access to anyone that has view access via gitlab.

Is this something you think is possible and any tips on how "best" to achieve this? From what I can see the auth plugins are pretty limited there doesn't seem to be an easy way to re-authenticate or dynamically pull the groups at publish/access time?

I still don't understand why the standard access: $authenticated doesn't actually work without copying and pasting these methods?

@bufferoverflow
Copy link
Owner

@drubin thanks for your contribution!

Limiting access was not in scope until now, access is given to everyone as mentioned within the README.md.

I currently do not see a use-case where limiting access makes sense. Could you please elaborate a bit more on that use-case?

The groups associated with the user during authentication are owned top level groups, other permissions such as master or developer rights are not handled until now.

@drubin
Copy link
Author

drubin commented Jan 15, 2018

@bufferoverflow thanks for the fast reply. The idea was to use it as a private registry (is this insane?) It seemed like a trivial addition (if you ignore my copy/paste code) so I wanted to find out if this is something that you would be keen on doing?

My goal was to get verdaccio-gitlab on the same level as their integration with the container registry, and turn the gitlab integration into a really amazing addition and simplify management for internal NPM packages that use gitlab's authentication.

I would even be happy with the packages being restricted to logged in users (I tried via the config but that didn't work until I added the allow_access method)

     access: $authenticated
     publish: $authenticated

The other thing is that the default package/permissions linking with a direct 1-1 relation with the package name and the repo names. Would it be possible to prefix them with a company name? Something similar to @corpname/group/project or something similar.

Not sure why but it feels like verdaccio recommend pre-fixing internal/private packages by a name https://github.com/verdaccio/verdaccio/blob/master/website/translated_docs/ur-PK/packages.md

The real power of this comes in when you leverage gitlab's CI permission model. Each job is assigned a unique token that runs with the same permission as the user that triggered the job. So if the user has permission to push to the repository they could have access to deploy.

https://docs.gitlab.com/ce/user/project/new_ci_build_permissions_model.html

@bufferoverflow
Copy link
Owner

Yes similar to the Docker Registry integration would be cool. I'm quite familiar with the container registry and the integration concepts, see https://gitlab.com/gitlab-org/gitlab-ce/issues/3299#note_4265537 .

I fully agree, CI integration will bring in the real power to this and will have a closer look at it as soon as I have some time.

Regarding prefixes, I'm not a big fan of it.

@drubin
Copy link
Author

drubin commented Jan 16, 2018

@bufferoverflow The prefix idea was actually more a "hack" to enforce permissions but maybe there are better ways around it.

I wanted a way to enforce that the package comes from the verdaccio repo and not potentially an upstream one.

For now, my biggest issue is simply making the packages only accessible to logged in authenticated users.

Is there something I could do/improve to get that functionality? I would love to roll this out to get some real feedback/usage from it but I would prefer the packages are not public. Even without complicated permissions if you have a gitlab account you could read.

I mean I could use a fork for now which does this but I would really love to stay with your version if at all possible.

@drubin
Copy link
Author

drubin commented Jan 22, 2018

@bufferoverflow I also found https://github.com/crispy1989/sinopia-gitlab which handles access control as well.

But I think there are a few too many configuration options there which I get why you might not want to allow prefixing.

Do you think you will allow limited access to published packages to only logged in users?

@bufferoverflow
Copy link
Owner

Limit access to authenticated users makes sense, feel free to file an issue for this and close this PR. The other topic is publish via gitlab ci, I started to look at the details already, it might require some changes on GitLab as well, but we will see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants