cannot login into docker registry (OD-2547)

brixomatic opened 4 months ago

I want to use OneDev as a Docker registry.

I use OneDev behind a HAProxy for SSL termination. HAProxy terminates SSL on 6510 (public) and forwards to port 6610. Port 6610 is kept on the bridge network and is not public. SSL git port is published on a non standard port 6581 and forwarded to 6611. The domain is registered, the certificate is valid.

The UI, git checkouts and stuff work as expected.

My compose.yaml reads:

    environment:
..
      - ONEDEV_PACKAGE_REGISTRY_ENABLED=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /root/onedev/data:/opt/onedev
      - /etc/timezone:/etc/timezone:ro

i.e. onedev uses the host's docker socket to run docker bulds inside itself.

I have a project that builds a Docker image. The project has package management enabled.

I have set up a service account with full permissions to this project. I have added a token to the service account with full permissions to this project. There is a job secret in the project that contains the contents of the token.

My onedev-buildspec.yml contains:

docker build -t plush/build-environment:latest .
    # Tag image to be available locally under /docker/ which is is the default prefix OneDev uses internally for Docker images (important!)
    docker tag plush/build-environment:latest my_server:6510/@project_path@:@build_number@
    # push the image
docker login my_server.online:6510 -u plush_service_acct -p "$PLUSH_SVC_ACCT_TOKEN"
    docker push my_server:6510/@project_path@:@build_number@

Build hangs when trying to login.

I connected to the host via ssh to login from there:

docker login https://my_server:6510 -u serviceaccount -p token
docker login my_server:6510 -u serviceaccount -p token
docker login my_server:6510 -u "" -p token
docker login my_server:6510 -u _token -p token
docker login my_server:6510 -u bearer -p token
docker login my_server:6510 -u serviceaccount -p logon password

All of them answer: Error response from daemon: login attempt to https://my_server:6510/v2/ failed with status: 401 Unauthorized

I am out of ideas.

Activities

Robin Shen commented 4 months ago

Please check server url in system settings of OneDev to make sure it is https://my_server:6510. If this still does not work, test docker login with root user account to make sure this is not a permission issue.
brixomatic commented 4 months ago

Password login on the host machine itself has been disabled in favor of public key authentication.

Server URL is set onnedev. Login with onedev setup user does not work (401) either.

brixomatic commented 4 months ago

:~# docker ps
CONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS         PORTS                                                   NAMES
f18477449343   1dev/server:latest              "/root/bin/entrypoin…"   2 days ago      Up 9 minutes   6610/tcp, 0.0.0.0:6581->6611/tcp, [::]:6581->6611/tcp   onedev
ccf59900bf3b   haproxy:3.0-alpine              "docker-entrypoint.s…"   2 days ago      Up 9 minutes   0.0.0.0:6510->6510/tcp, [::]:6510->6510/tcp             haproxy
ebf10f223c93   moby/buildkit:buildx-stable-1   "buildkitd --allow-i…"   12 months ago   Up 9 minutes                                                           buildx_buildkit_onedev0

Anything else I can do to look into the possible culprits? Does onedev log futile login attempts? Because I don't see anything in $ docker logs onedev that suggests anything like that.

Robin Shen commented 4 months ago

If this still does not work, test docker login with root user account to make sure this is not a permission issue.

I mean to run "docker login" with the administrator account of OneDev (not OS)
Robin Shen commented 4 months ago

Feel free to reopen if there is more info
Robin Shen changed state to 'Closed' 4 months ago
Previous Value Current Value
Open

Closed

Previous Value	Current Value
Open	Closed

brixomatic commented 4 months ago

If this still does not work, test docker login with root user account to make sure this is not a permission issue.

"I mean to run "docker login" with the administrator account of OneDev (not OS)"

I did that ("Login with onedev setup user does not work (401) either.") to no avail. The setup user is the admin.

What can be the possible culprits? I also tried relaxing the security measures on the haproxy top allow requests without user agent or curl, here's some from my haproxy.cfg:

global

global
    # intermediate configuration
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA--CHACHA20-POLY1305
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options prefer-client-ciphers no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3

    ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSSA-CHACHA20-POLY1305
    ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-server-options no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3

## -- max connections and stuff ---
frontend SSL_Termination
  mode http

  bind :6510 ssl crt /usr/local/etc/ssl/ssl_certificate_chain.pem alpn h2,http/1.1
  # bind *:6510
  http-request redirect scheme https code 301 unless { ssl_fc }
  # max-age is mandatory. 16000000 seconds is approximately 6 months. Use a low value during testing.
  http-response set-header Strict-Transport-Security "max-age=60; includeSubDomains; preload;"
  # A number of attacks use HTTP/1.0 as the protocol version because that’s the version supported by some bots.
  http-request deny if HTTP_1.0
  # curl, phantomjs and slimerjs are scriptable, headless browsers that could be used to automate an attack
#  http-request deny if { req.hdr(user-agent) -i -m sub curl phantomjs slimerjs }
  # an attacker who is using an automated tool might send requests that don’t contain a User-Agent header at all.
#  http-request deny unless { req.hdr(user-agent) -m found }

  acl hdr_connection_upgrade hdr(Connection)  -i upgrade
  acl hdr_upgrade_websocket  hdr(Upgrade)     -i websocket
  acl websocket_url path_beg -i /wicket/websocket

  use_backend onedev_websocket if hdr_connection_upgrade hdr_upgrade_websocket websocket_url
  default_backend onedev

backend onedev
  mode http
  option http-keep-alive
  option http-server-close

  option forwarded proto host by by_port for
  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }

  # Preserve critical headers exactly as sent by the Docker client
  http-request set-header Host %[req.hdr(Host)]
  http-request set-header Accept %[req.hdr(Accept)]
  http-request set-header Authorization %[req.hdr(Authorization)]

  server onedev_http_server onedev:6610 maxconn 2048

backend onedev_websocket
  mode http
  option forwarded proto host by by_port for
  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }

  http-request set-header Upgrade websocket
  http-request set-header Connection upgrade

brixomatic changed state to 'Open' 4 months ago
Previous Value Current Value
Closed

Open
Robin Shen commented 4 months ago

I doubt the permssion issue is reported by HA proxy. To verify, please by pass HAProxy and run docker login against OneDev directly, ie. docker login <onedev host>:6610. You will need to specify the server url in system settings of OenDev as http://<onedev host>:6610 as well. Also make sure to allow insecure docker registry: https://docs.onedev.io/tutorials/cicd/insecure-docker-registry
Robin Shen changed state to 'Closed' 4 months ago
Previous Value Current Value
Open

Closed
brixomatic commented 3 months ago

Exposing any service that needs authentication via http is a bad idea. You can't be serious! I will give up at this point.
Robin Shen commented 3 months ago

Exposing any service that needs authentication via http is a bad idea. You can't be serious! I will give up at this point.

This is just a test to narrow down the issue...
Login to comment

Previous Value	Current Value
Closed	Open

Previous Value	Current Value
Open	Closed

Type	Question
Priority	Normal
Assignee	Robin Shen
Labels	No labels

Issue Votes (0)

Watchers (2)

Reference

OD-2547