Authentication through Log In

Problem:
Trying to authenticate through login throws out error

Pulpcore version:
3.29.1

Pulp plugins installed and their versions:

"versions": [
    {
        "component": "core",
        "version": "3.29.1",
        "package": "pulpcore",
        "domain_compatible": true
    },
    {
        "component": "ansible",
        "version": "0.18.0",
        "package": "pulp-ansible",
        "domain_compatible": false
    },
    {
        "component": "certguard",
        "version": "1.6.5",
        "package": "pulp-certguard",
        "domain_compatible": true
    },
    {
        "component": "container",
        "version": "2.15.1",
        "package": "pulp-container",
        "domain_compatible": false
    },
    {
        "component": "deb",
        "version": "2.21.0",
        "package": "pulp_deb",
        "domain_compatible": false
    },
    {
        "component": "file",
        "version": "1.14.3",
        "package": "pulp-file",
        "domain_compatible": true
    },
    {
        "component": "maven",
        "version": "0.6.0",
        "package": "pulp-maven",
        "domain_compatible": false
    },
    {
        "component": "ostree",
        "version": "2.1.1",
        "package": "pulp-ostree",
        "domain_compatible": false
    },
    {
        "component": "python",
        "version": "3.10.0",
        "package": "pulp-python",
        "domain_compatible": false
    },
    {
        "component": "rpm",
        "version": "3.22.2",
        "package": "pulp-rpm",
        "domain_compatible": true

Operating system - distribution and version:
Pulp3 through Pulp Operator 1.0.0-alpha.8 ( latest version in the GitHub repo ) deployed in Kubernetes v1.25.6

Other relevant data:
When trying to auth through log in I get thrown an error. Whenever i try to go to another path rather then /auth/login e.g. “/pulp/api/v3/artifacts” and I authenticate with the same credentials through that path then it works. Just wondering if something I did wrong led to this or is this a bug ?


Hey there @AJJA - the Django web interface has been disabled in Pulp since core/3.19. You can see discussion on the reasoning in the core/3.19 changelog, and in a similar discourse thread

Sorry, Grant, but this DRF Web console is different from the django admin interface. And it should be safe to use, because it is only generating REST api calls.
The django-admin however talks to the orm directly, which we consider to be unsafe (breaking assumptions in the application logic).

What do you mean by: “… I authenticate with the same credentials through that path …”? Is this basic auth with every request?
What this login page is supposed to do is to provide an authenticated session. I think with cookies. But the CSRF protection kicks in.

Maybe pulpcore-manager check --deploy can give more hints.

1 Like

Ah, of course! I suspect my brain triggered on “admin” and went on its merry way. :slight_smile: Thanks for the correction Matthias!

1 Like

cli.toml (in the proper directory) works for the pulp cli. curl needs the credential in it’s own format.
Your command from above roughly resembles pulp artifact list using the cli.

1 Like

Hi @ akhilreddynalla,

-bash-4.2$ kubectl -n pulp3 exec deployment.apps/pulp-ha-api –- curl -sL pulp-api-svc.pulp.svc.cluster.local:24817/pulp/api/v3/artifacts/ && echo

Some things took my attention in this command:

  • the exec is running in pulp3 namespace, but pointing to a service running in pulp namespace
  • the Deployment is called pulp-ha-api, but the Service is called pulp-api-svc … the default behavior of the operator is to use the same name for the Deployment and the Service, so this is probably another clue that this Service is indeed used by another Pulp installation

“I have setup Pulp3 on the AWS EKS cluster. Can anyone please assist me in obtaining credentials in the proper manner?”

By default, if you didn’t provide an admin_password_secret in Pulp CR, the operator will create a random password for you in a secret called: <Pulp CR name>-admin-password.
Based on your deployment name, I guess your Pulp CR is called “pulp-ha”, so to extract the admin-password (if you didn’t provide a custom one) you can run something like:

$ kubectl -npulp3 get secrets pulp-ha-admin-password -ojsonpath='{.data.password}'|base64 -d

and you can check the credentials through

$ PULP_ADMIN_PWD=$(kubectl -npulp3 get secrets pulp-admin-password -ojsonpath='{.data.password}'|base64 -d)
$ kubectl -npulp3 exec deployment.apps/pulp-ha-api -- curl -u admin:$PULP_ADMIN_PWD -sL localhost:24817/pulp/api/v3/artifacts/

“Just want to know how can I change my default credentials and login into pulp where I hosted pulp on EKS cluster”

You can modify your admin-password secret and restart pulp-api pods:

$ kubectl create secret generic <YOUR ADMIN PWD SECRET> --from-literal=password=<NEW PASSWORD> --dry-run=client -oyaml  |kubectl apply -f-
$ kubectl rollout restart deployment/<PULP API DEPLOYMENT> 

for example:
$ kubectl -npulp3 create secret generic pulp-ha-admin-password --from-literal=password=supersecretpassword --dry-run=client -oyaml |kubectl -npulp3 apply -f-
$ kubectl -npulp3 rollout restart deployment/pulp-ha-api

note: I’m currently working on a PR to remove the need of restarting API pods in case of an “admin-password” Secret modification, but for now this is necessary because we are running some scripts only during API pods initialization.

Doc with more details:
https://docs.pulpproject.org/pulp_operator/configuring/secrets/#pulp-admin-password

Hi @hyagi @x9c4 , Thanks for response

image
i have setup pulp operator on EKS cluster while to get status it throwing error Error: Invalid URL ‘/pulp/api/v3/docs/api.json’: No schema supplied. Perhaps you meant http:///pulp/api/v3/docs/api.json?

Expected: need to login to pulp and create repository & store content in s3 bucket

Hum… ok, I believe we can start by checking the access to your cluster:

  • you mentioned that this is an EKS installation and from the screenshot provided I can see that all components are in a RUNNING/HEALTHY state
  • the pulp status command that you tried to run was executed from “outside of k8s” (for example, you are not running it from a pod running that runs in the same EKS cluster), correct?
  • if you are trying to access Pulp from your personal computer, we need to expose Pulp to outside of k8s: Exposing Pulp - Pulp Operator. Can you confirm if this is already possible or do you need help with this configuration too?

Can you share your Pulp CR? (please, paste the output from the command, not a screenshot)

$ kubectl -npulp3 get pulp pulp-ha -ojsonpath='{.spec}'

If you are exposing Pulp using Ingress you can configure your pulp-cli (~/.config/pulp/cli.toml file) like:

[cli]
base_url = "https://<Ingress host>"
verify_ssl = false
format = "json"

and you can set the credentials in a ~/.netrc file:

machine <Ingress host> login admin password <password>

So basically if I go through the log in and do username password it wont go through but rather if I make a request to /pulp/api/v3/artifacts/ and there I provide the credentials then I am logged in and can access everything.

{“admin_password_secret”:“pulp-ha-admin-password”,“api”:{“gunicorn_timeout”:90,“gunicorn_workers”:2,“replicas”:4},“container_auth_private_key_name”:“container_auth_private_key.pem”,“container_auth_public_key_name”:“container_auth_public_key.pem”,“container_token_secret”:“pulp-ha-container-auth”,“content”:{“gunicorn_timeout”:90,“gunicorn_workers”:2,“replicas”:4},“db_fields_encryption_secret”:“pulp-ha-db-fields-encryption”,“deployment_type”:“pulp”,“image”:“quay.io/pulp/pulp-minimal",“image_pull_policy”:“IfNotPresent”,“image_version”:“stable”,“image_web”:“quay.io/pulp/pulp-web”,“image_web_version”:“stable”,“mount_trusted_ca”:false,“object_storage_s3_secret”:“pulp-ha”,“web”:{“replicas”:4},“worker”:{"replicas”:4}}

output for : ```
$ kubectl -npulp3 get pulp pulp-ha -ojsonpath=’{.spec}’

@hyagi please check pulp CR as requested

So yes, the login page needs to authenticate a session, and there seems to be something misconfigured with the CSRF protection (cross site request forgery). Going to the api endpoint with curl/httpie directly or using the CLI authenticates all requests individually using BasicAuth.
Have you tried this command?

Didn’t give much.

bash-4.4$ pulpcore-manager check --deploy
Traceback (most recent call last):
  File "/usr/local/bin/pulpcore-manager", line 8, in <module>
    sys.exit(manage())
  File "/usr/local/lib/python3.8/site-packages/pulpcore/app/manage.py", line 11, in manage
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 412, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 458, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.8/site-packages/django/core/management/commands/check.py", line 76, in handle
    self.check(
  File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 485, in check
    all_issues = checks.run_checks(
  File "/usr/local/lib/python3.8/site-packages/django/core/checks/registry.py", line 88, in run_checks
    new_errors = check(app_configs=app_configs, databases=databases)
  File "/usr/local/lib/python3.8/site-packages/django/core/checks/security/base.py", line 222, in check_secret_key
    passed_check = _check_secret_key(secret_key)
  File "/usr/local/lib/python3.8/site-packages/django/core/checks/security/base.py", line 209, in _check_secret_key
    len(set(secret_key)) >= SECRET_KEY_MIN_UNIQUE_CHARACTERS
TypeError: 'bool' object is not iterable

This is actually something!
The Django SECRET_KEY is set to True. I don’t know who came to the glorious idea of doing that for development, but in a production system, you really need a proper secret key. It is among other things used to calculate CSRF tokens. Since you installed via an operator, you are running pulp in a kubernetes environment. So i’d suggest you to look into cluster secrets. Actually, I think the operator should take care of this.

I filed an issue against the operator for this. https://github.com/pulp/pulp-operator/issues/1040