Harbor: Registry: Token Issuer is hardcoded

[CrystalMethod]

Expected behavior and actual behavior:
The use of an alternative token provider should be fully supported.

Steps to reproduce the problem:
Configure the Harbor Registry to use a different token provider - for example Gitlab Registry. See config below. Docker CLI docker login registry.***.com should work but e.g. docker pull registry.***.com/library/alpine:latest and Harbor UI will not work, as internal implementations still seem to use harbor-token-issuer

Versions:
Please specify the versions of following systems.

• harbor version: v1.7.0-3b3311b4
• docker engine version: 17.05.0-ce
• docker-compose version: 1.14.0

Additional context:

https://github.com/goharbor/harbor/blob/2920ec5f9b11538ff0c377898824c6e32aa5176e/src/core/service/token/authutils.go#L36

• Harbor config files:

auth:
  token:
    issuer: gitlab-issuer
    realm: https://gitlab.***.com/jwt/auth
    rootcertbundle: /certs/registry.crt
    service: container_registry

• Log files:

nginx | 172.32.0.15 - "GET /api/labels?scope=g HTTP/1.1" 200 2 "https://registry.***.com/harbor/projects/1/repositories/library%2Falpine" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" 0.002 0.002 .
registry | time="2018-12-31T20:18:55.595524191Z" level=info msg="token from untrusted issuer: \"harbor-token-issuer\""
registry | time="2018-12-31T20:18:55.595589321Z" level=warning msg="error authorizing context: invalid token" go.version=go1.7.3 http.request.host="registry:5000" http.request.id=e047cb99-04b8-463e-84da-3964b6fe972c http.request.method=GET http.request.remoteaddr="172.18.0.5:47242" http.request.uri="/v2/library/alpine/tags/list" http.request.useragent=harbor-registry-client instance.id=54731945-74fe-42ea-9c0e-0b99bef16fa7 service=registry vars.name="library/alpine" version=v2.6.2
registry | 172.18.0.5 - - [31/Dec/2018:20:18:55 +0000] "GET /v2/library/alpine/tags/list HTTP/1.1" 401 157 "" "harbor-registry-client"
harbor-core | 2018-12-31T20:18:55Z [ERROR] [base.go:94]: failed to get tag of library/alpine: 401 {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"library/alpine","Action":"pull"}]}]}

[steven-zou]

@CrystalMethod
Thanks for reaching us and throwing out the problem. We'll take a look and see if we can find a good way to improve it.

@ywk253100
PLEASE take a look at this issue. Thanks!

[CrystalMethod]

I can confirm that the hard-coded token issuer in

https://github.com/goharbor/harbor/blob/master/src/core/service/token/authutils.go#L36

is the root cause. I fixed that locally and can now run docker login and docker push to the registry.

But there is another hard-coded identifier harbor-registry:

https://github.com/goharbor/harbor/blob/master/src/common/utils/registry/auth/util.go#L30
https://github.com/goharbor/harbor/blob/master/src/core/service/token/creator.go#L40

Jan  2 10:28:39 192.168.240.1 registry[1359]: time="2019-01-02T10:28:39.634458461Z" level=info msg="token intended for another audience: \"harbor-registry\""
Jan  2 10:28:39 192.168.240.1 registry[1359]: time="2019-01-02T10:28:39.634570676Z" level=warning msg="error authorizing context: invalid token" go.version=go1.7.3 http.request.host="registry:5000" http.request.id=b7080710-8fa9-48c4-b12f-443da1e2a34e http.request.method=GET http.request.remoteaddr="192.168.240.8:44174" http.request.uri="/v2/lars.martin/***/tags/list" http.request.useragent=harbor-registry-client instance.id=ef3d8ace-41ed-4986-ba8c-bee09d2309ae service=registry vars.name="lars.martin/***" version=v2.6.2

[CrystalMethod]

Finally I was able to integrate Gitlab Token Auth in Harbor Registry by simply hardcoding the Gitlab settings ("issuer" and "service" like mentioned above). Which of course is to be only seen as a PoC. And after a myriad of "trial and errors" I found the correct settings for the certificates necessary to communicate between Gitlab and Harbor.

[vegardx]

This would be amazing, as Gitlab Registry leaves much to be desired.

[CrystalMethod]

This would be amazing, as Gitlab Registry leaves much to be desired.

https://github.com/goharbor/harbor/issues/694#issuecomment-451406433

However, Gitlab offers much more flexibility through its concept of groups and sub-groups. For example, to push my built images into Harbor, I have to create a group "goharbor" in Gitlab and create a project with the same name per Harbor image (core, jobservice, migration, clair, portal,..). But I only have exactly one forked source code repository with a single Makefile for Harbor. Maybe you can solve this in the future using the token scope.

Harbor images pushed to harbor
Gitlab Project per Harbor image

[vegardx]

Yeah - we'd lose out on some of the access control, which is also less than ideal. But the issue is always integrating with a CI. Anyone would be able to run away with the credentials used for an external registry if they are put as variables in gitlab. It's a lose-lose situation currently.

[CrystalMethod]

The naming scheme of some images is also not ideal I think, i.e. "*-photon" images where "photon" is more some kind of flavour. IMO it would be much better to move the "photon" flavour to the version tag "goharbor/nginx:v1.7.0-photon"

[flixpae]

Hey :) i am also very interested in this.

i can't figure out where to put those config steps with harbor v2.0+.

We had the setup working with harbor version 1.10
we kinda went with the steps described in #4455

is there a way to do this configuration of an external JWT token-realm without patching the hardcoded token-issuer ?

as #12351 mentions there is some work on reworking jwt tokens ?

[reasonerjt]

Unfortunately #12351 will not make the issuer configurable.

[timrizzi]

Hey - GitLab PM here. I was wondering if there is anything I can do to help move this forward. We'd really like to provide a way for our shared customers to use both registries.

[flixpae]

@timrizzi
we wrote a api adapter that would create harbor projects acording to projects as they are setup in Gitlab.
The Api adapter would be a service receiving "gitlab system hooks" and acting on the information in the hook to create harbor projects and set up permissions for humans (and create a robot$account in harbor that is able to use the registry from gitlab side)

But realised halfway done that harbor lacks the support for setting group permissions... so the integration would be somewhat ugly as of now.

Since there is no place in harbor to project the gitlab permissions for "Groups" onto.
permitting users the same way on harbor as they are in gitlab is not possible. (at least the ux is not good as harbor project names get unreadable since only addressable via id)

Also from what i saw, since harbor 2.x the JWT thing is not used for the auth to the harbor registry anymore. So simple change of the hardcoded issuer as in harbor 1.1x was, at least from the limited time spent, not working :/.