添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

our ci-cd platform build image and push to harbor, every user has own project 。when push image,our db store md5 password,we could not used for docker login。

what I can do for this case ?

@yugongpeng are you saying you want a token to push image only but not do anything on the web UI?

It's a matter of fine grained access control, per my understanding you want a token that can push image but not for calling any API, so you are essentially asking for a role that can push image only, but unfortunately here's no such role in Harbor.

We would be interested in the concept of push tokens as well. There's a few open issues for "mixed mode" authentication already (See #698 and #1323 ) but I like this solution better. I'd imagine being able to create push tokens at the project and repo level. This would be extremely useful for CI where you want people to only be able to push to repos they own from CI (rather than using a shared service account like the builtin admin or one from LDAP).

@nlowe Thanks for the input I like the idea to create tokens on project level, so I imagine the flow will be:

Project Admin to create the token, then update config.json with this token and the docker host and do pull/push with this token until it's revoked by Project Admin?
So this token will be used to pull/push only and nothing else.

Sort of, yeah. Although I think it would be easier for most CI systems if we can get UN/PW pair that we can docker login from (for example, using with the Jenkins withDockerRegistry step) instead of having to update the config.json on the host.

Yes, I see this as push/pull only.

Please keep this open.

Ideally the authentication should work like GitLab's personal access token https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
And deploy tokens on a project level. https://docs.gitlab.com/ee/user/project/deploy_tokens/#creating-a-deploy-token

  • This would allow users to not share their personal authentication that can come from LDAP providers ad might change.
  • It would also allow a projects workflow to continue and not be contingent on a personal user account to pull images from if the project is not public.
  • @paulbadcock Users of Gitlab can use Gitlab Token Auth with Harbor. So you don't need to define access tokens. In .gitlab-ci.yml you use something like docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com where registry.example.com is you Harbor installation. This works like a charm and doesn't interfer with your LDAP settings.

    Access Token / Robot Account has the charm that you can push different images from one Gitlab project into the registry. Otherwise, Gitlab assumes that one source project corresponds to exactly one image. So, yes, I think support for both use cases make sense and should co-exist:

  • Access Token / Robot Account
  • Gitlab as Registry Token Auth
  •