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.

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.

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.

Duplicates #392

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.

@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?

@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.

@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/

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.

@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.