Harbor: Ability to sync robot accounts between replicated Harbor instances

Created on 15 Jan 2020  路  4Comments  路  Source: goharbor/harbor

We are using replication between two Harbor instances to provide geo-availability between data centers. We have a wide IP that points to both instances, but cannot use robot accounts because we do not have a mechanism to sync robot account tokens between instances. Wide IP prevents end user from knowing which site they are authenticating against so they will not be able to tell which token to use. Having the same token in both sites would be optimal.

areHA arerobot-account kinrequirement

Most helpful comment

I have the same scenario. And also replication of other projects options could be good like labels, tag retention, tag imutability, etc etc

If the robot account replication is not possible, maybe something to allow us to customize the token during the robot creation, thus we can use the same token for our other harbors servers.

All 4 comments

I have the same scenario. And also replication of other projects options could be good like labels, tag retention, tag imutability, etc etc

If the robot account replication is not possible, maybe something to allow us to customize the token during the robot creation, thus we can use the same token for our other harbors servers.

We are facing a similar issue. This request and @vzanlnx's comments is most likely what we are looking for.

I know exactly what you are talking about but the current proprietary token service in Harbor does not allow for that, a robot at its highest degree of freedom will be scoped to the instance. For this requirement, we need to expose the token auth service somehow. The project name will probably have to be the same as well maybe? @reasonerjt @wy65701436 please correct me if I'm wrong

@vzanlnx @fivezerosix your requirements already tracked as part of the following
https://github.com/goharbor/harbor/issues/8709
https://github.com/goharbor/harbor/issues/8207

a robot at its highest degree of freedom will be scoped to the instance. For this requirement, we need to expose the token auth service somehow. The project name will probably have to be the same as well maybe?

As far as I looked in how robo accounts work then token auth service won't be greatest problem - separate instances can be used as long as JWK keys match ( at least in theory). main problem is robo account token mapping to projects - as robo tokens (v2.1.1) contain project ID which could differ between harbor instances

Was this page helpful?
0 / 5 - 0 ratings