Harbor: Robot accounts should be allowed to access the full Harbor api

Created on 16 Aug 2019  路  20Comments  路  Source: goharbor/harbor

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"
    }
  ]
}
arerobot-account candidat2.2.0 kinrequirement

Most helpful comment

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

All 20 comments

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.

remove stale? :cat2:

@xaleeks idea?

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.

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.

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

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?

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

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

This would be really useful

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

I also agree it would be great!

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

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

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

any security concerns? @reasonerjt @wy65701436

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!

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

@jorgemoralespou I will ping you on slack to discuss this

Hi
Could you please advise when 2.2 is expected to be released?
Thank you

Was this page helpful?
0 / 5 - 0 ratings