Allow pull from repository only for authenticated users and robot accounts with long lived credentials

[strigazi]

Is your feature request related to a problem? Please describe.
In a harbor deployment, administrators may want to allow pull access to all authenticated users for a repository, usually in environments with OIDC or LDAP that the set of users is not known beforehand.

A specific use-case is proxy-cache repositories open to the internet that can potentially create copyright or licencing issues with public registries. For example, dockerhub and other registries have rate limits and if a harbor deployment is open to the internet with a public proxy-cache repo, everyone can bypass protections configured in the public registry.

Another use case is for a private repository in a public harbor registry, allow access to everyone in an organization. Our organization has ~60,000 members.

Possible solutions:
One solution that has limitations is, create a private repository and give a catch all group the Limited Guest role. The limitation is that users can not create robot accounts for that repository and their personal OIDC token needs refresh which is a problem for automation CI/CD, access from kubernetes etc.

Another solution is an L7 policy in the LoadBalancers/Ingress but this requires knowledge for all network domain beforehand.

Describe the solution you'd like
Two items must be addressed.

a. allow all authenticated users with a new option. (there is the anonymous role https://goharbor.io/docs/main/administration/managing-users/, we can say with an option, reject anonymous)
This can be worked around with a catch all users approach, but in my opinion it's a hack.

b. long lived credentials
Allow users to create user robot accounts or personal tokens with permisssions granularity. For example gitlab let users create token with specific permissions. Dockerhub allows the creation of personal token but without any granularity on permissions.

I'm happy to dig more into the design, but let's discuss the need for this first.

[Vad1mo]

this is related to the community proposal #242 - Multiple Visibility Levels and enforcement Levels for Projects

[strigazi]

this is related to the community proposal #242 - Multiple Visibility Levels and enforcement Levels for Projects

If we plan to have long lived tokens as part of goharbor/community#242 we can close this issue as it's the same use case.

[reasonerjt]

@strigazi Sorry I joined the community meeting a bit late ...

But I believe you are asking for an access requirement that equals to "public but requires authenticated"? If the answer is yes, what do you think if the setting is added at the project level?

[strigazi]

@strigazi Sorry I joined the community meeting a bit late ...

But I believe you are asking for an access requirement that equals to "public but requires authenticated"? If the answer is yes, what do you think if the setting is added at the project level?

yes, "public but requires authenticated" is what we would like.

Adding a setting at the project level would work and I think this is addressed in the proposal linked by @Vad1mo .

The only missing bit is adding support for robot accounts. @Vad1mo will update the proposal.
IMO, what would work is allowing user even with the Limited Guest role create their own project scoped robot accounts for pull only without being able to see/edit other users robot accounts. This is a requirement for automation (CI/CD, kubernetes nodes etc). user tokens work fine but for humans since these token expire.

[reasonerjt]

Thanks @strigazi
But I have a question regarding the requirement about robot account:

IMO, what would work is allowing user even with the Limited Guest role create their own project scoped robot accounts for pull only without being able to see/edit other users robot accounts. This is a requirement for automation (CI/CD, kubernetes nodes etc). user tokens work fine but for humans since these token expire.

I believe this is generally supported as long as the user is project admin right? We may let the project admin create a robot account with very limited permission. Do you mean in your scenario you cannot let project-admin do this?

[strigazi]

I believe this is generally supported as long as the user is project admin right? We may let the project admin create a robot account with very limited permission. Do you mean in your scenario you cannot let project-admin do this?

@reasonerjt Project admins can indeed create robot accounts. However, this solution is suboptimal, in our organization we have thousands of users, so creating a robot account manually (or deleting/rotating credentials) every time a user needs one, does not scale. Additionally, we would have to devise a way to distribute the robot account credentials we create.