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.

[christian-korneck]

we fixed the problem mentioned above

@phin1x out of interest: how? did you need to modify code?

[phin1x]

@christian-korneck this is my patch file:

From c253bbeb2e46deaa61fa801f0583e130f685def0 Mon Sep 17 00:00:00 2001
From: Fabian Weber
Date: Fri, 23 Apr 2021 08:20:42 +0200
Subject: [PATCH] fixed-robot-account-project-creation

---
 src/server/v2.0/handler/project.go | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/server/v2.0/handler/project.go b/src/server/v2.0/handler/project.go
index 576da5a3d..3696388a9
--- a/src/server/v2.0/handler/project.go
+++ b/src/server/v2.0/handler/project.go
@@ -136,10 +136,10 @@ func (a *projectAPI) CreateProject(ctx context.Context, params operation.CreateP
        // set the owner as the system admin when the API being called by replication
        // it's a solution to workaround the restriction of project creation API:
        // only normal users can create projects
-       if secCtx.IsSolutionUser() {
+       ownerName := secCtx.GetUsername()
+       if secCtx.IsSolutionUser() || strings.HasPrefix(ownerName, config.RobotPrefix()){
                ownerID = 1
        } else {
-               ownerName := secCtx.GetUsername()
                user, err := a.userMgr.GetByName(ctx, ownerName)
                if err != nil {
                        return a.SendError(ctx, err)
-- 
2.25.1

But we found more problems, with a robot account you cannot delete, get, list, a.s.o. projects.
this is caused by a wrong rbac subject. the rbac subject harbor passes to casbin (the rbac engine) is something like "/project/", but the allowed project subjects for the robot accounts is "/project//project", so harbor will never allow the robot account to administer projects.

// edit
The root cause is this line: https://github.com/goharbor/harbor/blob/master/src/server/middleware/security/robot2.go#L66

the scope gets combined with the resource. this works vor every resource execept for projects. for projects the resource should not be appended.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lindhe]

Please keep this open. It's pretty frustrating having to create the robot accounts via API instead of GUI.

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.