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

Add Domain and/or RBAC (multi-tenancy) support #860

Open
netsandbox opened this issue Aug 8, 2023 · 10 comments · May be fixed by #1062
Open

Add Domain and/or RBAC (multi-tenancy) support #860

netsandbox opened this issue Aug 8, 2023 · 10 comments · May be fixed by #1062
Labels
.feature CHANGES/<issue_number>.feature

Comments

@netsandbox
Copy link

Is your feature request related to a problem? Please describe.
As a user, I'd like to have application level multi-tenancy, like pulp_file and pulp_rpm has.

Describe the solution you'd like
Enable domain support: https://docs.pulpproject.org/pulpcore//workflows/domains-multi-tenancy.html

Additional context

@quba42
Copy link
Collaborator

quba42 commented Aug 14, 2023

This is a perfectly reasonable feature request that we don't currently have on our roadmap. This goes for both RBAC and Domains.

What would help us to get this process of the ground, is if you could describe some concrete example workflows/use cases, that you would like to see in pulp_deb. Something like: "In pulp_file/rpm we have user A with permissions B taking action x on repo y, but also user C with permissions D who should only be able to take action z."

Currently the pulp_deb plugin maintainers have no experience working with RBAC or Domains, either for pulp_deb or any other plugins. We would like to support this feature at some point, but we don't currently need it for our own use cases. As a result, a detailed description of someone else's use case, who would like to see this feature, would be very valuable for us.

@netsandbox
Copy link
Author

Currently we have for each of our customer a separate pulp instance, to build the packages for our customers and distribute the packages to them. This is because we have to separate the packages so that the customers don't see packages of other customers.

To simplify our infrastructure, we would like to consolidate all the customer pulp server to one centralized pulp server.
But we need the domain feature for the separation of each our customer pulp repositories.

@mdellweg
Copy link
Member

To simplify our infrastructure, we would like to consolidate all the customer pulp server to one centralized pulp server.
But we need the domain feature for the separation of each our customer pulp repositories.

Now here's an important question: How much separation is desired? Or: What is shared.
For just "not seeing other peoples content", RBAC may be sufficient. Content and artifacts will still be deduplicated with this architecture. Also all the infrastructure (workers, content servers, ...) will be shared. Also there will be a shared namespace for e.g. repository names, distribution names and base_paths, ...

With domains, each domain will have a separate namespace for all these objects, and the artifact storage will be separated. Deduplication will only happen within the same domain, so the storage requirements will roughly match your current setup. Bonus: You can configure the storage backend separately for each domain. "Bring your own storage bucket." Not, you can still use RBAC within a domain. In comparison to your current setup, the infrastructure will be shared between domains, users and groups can be granted to operate in multiple domains (not in a single request) and access policies and roles are global too.

@quba42 quba42 added .feature CHANGES/<issue_number>.feature and removed Feature labels Aug 23, 2023
@quba42 quba42 changed the title Add Domain (multi-tenancy) support Add Domain and/or RBAC (multi-tenancy) support Aug 23, 2023
@quba42
Copy link
Collaborator

quba42 commented Aug 23, 2023

Duplicates #392

@quba42 quba42 added the Looking_for_Contributor For valid issues that the plugin maintainers have no plans to implement. label Aug 24, 2023
@maggu maggu linked a pull request Apr 5, 2024 that will close this issue
@ananace
Copy link

ananace commented Apr 25, 2024

Hello, a colleague to @maggu here, to fill in on our preferred use cases.

Our main use case is with CI pipelines, where a user exists which has the necessary permissions to see and upload content to a given set of repositories, and only those repositories. (Seeing other repositories is acceptable)
The user should also have the necessary permissions in order to remove the uploaded content again from its assigned repositories.
Furthermore, that same user should be able to publish the repository changes - and therefore also publish changes for removed content - for the same limited list of repositories. As an alternative, this could be done through an auto-publishing repository.

We would also like to be able to let the CI user copy content from the upload repository to a secondary set of repositories, to allow tiered rollout of changes. As an alternative, this could be done through a regular upload to the secondary set of repositories.

The described user should not have the ability to modify any other repositories than those assigned to it, nor modify the definitions for its assigned upload repositories.

@quba42
Copy link
Collaborator

quba42 commented Apr 26, 2024

@ananace @maggu Do you already have a set of API calls/commands to create the user in question for a Pulp instance running the changes from your PR?

@maggu
Copy link

maggu commented May 8, 2024

@quba42 Not yet so far. I tested through the basic cases before submitting the PR, but didn't save the exact commands I used. Work is planned to test all cases more thoroughly.

@cleonn
Copy link

cleonn commented Jun 20, 2024

@quba42 The following commands have been tested by us. This is the commands we think is the minimum we need for it to work.

Create user:
pulp user create --username <user> --password <pass>

Create the repositories (one to test allowed access and one to test denied access):

pulp deb repository create --name allowed_access
pulp deb repository create --name denied_access

Create role with least amount of privileges :

pulp role create --name allowed-to-upload --permission deb.modify_content_aptrepository --permission deb.view_aptrepository
pulp user role-assignment add --username <user> --role allowed-to-upload --object <allowed pulp_href>

Check upload privileges (either of the following two commands are valid, first is using httpie, second uses Curl):
http -a <user>:<pass> --form POST <PULP_HOST>/pulp/api/v3/content/deb/packages/ file@<deb package> repository=<allowed_access pulp_href|denied_access pulp_href>

Or:

curl -u <user>:<pass> -F "file=@<deb package>" -F repository=<allowed_access pulp_href|denied_access pulp_href> <PULP_HOST>/pulp/api/v3/content/deb/packages/

@quba42 quba42 removed Triage-Needed Looking_for_Contributor For valid issues that the plugin maintainers have no plans to implement. labels Jun 21, 2024
@quba42
Copy link
Collaborator

quba42 commented Jun 26, 2024

Update: We are pretty swamped right now, so I am not certain how soon I will get around to continuing with this review. It is on my list and will be returned to.

@maggu
Copy link

maggu commented Sep 16, 2024

@quba42 The following commands have been tested by us. This is the commands we think is the minimum we need for it to work.

Tests have been added in #1062 to cover these.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
.feature CHANGES/<issue_number>.feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants