Harbor: Make robot serapator configurable

[ruiztulio]

First at all, thanks for releasing this project, so far I'm very happy with the features it have.

Is your feature request related to a problem? Please describe.
The robot accounts are created with $ char which have to be scaped most of the time. I you think about it most of the time the robot accounts are used to login from the console (via a CI pipeline, to deploy a service, etc), the credentials are shared via env vars thus they have to be scaped this implies changing the current scripts to deal with that, in my particular case having "robot$somename" doesn't work because is used by another script

Describe the solution you'd like
Be able to confugure or change the separator.

Describe the main design/architecture of your solution
Can be a variable in the compose file where I can define it when I start harbor, probably a person won't change it any more (ideally it would be a field in the config section)

Additional context
Initially proposed here

[reasonerjt]

Making it configurable will cause un-expected issue such as colission.

I don't think escaping a $ in script is a big hassle.

[ruiztulio]

@reasonerjt I won't call it "big hassle", but I had to create a normal user to avoid the issue (I'd just it is annoying). Consider that in my case I have to make this change at least 30 times (one per group).

It'd be nice to configure it at the install, only once and cannot be changed later so is easier to avoid or at least reduce the risk of colissions as you mention.

[containerpope]

In Gitlab CI this can be a very big pain. Also logging in with bash is annoying. It would be a very good idea to make this configurable initially.

[nseigneur]

+1 on this issue.

We use Concourse CI and the docker resource will interpret the "$" character. As we enabled OIDC, we can't create a normal user which leaves us with use the Admin account which is unacceptable as we move to production.

I have seen many system use the "+" character for robot account and this doesn't cause issue in bash and seems to be a better design.

[tstrohmeier]

+1 for this issue

We would also prefer a different character or to make it configurable.

[jotokra]

Making it configurable will cause un-expected issue such as colission.

I don't think escaping a $ in script is a big hassle.

Well.. It truely can be a very big hassle if you inject scripts into others and youre trying to debug an issue with 401 unauthorized at the end.

[qvistgaard]

+1
I came here to file this as an issue

[esantoro]

+1

[Kryan90]

+1 trying to use this with jenkins / groovy is broken.

[joshuaswickirl]

Just wrap the name in single quotes.

Ex. 'robo$name'

[tstrohmeier]

@joshuaswickirl Basically true, but please read what @jotokra , @mkjoerg, @ruiztulio and @nseigneur pointed out.

@reasonerjt Is it possible to increase the priority, since we have quite a lot of upvotes for this ticket here.

[esantoro]

It would be nice to have this fixed for release 2.0

[joshuaswickirl]

@tstrohmeier I did read the comments, maybe I'm just missing something. Can you provide an example where single quotes doesn't work?

[knackaron]

@joshuaswickirl Single quotes don't work using GitLab runners because variables are expanded in multiple stages, and there's no way to escape the $all the way through. See https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html

The workaround we use now is in our build scripts. We define the robot account with a + instead of $, then replace it in the script:

REGISTRY_USERNAME="${REGISTRY_USERNAME/+/$}"

It would be nice to not require this hack and have the username we define in the CI/CD variables in the GitLab UI match what is actually in Harbor.

[mefcorvi]

@knackaron It's possible to escape $ in GitLab with another $, i.e. robot$$name. However I must admit that using $ in the robot account's name creates a lot of inconveniences because of common usage of $ for variable substitutions.

[mikemowgli]

@knackaron @mefcorvi , we discovered that we don't need to escape or double the '$' character in gitlab if we perform temporary variable definition.
Example: let's say your GitLab CI variable is: REGISTRY_USERNAME: robot$name. Then in your .gitlab-ci.yml:

build-job:
  variables:
    REGISTRY_USERNAME_FOO: $REGISTRY_USERNAME
  script:
    - echo $REGISTRY_PASSWORD | docker login -u $REGISTRY_USERNAME_FOO $REGISTRY_SERVER --password-stdin

I prefer this than messing with the value of the variable.

[lowerzero]

This is very annoying when use it in scripts. Why don't just make in congurable?

[Jason-2020]

@mikemowgli Thanks for the workaround!

[georgesvachulay]

+1, why do we have to explain this even

[bryan-taylor]

Administrators in a harbor deployment environment should control the username fully, so they can follow the naming conventions in use in their organization. Software designers should not impose weird constraints on identity fields like this.

The stated goal (to make it obvious what type of user account something is) violates good data normalization design principals. Each data element should have one purpose and clearly and explicitly serve that purpose. The username shouldn't simultaneously define the type of user and who the user is. A better alternative would use a type attribute whose values are {user, robot} and some icons to make this visually distinctive in the UI. In code form user.type == robot is much easier to comprehend than user.name.starts_with("robot$").

[tdensmore-novant]

This whole conversation is really disappointing. The community is asking for a fix to something that was an arbitrarily bad decision in the first place. Why would maintainers spend ANY energy trying to defend these poor decisions, rather than address the actual issue?

[mikemowgli]

@reasonerjt can this be added in the backlog?

[ChristianCiach]

I took me half a day to finally find out why our gitlab pipeline failed with "401" errors.

Yes, of course it is (more or less) easy to escape the dollar - that is, IF you know what you're looking for! For example, I had no idea that gitlab uses a double-dollar to escape the dollar sign. Many people have lost a lot of time because of this.

[BeGj]

Thanks to @mikemowgli and @mefcorvi for the workaround. I'm hoping the $ will be removed in future versions of GoHarbor. Terrible design decision. We wasted perhaps 2-3 hours on this before finding this issue.

[xaleeks]

this char is going to be configurable by the Harbor admin in the upcoming v2.2. I'm closing this because we've been tracking progress on https://github.com/goharbor/harbor/issues/9553. Sorry to make you guys subscribe to a different thread!