Today, the Pulpcore auth & permission settings look like:
AUTHENTICATION_BACKENDS = ['pulpcore.app.authentication.PulpNoCreateRemoteUserBackend']
REST_FRAMEWORK__DEFAULT_AUTHENTICATION_CLASSES = (
'rest_framework.authentication.SessionAuthentication',
'pulpcore.app.authentication.PulpRemoteUserAuthentication'
)
However, I don't believe Katello makes use of session cookies talking to Pulp. As such, @mdellweg recommends that we remove its use to improve performance and security.
At the same time, Katello only uses the "built in" admin in Pulp. No user gets created in the database. So, it would likely make more sense to enforce that the user needs to be admin to talk to Pulp.
I recommend that the settings change to look like:
# changed
AUTHENTICATION_BACKENDS = ["pulpcore.app.authentication.PulpNoCreateRemoteUserBackend"]
# same
REST_FRAMEWORK__DEFAULT_AUTHENTICATION_CLASSES = (
'pulpcore.app.authentication.PulpRemoteUserAuthentication',
)
# new option
REST_FRAMEWORK__DEFAULT_PERMISSION_CLASSES = [
'rest_framework.permissions.IsAdminUser'
]
I've tested this on Katello/Satellite running Pulpcore 3.63 and 3.73. I tested some more complex workflows like container push and smart proxy syncing. Everything seems to be working as normal.
The question I can't answer is why we ever had rest_framework.authentication.SessionAuthentication in the first place.
Today, the Pulpcore auth & permission settings look like:
However, I don't believe Katello makes use of session cookies talking to Pulp. As such, @mdellweg recommends that we remove its use to improve performance and security.
At the same time, Katello only uses the "built in" admin in Pulp. No user gets created in the database. So, it would likely make more sense to enforce that the user needs to be admin to talk to Pulp.
I recommend that the settings change to look like:
I've tested this on Katello/Satellite running Pulpcore 3.63 and 3.73. I tested some more complex workflows like container push and smart proxy syncing. Everything seems to be working as normal.
The question I can't answer is why we ever had
rest_framework.authentication.SessionAuthenticationin the first place.