You signed in with another tab or window.
Reload
to refresh your session.
You signed out in another tab or window.
Reload
to refresh your session.
You switched accounts on another tab or window.
Reload
to refresh your session.
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