-
Notifications
You must be signed in to change notification settings - Fork 45
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 namespaces to be private #1721
Comments
I would not introduce another layer of privacy here. There is enough of flexibility to make a repo under namespace public or private + the rbac. |
The issue here is that everyone can pull from a repository/distribution if it is not flagged as "private" because of this line: pulp_container/pulp_container/app/viewsets.py Lines 1242 to 1247 in 1075b43
I was thinking about extending the "private" flag functionality to namespaces. This would allow administrators to create a protected namespace that can be initialized beforehand. Thus, only authenticated/authorized users can then pull content from it without further administrators' intervention. |
Did you have something specific in your mind? Can you provide a complete example on how to prepare such a protected namespace from the administrator's perspective? |
Can you create instead beforehand a private distribution? |
You can. But, imagine administrators doing this for 30 distributions at once instead of configuring it inside a single namespace. It is a bit cumbersome experience, is not it? This experience has been shared on the discourse thread I attached to the issue description. |
It is not ideal yes, but when you look from another side - where you need to selectively make public X repos public from the namespace it also brings level of inconvenience. Such level of flexibility and granularity always brings also inconveniences depending from which angle you will look. If for the admin is important to have some distributions private, he can create those ahead. As I mentioned, I would not want to deal with situations when namespace is set to private, then another admin persona comes and makes a distribution public. First admin still thinks whole namespace is private but in reality it is not. The flag on the namespace is unreliable, because flag on the distribution overrides it. |
Hmm, you are right. Let this issue sit here for a while as I might think about it a bit more. I am tempted to close it. |
I'm not sure why but even setting
If an authenticated user does a push to
Is it getting put in the default |
I should mention that I only added my above comment to this issue because it seemed directly related to namespace permissions... if you'd rather I open a new issue, just let me know. Edit: I did see in the Discourse discussion that token auth being disabled makes Pulp ignore the RBAC, but we have Edit 2: I actually think I'm running into #1588 again, just from a different angle. |
For what it's worth, nested namespaces (as in #1588) would be a pretty clean solution to this problem, I think. To me, the problem is that "repository" and "distribution" refer to single images (with all their associated tags), which isn't really how people use registries. I want to be able to give a team unfettered control over some namespace while locking everyone else out (which is also what is requested in that Discourse). Then we don't have to make 30+ container images |
The problem here is that repositories created during pushing fall into a different category. You can find them by using the |
Assuming you work with the same distribution as shown (i.e., having base_path equal to |
@grzleadams, once you flag a distribution as "private", users without permissions should not be allowed to pull images from it. If this is really what you experience, please, open a new ticket with a complete reproducer and the plugin version used. |
@ipanova, I still think we should add this functionality. I guess it is more practical to give administrators an option to flag everything as private beforehand. Lacking the communication between the administrators might be worrisome. However, this worry can be extended to other concepts -> (1) one admin syncing repository vs another admin deleting the synced repository, (2) one admin updating distribution vs another admin reverting the update, etc. |
I am not against this feature extension. We just will need to make sure the flags on namespace and distribution are taken into account correctly. |
Add a private attribute to the namespace model. This could allow administrators to create just a namespace in advance, lock it for specific users, and permit the consumption from the namespace accordingly.
Some administrators do not want unauthenticated users to be able to pull the images by default.
https://discourse.pulpproject.org/t/container-pull-permission/1300
The text was updated successfully, but these errors were encountered: