Harbor: Support "global" robot accounts

[lhotrifork]

Is your feature request related to a problem? Please describe.

We have a multi-tenant setup where different suppliers have their own project in harbor, where they push their docker images.

However some of the images are deployed into the same kubernetes namespace. We would like to have one pull secret per namespace that allows access to all relevant projects in harbor.

We used to be able to define robot accounts that spanned multiple projects:
(e.g. before https://github.com/goharbor/harbor/security/advisories/GHSA-x2r2-w9c7-h624 )

{
    "name": "robotAccount",
    "access": [
        {
            "resource": "/project/management/repository",
            "action": "pull"
        },
        {
            "resource": "/project/management/helm-chart",
            "action": "read"
        },
        {
            "resource": "/project/vendor1/repository",
            "action": "pull"
        },
        {
            "resource": "/project/common/helm-chart",
            "action": "read"
        }
    ]
}

Describe the solution you'd like
We would like to be able to create "global" robot accounts that can pull both images and helm charts from multiple projects.

[smekkley]

I agree that this feature is necessary. Also remove robot$ prefix for this. It's more like supporting ldap/oid and local account at the same time with priority. And then you can assign the user to project. Every other system account implementation I've come across worked like that.

[smekkley]

Actually this is duplicate of #7867.
There are issues like #7812, #8248. These are all because of an awkward implementation of a system account aka robot account in harbor.

[xaleeks]

Hi, we understand your pain point and are having some internal discussions around this but the feeling is that in most tenancy models, robot accts would not be using different projects. When we add the idea of namespace or organization as a level above projects, this would make more sense. For now, you'd have to create multiple robot to accomplish this.

[smekkley]

I just wanted to point the weirdness around it. Even with normal system account, you just create multiple accounts depending on the need. I'm rather fond of the idea of deprecating robot account.

[xaleeks]

I'm not sure I see the weirdness around it but we are trying to strike a balance btw minimizing robot acct creation and respecting boundaries. closing this for now.

[smekkley]

Weird might've been 'weird' expression. What I meant was robot account won't be necessary as soon as we support local accounts and ldap/oid accounts at the same time with priority like many other applications do. We already have role based authorization, thus there was no need to create a dedicated account type with dedicated authorization strategy like robot account.

[Hokwang]

I need this feature.

[smekkley]

I'm not sure why this issue was closed. All other issues I mentioned in my previous comment can be solved by supporting this so-called global robot accounts, which probably should mean supporting existing local authentication strategy on top of another authentication strategy. People using local accounts aren't having these issues.

Actually, #8272 says the same thing but it was closed.

[xaleeks]

@smekkley Hi smekkley, didn't mean to dismiss this, closed it because there should be at least 1 other issue on this and we understand the requirement. Another reason is this issue essentailly exposes a vulnerability that we fixed on the latest release but not on all the previous releases so wanted to limit visibility in case someone is doing something malicious. But the idea around global robot accounts is already in our backlog but we need to go deeper on namespace management before we can support this directly. If you are not aware yet, 1.11 is going to support OCI registry so we have quite a few things to plan for. You can also ping me [email protected] to discuss some specifics.