Robot account possible permissions are too limited

[slushysnowman]

We are currently on Harbor 2.9.1 - I've been experimenting with Harbor 2.10.0 and ran into some blockers due to the way we currently use Harbor.

We provide Harbor as a service internally within our organisation - and it is heavily integrated into our environment.

The integrations to harbor that we provide are often managed separately from Harbor itself (although by the same team). With this in mind, we have been using system robot accounts to setup those integrations.

With the permission changes for robot accounts introduced in 2.10.0, as far as I can see, the permission set that system robot accounts can get has been limited, and as far as our use-case goes at least, it's too limited, and I think that may apply to others as well.

Use-case 1:
In Harbor 2.9.1 (what we are currently running), we could create a robot account (using TF provider) with permissions configured as so:

resource "harbor_robot_account" "integration" {
  name        = "system-registry-integration"
  description = "Robot account with rights to create robot accounts"
  level       = "system"
  secret      = <generated-password-here>
  permissions {
    access {
      action   = "*"
      resource = "robot"
    }
    access {
      action   = "list"
      resource = "project"
    }
    kind      = "system"
    namespace = "/"
  }
}

When I try to create this resource in Harbor 2.10.0 I get the following error:

│ Error: [ERROR] unexpected status code got: 400 expected: 201 
│  {"errors":[{"code":"BAD_REQUEST","message":"bad request permission: robot:*"}]}
│ 
│ 
│   with harbor_robot_account.integration,
│   on caps-integration-credentials.tf line 15, in resource "harbor_robot_account" "integration":
│   15: resource "harbor_robot_account" "integration" {

Our use case for a system robot account that can create robot accounts is to use this robot account to create granularly-scoped robot accounts to use for integrations with our CICD tooling, and our Kubernetes clusters, to setup default service connections and pull secrets on behalf of our users. With the ability to use a system robot account to do this removed, the only course of action left to me is to use the Harbor admin credentials, which seems like a step backwards for me.

Obviously this specific use-case has some downsides, as there is an escalation pathway possible, whereby a robot account could be created which has higher permissions than the robot account that created it, but in my mind that should be up to the Harbor admins to decide if they deem that acceptable, not the Harbor product itself. I think that something like a warning about this in the UI would be sufficient, while still enabling 'advanced' use-cases.

In addition, the use of * for actions / resources is now basically impossible from my testing, as for most permissions you cannot use *, so instead of * producing a list of all the actions / resources possible, it just breaks

[wy65701436]

We must adhere to the definition of a robot account and its designated capabilities. As per our understanding, creating additional users or robots should not be within the scope of its intended functionality. In other words, any Harbor user seeking a system robot should request one from the system administrator rather than creating one arbitrarily at the system level.

Furthermore, the absence of a tracking mechanism for identifying the creator of a robot and assigning appropriate permissions poses a security risk to the system. It could result in numerous robots having admin permissions without any oversight or accountability.

[slushysnowman]

We have some pretty hefty default integrations between Harbor and the rest of our IT landscape

• we automatically create Azure DevOps Service Connections for 100+ development teams, to allow them to push to Harbor without them needing to do anything
• we automatically create Kubernetes pull secrets for all our teams on 40+ AKS clusters
  ^ all of that uses robot accounts

In addition, we're now moving our Harbor setup to Azure, and we'll be running 2 Harbor instances - one for private access (basically an entire instance of proxy-cache projects) and one for public access (which the private instance will use as source for images) - all of which will also be using robot accounts to achieve the design 😄

For all of these things we also do automatic rotation of robot credentials to reduce risk of leak etc

Throwing the Harbor admin credentials around to achieve all of that seems like a very bad idea to me, and leaves the admin creds at much greater risk of compromise, which can have a far worse effect than if a robot account is misused - and it's a lot easier for me to retract/rotate robot credentials than the admin credentials.

We must adhere to the definition of a robot account and its designated capabilities. As per our understanding, creating additional users or robots should not be within the scope of its intended functionality. In other words, any Harbor user seeking a system robot should request one from the system administrator rather than creating one arbitrarily at the system level.

I understand, but the definition of a robot account has changed, and hence it seems to me that it can change again.

The path you define for robot accounts does not scale - in large enterprises aiming for standardised approaches, having all users request a system robot account manually is unscalable. The approach we take instead is to provide them with the robot accounts they need by default.

We maintain our Harbor instance(s) ourselves, and are capable of determining for ourselves what we deem to be acceptable risk. Having a hard block on the product level limits possibilities tremendously.

Furthermore, the absence of a tracking mechanism for identifying the creator of a robot and assigning appropriate permissions poses a security risk to the system. It could result in numerous robots having admin permissions without any oversight or accountability.

This is correct, but to me this is more of an argument for a properly comprehensive audit logging system than for restricting robot accounts and thereby limiting automation possibilities.

Overall, I am OK with limiting robot account permissions - I don't want a robot account modifying Harbor core config for example - I don't want a robot account modifying our OIDC login setup.

But in my mind, removing this permission is a wrong choice.

Unfortunately I missed the last community meeting, but I'll ensure I join the next one to discuss this.

[gaglimax]

In my team, we have a different use case but the issue is quite similar.
We have 2 Harbor instances, one on Azure and one on AWS. Our need is to synchronize artifacts and robot accounts from Azure to AWS. To synchronize artifacts, we use a replication rule.
To synchronize robot accounts, we need a user that can list robot accounts on Harbor Azure. To perform RBAC, we don't want to use the admin user to do that.

Today, on Harbor, it is not possible to create local system users when OIDC is configured, and even if it was possible, there's no such thing as RBAC with system users. So we created a robot account with list permission over robots, but since the last version, that kind of robot account is not allowed anymore.

[pmeyer34]

Hello, similar issue in my team :
we want to create a project for each team, with their own robot to push/pull artifacts.
we have a pipeline to create all objects with API, except for robot account since we don't want to use the admin account.

[reasonerjt]

@slushysnowman

Thanks for reporting this issue

Obviously this specific use-case has some downsides, as there is an escalation pathway possible ...

Correct, that's the reason why we decided to disable robot accounts managing other robot accounts

Our use case for a system robot account that can create robot accounts is to use this robot account to create granularly-scoped robot accounts to use for integrations with our CICD tooling, and our Kubernetes clusters, to setup default service connections and pull secrets on behalf of our users. With the ability to use a system robot account to do this removed, the only course of action left to me is to use the Harbor admin credentials, which seems like a step backwards for me.

Let me clarify the use-case, do you want to enable system-level robot accounts to manage project-level robot accounts, or both system-level and projet-level robot accounts?

IMO there are two possible solutions:

1. Expand the possible permissions to system-level robot accounts, allow them to list all system-level robot accounts and manage (incl. create/update/delete) project-level robot accounts.
2. Add a switch, so that system admin can turn on this switch to allow system-level robot accounts to manage all robot accounts.

I slightly prefer approach 1, b/c there seems no escalation. Approach 2 is easier to implement, but it essentially compromises security, which is usually more expensive to fix when there's a problem.

Please let me know your thoughts.

[slushysnowman]

Hi @reasonerjt ,

Let me clarify the use-case, do you want to enable system-level robot accounts to manage project-level robot accounts, or both system-level and projet-level robot accounts?

Both - our use case is to create robot accounts with permission to pull from multiple projects, and that is only possible with system-level robot accounts.

IMO there are two possible solutions:

1. Expand the possible permissions to system-level robot accounts, allow them to list all system-level robot accounts and manage (incl. create/update/delete) project-level robot accounts.

2. Add a switch, so that system admin can turn on this switch to allow system-level robot accounts to manage all robot accounts.

I slightly prefer approach 1, b/c there seems no escalation. Approach 2 is easier to implement, but it essentially compromises security, which is usually more expensive to fix when there's a problem.

I'd love option 2 honestly. I think this gives enough flexibility, while defaulting to the current behaviour for those who don't need this more advanced use-case. The responsibility then lies with the Harbor admins to determine whether to enable this or not - and they're also responsible for the security repercussions.

[ominiet]

I would also be interested in allowing robot accounts to manage other robots. My use case is simple automated secret rotation. It seems there is a dedicated endpoint for solely refreshing a robot account's secret which doesn't allow modification of a robot account's permissions. I guess it doesn't necessarily follow the typical "action" pattern of the project where the actions are some subset of CRUD operations. Would it be possible to add a specific action for secret refreshing of robot accounts?

Although there is a risk for escalation via a compromised 'credential rotator' robot account acquiring new secrets, the rotator could at least be restricted from creating/modifying other robot accounts. With this, the max escalation I see is to the privileges of a pre-existing robot account. Using a rotator robot account at each project level will also avoid escalation to system level, or into another project as well.

[steled]

Hi,

below is my use case.

I want to add user-group permissions to one of my robot account.

But when I use the resource shown below I get the following error:

harbor_robot_account.terraform: Creating...
╷
│ Error: [ERROR] unexpected status code got: 400 expected: 201
│  {"errors":[{"code":"BAD_REQUEST","message":"bad request permission: user-group:delete"}]}
│
│
│   with harbor_robot_account.terraform,
│   on serviceaccount.tf line 6, in resource "harbor_robot_account" "terraform":
│    6: resource "harbor_robot_account" "terraform" {

But there is an delete action for the user-group resource as you can see here.

I tried to create a robot user with the following permissions:

resource "harbor_robot_account" "terraform" {
  name        = "terraform"
  description = "system level robot account"
  level       = "system"
  secret      = "test"
  permissions {
    access {
      action   = "create"
      resource = "project"
    }
    access {
      action   = "list"
      resource = "project"
    }
    access {
      action   = "create"
      resource = "user-group"
    }
    access {
      action   = "delete"
      resource = "user-group"
    }
    access {
      action   = "read"
      resource = "user-group"
    }
    access {
      action   = "update"
      resource = "user-group"
    }
    kind      = "system"
    namespace = "/"
  }
  permissions {
    access {
      action   = "delete"
      resource = "project"
    }
    access {
      action   = "read"
      resource = "project"
    }
    access {
      action   = "update"
      resource = "project"
    }
    kind      = "project"
    namespace = "*"
  }
}

[nafaa-tayachi]

Hi - As agreed in issue goharbor/terraform-provider-harbor#439 I am posting my case here:

I'd like to use a Harbor robot account to authenticate with the Terraform provider and manage system configurations, such as authentication settings.
However, with the current robot account permissions I cannot do that as it lacks the permissions to manage system configuration.

[blancadesal]

Similarly, as explained in #20463, we would like extended robot permissions to fully automate quota management.

Current Issues:

• Only regular user accounts can manage quotas if granted admin permissions, but using such an account in automations isn't ideal compared to using a robot account with more limited and granular permissions.

Requested Features:

• Enable robot accounts to read and update individual project quotas.
• Allow robot accounts to read and update the default project quota.

These changes would help us manage quotas more securely and efficiently, including updating existing projects to match new default quotas.

[robertlemke]

Here's another use case which wasn't mentioned yet:

We want to use a system robot account which manages (hundreds of) project robot accounts. The intention is to automate the management of projects and being able to automatically create and rotate separate pull image secrets for each of them. It is not feasible to let a human do this task in our case.

[wy65701436]

hi @robertlemke can you share more details on your request? Like, what permission would you like to grant to the system robot?

[wy65701436]

Hi - As agreed in issue goharbor/terraform-provider-harbor#439 I am posting my case here:

I'd like to use a Harbor robot account to authenticate with the Terraform provider and manage system configurations, such as authentication settings. However, with the current robot account permissions I cannot do that as it lacks the permissions to manage system configuration.

Hi @nafaa-tayachi I have a different opinion. Allowing the robot to modify configurations could put the system in a more dangerous situation. Configuration changes should only be made by the system admin.

[ominiet]

Configuration changes should only be made by the system admin.

I think this is fine for deployments that don't have IaC or GitOps requirements. We'd like to manage our harbor deploy via MRs to a set of repos that manage project/rule creation, our helm deploy, etc.

For us, we'd want to create purpose built robot accounts for these repos, and then control which real users are capable making system modifications via repository access.

Additionally, we'd like to regularly rotate these secrets through automation.

[wy65701436]

Configuration changes should only be made by the system admin.

I think this is fine for deployments that don't have IaC or GitOps requirements. We'd like to manage our harbor deploy via MRs to a set of repos that manage project/rule creation, our helm deploy, etc.

For us, we'd want to create purpose built robot accounts for these repos, and then control which real users are capable making system modifications via repository access.

Additionally, we'd like to regularly rotate these secrets through automation.

@ominiet I am not quite understand your statement, does that mean you would like to give the system configuration permission to a system-level robot?

And as for the secret rotation, do you rotate these secrets through a robot? So, the robot update permission is needed, right?

[ominiet]

@wy65701436 Yes. I would like to be able to control the majority of the configuration of Harbor through terraform that is run through automation and authenticates as a robot account.

I have found I can do most of what I need currently if I authenticate as myself when I run the terraform, but run into issues if I want to create another robot account or manage that other robot account's secret when I authenticate as a system level robot account.

[robertlemke]

hi @robertlemke can you share more details on your request? Like, what permission would you like to grant to the system robot?

Sorry for the late reply …

We've got a cluster running potentially hundreds of customer projects. Each project should have its own Harbor project, containing images which only that customer project should have access to.

Now I want to create a pull image secret (project robot account) for each of those customer projects, to make sure they only have access to their own images.

Since the customer projects come and go, this needs to be automated. Therefore, I need a system robot account which can create project robot accounts and assign them the right to pull images.

I hope that explains it a bit better …

[ianseyer]

+1 to this

We would like a robot user to manage our terraform, but it is extremely limited (e.g. we cannot control our OIDC configuration from terraform with a robot user)