Pulp

Ticket moved to GitHub: "pulp/pulpcore/1953":https://github.com/pulp/pulpcore/issues/1953

I am using pulp 2.21.2. I wrote some scripts recently to create "service accounts" that are meant for CI pipeline interactions with building pkgs and publishing to pulp. As part of this design, we are generating long lasting user certs such that there isn't a need to authenticate interactively as that service account user within the CI pipeline. This works, however, there are some security concerns that have come out of this based on the behavior of "pulp/server/webservices/views/decorators.py", specifically, the _verify_auth function design under the following conditions:

• user cert still valid (within time range and signed by pulp CA)
• user administratively removed along with permissions

here is the concern:

when assigning CRUDE ops to these service accounts, I am only assigning full CRUDE to a single repository for various reasons. so a pulp-admin rpm repo list using this service account will fail with permissions issue (which is desired and working). the _verify_auth function correctly authenticates using the user_cert_authentication method.

However, if I delete this service account user and the permissions assigned in pulp, I can still use the long lasting cert to gain privilege in that a pulp-admin rpm repo list will succeed for all repos (including ones that the service account originally did not have access to). it appears like _verify_auth function would "authenticate" this non-valid pulp user via the consumer_cert_authentication method (which imho is incorrectly authenticated) and based on the reference in that same module:

DEFAULT_CONSUMER_PERMISSIONS = {'/v2/repositories/': [READ]}

suggests that a consumer authenticated id would have full read access to all repos via this rest endpoint. This access violates the original permissions tied to a single repo for this service account and in effect elevates the privilege in the event of the service account being deleted, while still holding a valid cert (time range and CA) used to authenticate.

an example of some data that we don't not want the service account to see would be metadata for another repo outside of the service account's original repo access.

I thought of a strawman suggestion; leverage the consumer* models and verify that the id out of the cert is in the consumer* collections prior to authorization (perhaps prior to setting is_consumer). it looks like there is precedent for using models here because the function does this if is_consumer is not set by checking to verify that the user is valid from the database. e.g. user = model.User.objects.get(login=login) given that when I remove a user from pulp, I am effectively removing the user and its permissions from the database, if it checked to see that there isn't a consumer for this user / id, it shouldn't assume that the cert is held by a consumer...just a quick thought.