Robot Account with Advanced Permissions

[Vad1mo]

Now that Harbor 2.2 has support for more sophisticated robot accounts types with already 10 permission out of the box.

It would be very beneficial to have an additional permission sets similar to normal users:

• System Admin
• Project Admin
• Maintainer
• Developer
• Guest
• Limited Guest

Why
The primary reason behind the System Admin Robot account is that in an OIDC environment it is often impossible to use the REST api a normal user. See related issues #8033, #13093, #13683, #10597 #14236

Expected
System Admin with 3 permissions Read/Create/Delete

API LEVEL
On the REST API level

• READ should match GET and CREATE
• CREAE should match PUT/PATCH/POST
• DELETE should match DELETE

[wy65701436]

hi @Vad1mo, do you need the robot to have the system access? Can you just clarify the resources?

[phin1x]

Robot Accounts with admin permissions would be very useful. As Vad1mo mentioned you cannot use the rest api programaticly because you need a oidc token. You can get a token with a application id and application secret (azure ad), but the token is useles because you need to onboard a user first and you cannot onboard a application. So we had to create the required database entries manually:

DO $$
DECLARE
        -- set application subject
        --
        -- howto get subject:
        -- url: https://login.microsoftonline.com/a8cea0e8-2d5f-4772-9440-2820c0ef44b9/oauth2/v2.0/token
        -- post body params:
        -- grant_type: client_credentials
        -- client_id: <broker application id>
        -- client_secret: <broker application secret>
        -- scope: <harbor app id>/.default
        --
        -- jwt in z.B. jwt.io decoden und subject entnehmen
        oidc_subject varchar := '';

        -- set issuer endpoint from web ui
        oidc_issuer varchar := '';

        userid harbor_user.user_id%TYPE;
BEGIN

INSERT INTO harbor_user (username, password, realname, sysadmin_flag) VALUES ('service-broker', '', 'Service Broker', true) RETURNING user_id INTO userid;

INSERT INTO oidc_user (user_id, secret, subiss) VALUES (userid, '', concat(oidc_subject, oidc_issuer));

END $$

This works well but it's very hacky and require manuall actions in the database. If we have a robot account with admin permissions, we could avoid all this.

[Vad1mo]

@wy65701436, thanks for asking, We would like to use tools like https://github.com/moolen/harbor-sync, https://github.com/christian-korneck/update-container-description-action and also create robot accounts, projects via the API.

Basically, the complete REST API isn't usable if you are using OIDC. And OIDC user need to find hacks in their IDPs and Harbor to make thing work. With some IDPs it's not possible at all.

[christian-korneck]

+1 for what @Vad1mo wrote. The core problem is that it's not possible to use the Harbor REST API with OIDC users (at least not without getting a separate token from the oidc provider, for which there's no canonical way). I've looked at two commercial hosted Harbor providers. Both don't offer the Harbor REST API to their users because of this limitation. This basically prevents any use case that requires API access. (I'm the maintainer of docker-pushrm and would like to make my tool accessible to Harbor users that log in with oidc).

I'd propose this solution: Allow to assign arbitrary api permission to robot users.

[wy65701436]

@Vad1mo @phin1x If you want to create a robot account with access to system resources, just use the following body as an example(robot with create project permission). Robot access to system resources is not exposed in UI, but is available in the new version (v2.2+) via the API.

POST https://{harbor_ip}/api/v2.0/robots
{
   "name":"test",
   "duration":30,
   "description":"test",
   "disable":false,
   "level":"system",
   "permissions":[
      {
         "kind":"system",
         "namespace":"/",
         "access":[
            {
               "resource":"project",
               "action":"create"
            }
         ]
      }
   ]
}

And for the system resource defination, go to https://github.com/goharbor/harbor/blob/main/src/common/rbac/const.go to get details.

[Olli73773]

@wy65701436 I create a robot account with the admin account and the json above on Harbor Version v2.2.1-b0d63082
And got

{
  "creation_time": "2021-04-13T09:45:02.491Z",
  "expires_at": 1620899102,
  "id": 4,
  "name": "robot$test",
  "secret": "someSecretString"
}

Now I send a HTTP Post request (with the created robot account)

http://mytest:9080/api/v2.0/projects
{
  "project_name": "autotest",
  "count_limit": 0,
  "storage_limit": 0,
  "public": true
}

But I just get an error:

{
  "errors": [{
    "code": "NOT_FOUND",
    "message": "user robot$test not found"
  }]
}

[phin1x]

We run into the same issue.

The problematic line is: https://github.com/goharbor/harbor/blob/v2.2.1/src/server/v2.0/handler/project.go#L143

When a project is created, harbor tries to get the ID of the owner. If the user is not a solution user (I don't know what that means), it tries to get the ID of the current authorized user. But this fails because a robot account is not a regular user and the api returns "user < robot account > not found".

@wy65701436 a quick fix could be that a robot account is treated as kind of solution user or check if the current authorized user starts with the robot prefix.

[phin1x]

We run into the next problem:

we fixed the problem mentioned above and successfully created a repository. But i cannot do any actions (for example getProject) on the project with my robot account. Harbor always responds with 403 forbidden. I think this is because the robot account is not a actual member of the project.

I created the robot account with the following permissions:

{
					Namespace: "/",
					Kind:      "system",
					Access: []*models.Access{
						{
							Action:   "*",
							Resource: "robot",
						},
						{
							Action:   "*",
							Resource: "member",
						},
						{
							Action:   "*",
							Resource: "project",
						},
					},
				},

[phin1x]

as we digged into the issue we found that you cannot mix system and project level permissions in a robot account. if you want to create a project and modify the members you need two robot accounts. one with system level permissions to create a project and one with project level permissions (namespace is '*') to modify the project.