Token specific to project

[jakirpatel]

Is your feature request related to a problem? Please describe.
Yes. We do have the LDAP in place. The current relationship between harbor and teams is differentiated through projects in the harbor.So one team is having N number of mailing lists and we have assigned the one project --> one team.

Our problem:

Teams don't have common accounts. So either we should be dependent on username/password in LDAP of some member which is not a feasible way to do automation.

Describe the solution you'd like
There is the concept called as bot-accounts. In my opinion for reliable CI/CD automation, there should be token specific to the project. The lifecycle of the project can be managed by the Harbor admin and project admin.

Also, it will be really helpful if the token can be assigned with the current role like admin, developer, and guest.

Any thoughts about this?

[reasonerjt]

For automation or CI integration, do you only want the bot-accounts do push/pull, or any other manage API calls.

We did have some feedback requiring the bot account, but it's mainly focusing on push/pull actions, if the token is introduced, but it can only do push and pull with that token, will it satisfy your scenario?

[jakirpatel]

@reasonerjt

Thanks for your reply. We may require the other API calls too. For example, let's look our approach of Automation specific to harbor (Prod):

1. Create the project (for the first time)
2. Create the LDAP group.
3. Assign LDAP group to the project.
4. Build the docker image
5. Push to harbor
6. Add the label to the image (example: Prod)
7. Scan the image (Optional)

Right now we are doing this with the Harbor admin through our CI. But it may be a potential risk if the someone exposes the token.

We want the teams will have more authority to configure their own projects. Also, we do have the worker in place which is doing the deletion of the images with some specific rules.

Please share your opinions.

[jakirpatel]

For automation or CI integration, do you only want the bot-accounts do push/pull, or any other manage API calls.

We did have some feedback requiring the bot account, but it's mainly focusing on push/pull actions, if the token is introduced, but it can only do push and pull with that token, will it satisfy your scenario?

But even I think this approach can also work. For push and pull at least..

[reasonerjt]

@jakirpatel

Thanks for your reply. We may require the other API calls too. For example, let's look our approach of Automation specific to harbor (Prod):

1. Create the project (for the first time)
2. Create the LDAP group.
3. Assign LDAP group to the project.
4. Build the docker image
5. Push to harbor
6. Add the label to the image (example: Prod)
7. Scan the image (Optional)

Right now we are doing this with the Harbor admin through our CI. But it may be a potential risk if the someone exposes the token.

We want the teams will have more authority to configure their own projects. Also, we do have the worker in place which is doing the deletion of the images with some specific rules.

Please share your opinions.

This ask is essentially customisable fine-grained permission control over API, this is a valid scenario, but requires heavy refactory that may not happen very soon.
Provide bot-account for push/pull seems a lower hangin fruit though.

[jakirpatel]

@reasonerjt

Even I think in any case is it possible to have the combination of DB account and LDAP Account ?

Like if I can create the DB account and if we can set the relationship of the DB account in postgres itself.

What you think about this ? I am curious the admin account itself is DB Account.

[reasonerjt]

I understand you want to avoid setting credentials of LDAP in your automation scripts/tools.
However, comparing to bot-account, it's another story to provide combination of DB + LDAP user. Esp. if we think about the migration of current users.
But I think we'll consolidate the requirements when providing a solution for bot-accounts or integration-account, etc.

[jakirpatel]

@reasonerjt

The major security risk we are facing now that in Kubernetes we are providing the secret which is created by the admin username and password. Which is ultimately not a good practice.

Talking about the token I am okay if I 'll get the token for only push or pull to a specific project. Will it be possible with respect to the project?

[ghost]

I think this can be done. Is this something you're willing to contribute @jakirpatel ? If not we'll work on adding it to the roadmap.

[jakirpatel]

@clouderati

Happy to contribute if possible... For time being could you please add to the roadmap? I'll pick it ASAP when I get the time for it...

[reasonerjt]

The robot account will be part of 1.8.0:
#6565