-
Notifications
You must be signed in to change notification settings - Fork 44
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
As a user I want to be able to create nested namespaces #1588
Comments
I do not recall if this is a bug or feature. @ipanova, would you mind chiming in? Right now, we grab the first part of the namespace and check access permissions based on it. To me, it makes sense to find the longest prefix match and do the needful. pulp_container/pulp_container/app/authorization.py Lines 226 to 231 in f377a9c
|
|
Namespace is always the first part until the first occurrence of |
If I'm understanding you correctly and namespaces are restricted to a single "level", then it feels like there's a gap in RBAC; you can only either enforce access at the namespace level or the distribution level (which you, as an admin, may or may not know beforehand). As an admin, I would like to specify access at any "level" (i.e., user A owns |
Depending on the registry, namespace could be nested or have a single depth ( e.g docker registry, quay) There is a challenge when parsing the string when content is being pushed to distinguish what is repo and what is namespace e.g podman push library/rhel/ubi At this stage namespace, distribution and repo are created on the fly and not beforehand. |
i found this article worth reading https://stevelasker.blog/2020/02/17/registry-namespace-repo-names/ we might want to reconsider or not certain logic |
Yeah it's a tough problem because the oci spec supports nested namespaces but, as you pointed out, many registries don't. Just thinking through this though, it doesn't feel like it would be a complicated thing to support; just traverse the path given and see if any matching namespaces/distributions exist. Basically, on push or pull (since the permissions would be applied at the same levels) of image
Then just overlay the permissions in all three levels and flatten to create the permissions object. |
We can re-purpose this as RFE request to support nested namespaces and evaluate its feasibility. |
@grzleadams when it comes to RBAC there is always some complexity ;) |
And just to be completely transparent, I have given almost zero thought as to the performance implications of this... if it increases API calls by 4x then it's probably not worth it, especially if pull-through distributions can be structured to avoid name collisions entirely (which was the main use case I had for this capability and I've spent almost no time testing, so my concerns are even just hypothetical). Life's a lot easier on the sidelines :) |
Might be related to #1534. |
I ran into a strange behavior with respect to RBAC and it's not clear to me why it's happening. Basically, it seems like more-specific role assignments are being overridden by less-specific ones. For example:
I would expect that giving a user owner to a specific namespace (in this case,
myorg/mygroup
) would allow them to push images to it, but they're unable to until they also have permissions formyorg
. That's kind of a bummer, because I would want to give people namespaces to use under a parent namespace, without them being able to push to the parent namespace as well. Is this behavior expected?The text was updated successfully, but these errors were encountered: