Robot accounts should be allowed to access the full Harbor api

[clausa]

Expected behavior and actual behavior:
I would like to use a robot account to programatically obtain vulnerability data for any repo:tag as well as other functions exposed by the api.

Expected:
Robot accounts should be allowed to access /api/ like regular user accounts.

Actual:
Robot accounts are only allowed to push/pull images and charts.
Trying to access /api always returns 401

Steps to reproduce the problem:

• (Enable OIDC)
• Create project.
• Add robot account with full push and pull permissions.
• Use robot to access: '/api/repositories/{repo}/tags/{tag}/vulnerability/details'
  $ curl -X GET "https://harbor/api/repositories/myrepo/tags/latest/vulnerability/details" -H "accept: application/json" -H "authorization: Bearer eyJhbG.....robot-account.token"
• Get a 401 {"code":401,"message":"Unauthorized"}

Versions:

harbor version: 1.8.1

Additional context:
For now, creating robot accounts via the API should be sufficient - UI might come later.

Something like:

{
  "name": "scanner",
  "description": "robot account to fetch vulnerability reports from any project",
  "access": [
    {
      "resource": "/api/repositories/*/tags/*/vulnerability/details",
      "action": "get"
    }
  ]
}

[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.

[fentas]

remove stale? 🐈

[wy65701436]

@xaleeks idea?

[kawaiipantsu]

I think it would be a good idea, many are using OIDC for auth and that can cause problems with api also would be nice to use a more "neutral" user in your scripts etc than a actual employee/username.

[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.

[troy256]

We would really like this feature too. Specifically to pull vulnerability data for specific images/tags.

[rubin55]

We ran into this issue when trying to use a robot account to DELETE tags (we want to use a cleanup script we previously used with GitLab registry that is failing with Harbor due to permissions):

%> curl -XGET https://myharbor/api/v2.0/projects/foo/repositories/example/artifacts
<lots of JSON, this works fine>

%> curl --basic -u 'somerobot:somepass' -XDELETE https://myharbor/api/v2.0/projects/foo/repositories/example/artifacts/null/tags/200616-057eb77a
{"errors":[{"code":"UNAUTHORIZED","message":"unauthorized"}]}

We think only the root account can actually use HTTP DELETE (please correct me if wrong); is it possible to let the robot account do HTTP DELETE and is this ticket related to that?

[xaleeks]

We will open up controlled access to APIs for robots in the next minor release v2.2

[fentas]

We wanted to use robot accounts to access container clair log results. Would be awesome. 💯

[AndrewNeudegg]

This would be really useful

[xygon]

This would make using the API from a service, as opposed to an actual user, so much easier.

[tompizmor]

I also agree it would be great!

[xaleeks]

goharbor/community#148

[xaleeks]

Here are the actions we're considering granting API access to robot accounts for the 2.2. I don't necessarily consider retrieving scan results part of core CI and this is also asynchronous. Maybe you can define why this needs to be retrieved programmatically, and we can consider adding for the next release

Push images / helm charts / OCI indexes / singularity files
Pull images / helm charts /OCI indexes / singularity files
Delete images / helm charts / OCI indexes / singularity files
Sign+push images
Add tag
Remove tag
Add label
Scan images

[dkulchinsky]

@xaleeks thanks for sharing the details.

We're also retrieving vuln scan reports during our images build CI pipeline, it's done in a post-build validation step where we ensure the image has no vulnerabilities beyond a certain threshold, we're aware it's an async process and take that into account in our job.

builds for images that don't meet the required vuln threshold fail and the owner is notified, this is critical to catch vulns in time and allow the dev teams to address the issue.

as a general concept, we view robot accounts as service accounts and would like to be able to perform a variety of tasks (mostly API calls) that now require that we use the built-in admin user - this is a security concern and would be great if we could use the robot/service accounts instead.

[xaleeks]

I guess API access for retrieving CVE scans is ok, we can add it to the v2.2

any security concerns? @reasonerjt @wy65701436

[jiparis]

Thanks @xaleeks.

In our case, we'd like to use robot accounts also for replication between harbor instances using both Harbor (to support charts) and Docker API adapters. Meaning that we would need Harbor API access for projects (the one the robot account belongs to), repositories and artifacts, as well as _catalogs and tags for Docker API v2. Not sure if I'm missing any other.

Is that feasible for 2.2?
Thanks!

[jorgemoralespou]

@xaleeks this last one is critical that we support it for making TAC catalog for advanced replicable in the local harbor instances. CC/ @michmike

[waldner]

There is still a helm-chart-version read permission missing for robot accounts as of harbor v2.6.0-b035ca7, which has to be patched using the API.

[Setre14]

I want to use the copy Artifact api (/projects/{project_name}/repositories/{repository_name}/artifacts) with a system robot account and although i gave it all permission for both the source and the target project the command fails with

{"errors":[{"code":"FORBIDDEN","message":"forbidden"}]}

Is it possible to also allow a robot user to access this Rest endpoint?

[monofone]

@Setre14 I have the same issue, I added the policy for creating artifacts to the robot account, this solves it for now. In addition I made a PR to add the Policy to the UI to allow direct creation of the robot account together with this policy.

[wy65701436]

Robot Account V2 is designed to expand support for more of Harbor's APIs, but not to expose them in the UI. If you would like to use the robot to call any specific API, refer to this comment to create your robots.

[dioguerra]

I'm having something of a similar behaviour (with v2.5.4).

I created a system robot account with full access to two projects (dtomasgu and harbor).
Trying to curl the harbor API to do some scripting,

curl "https://$0/api/v2.0/projects/$1/repositories/$2/artifacts?with_tag=true&with_scan_overview=false&with_label=false&with_accessory=false&page_size=25&page=${PAGE}" -H "accept: application/json" -H "authorization: Basic ${BASE_AUTH}" --compressed --silent

I notice that if the project is public it can access the API if the project is private, it does not have access.

Any thoughts?

Edit: looks like classical -n missing from echo :/

[AllForNothing]

Fixed by #19543(backend) and #19507(UI)

[Tim-herbie]

Hello,

thank you for the implementation. I created a new robot with full permission on system and project level and tested it with Terraform. It get much less errors like before, but I still get some errors. Is that expected?

I tested it with the following Versions:

• Harbor Server: Version v2.10.0-6abb4eab
• Terraform version: Terraform v1.5.7
• Harbor Terraform Provider: 3.10.5

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform planned the following actions, but then encountered a problem:

  # module.projects.harbor_robot_account.robot_account["robot-test"] will be created
  + resource "harbor_robot_account" "robot_account" {
      + disable   = false
      + duration  = -1
      + full_name = (known after apply)
      + id        = (known after apply)
      + level     = "system"
      + name      = "test"
      + robot_id  = (known after apply)
      + secret    = (sensitive value)

      + permissions {
          + kind      = "project"
          + namespace = "test"

          + access {
              + action   = "create"
              + effect   = "allow"
              + resource = "artifact-label"
            }
          + access {
              + action   = "create"
              + effect   = "allow"
              + resource = "tag"
            }
          + access {
              + action   = "list"
              + effect   = "allow"
              + resource = "artifact"
            }
          + access {
              + action   = "list"
              + effect   = "allow"
              + resource = "repository"
            }
          + access {
              + action   = "list"
              + effect   = "allow"
              + resource = "tag"
            }
          + access {
              + action   = "pull"
              + effect   = "allow"
              + resource = "repository"
            }
          + access {
              + action   = "push"
              + effect   = "allow"
              + resource = "repository"
            }
          + access {
              + action   = "read"
              + effect   = "allow"
              + resource = "artifact"
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  ~ robot_secrets = (sensitive value)
╷
│ Error: unexpected end of JSON input
│
│   with harbor_config_auth.oidc,
│   on oidc.tf line 1, in resource "harbor_config_auth" "oidc":
│    1: resource "harbor_config_auth" "oidc" {
│
╵
╷
│ Error: Error getting system configuration unexpected end of JSON input
│
│   with harbor_config_system.config_system,
│   on system-configuration.tf line 1, in resource "harbor_config_system" "config_system":
│    1: resource "harbor_config_system" "config_system" {
│
╵
gmake: *** [Makefile:19: plan] Error 1

The test robot account from the code above is already created before with Terraform. It seems for me that the full permission robot-account can´t still manage the harbor_config_system, harbor_config_auth and robot-account resources.