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[bot]]

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? :cat2:

[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[bot]]

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. :100:

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

https://github.com/goharbor/community/pull/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

[xaleeks]

@jorgemoralespou I will ping you on slack to discuss this

[oimoit]

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

[wy65701436]

We introduce 8 more APIs access in the v2.2 for both project & system robot account.

[markafarrell]

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

any security concerns? @reasonerjt @wy65701436

@xaleeks did this make it into v2.2 If not is there a plan to allow robot account to retrieve the vulnerability results in a future version?

[lindhe]

Are there any important reasons for not giving robot accounts full (but of course down-scopeable) access to the API?

[mrbusche]

Would be useful if robot acounts could update repository details We use this to add the README from the git repo as the description for the repository on each build.

Endpoint /projects/{project_name}/repositories/{repository_name}

[SimonAlling]

Robot accounts are at least more powerful than the GUI suggests. When creating a robot account in the web GUI, these 10 permissions are available:

• Push Artifact
• Pull Artifact
• Delete Artifact
• Read Helm Chart
• Create Helm Chart Version
• Delete Helm Chart Version
• Create Tag
• Delete Tag
• Create Artifact label
• Create Scan

However, we wanted a robot account to be able to delete "Artifact" (Docker image) labels as well as create and delete Helm chart labels. Turns out that can be accomplished using the REST API!

🙏 Let me just take a moment to express my gratitude for open source! Like so many times before, this was fairly easy to figure out simply because we had access to the source code.

Alright! Start by finding out the ID of the robot account:

HARBOR_URL="https://example.com"
 CLI_SECRET_ADMIN="halloj" # or whatever the admin password/CLI secret is
curl -u "admin:${CLI_SECRET_ADMIN:?}" -X GET "${HARBOR_URL:?}/api/v2.0/robots?page_size=100&page=1" -H  "Accept: application/json"

⚠️ The API endpoint is paginated, and the maximum page size is 100. If you cannot find the robot account you're looking for, try incrementing the page query parameter.

Format the JSON for readability in your favorite editor and then look for e.g. "id": 133742. Once you have found the ID, download and save the configuration for the robot account in question:

ROBOT_ACCOUNT_ID=133742 # or whatever the ID is
curl -u "admin:${CLI_SECRET_ADMIN:?}" -X GET "${HARBOR_URL:?}/api/v2.0/robots/${ROBOT_ACCOUNT_ID:?}" -H "Accept: application/json" --output account.json

You should now have a file that looks something like this:

📃 Content of account.json

{
  "creation_time": "2021-05-20T11:27:06.598Z",
  "description": "Testing …",
  "disable": false,
  "duration": -1,
  "editable": true,
  "expires_at": -1,
  "id": 133742,
  "level": "system",
  "name": "robot$glados",
  "permissions": [
    {
      "access": [
        {
          "action": "push",
          "resource": "repository"
        },
        {
          "action": "pull",
          "resource": "repository"
        },
        {
          "action": "delete",
          "resource": "artifact"
        },
        {
          "action": "read",
          "resource": "helm-chart"
        },
        {
          "action": "create",
          "resource": "helm-chart-version"
        },
        {
          "action": "delete",
          "resource": "helm-chart-version"
        },
        {
          "action": "create",
          "resource": "tag"
        },
        {
          "action": "delete",
          "resource": "tag"
        },
        {
          "action": "create",
          "resource": "artifact-label"
        },
        {
          "action": "create",
          "resource": "scan"
        }
      ],
      "kind": "project",
      "namespace": "*"
    }
  ],
  "update_time": "2021-05-20T14:21:00.344Z"
}

Go ahead and edit it like this:

         {
           "action": "delete",
           "resource": "tag"
         },
         {
           "action": "create",
           "resource": "artifact-label"
         },
+        {
+          "action": "delete",
+          "resource": "artifact-label"
+        },
+        {
+          "action": "create",
+          "resource": "helm-chart-version-label"
+        },
+        {
+          "action": "delete",
+          "resource": "helm-chart-version-label"
+        },
         {
           "action": "create",
           "resource": "scan"
         }

💡 Use src/common/rbac/const.go as reference.

Finally, update the robot account:

curl -u "admin:${CLI_SECRET_ADMIN:?}" -X PUT "${HARBOR_URL:?}/api/v2.0/robots/${ROBOT_ACCOUNT_ID:?}" -H "Content-Type: application/json" -T account.json

If you visit ${HARBOR_URL}/harbor/robot-accounts, you should see that the robot account now has 13 instead of 10 permissions:

• Push Artifact
• Pull Artifact
• Delete Artifact
• Read Helm Chart
• Create Helm Chart Version
• Delete Helm Chart Version
• Create Tag
• Delete Tag
• Create Artifact label
• Delete Artifact label 👈
• Delete 👈
• Create Scan
• Create 👈

(GUI support is not complete yet, so helm-chart-version-label is rendered as the empty string.)

[jxsl13]

What we seem to be missing is the actual possibility to access e.g. Tag Data (Reading Tags) in order to work with those tags in e.g. Jenkins pipelines. Currently our workflow is that we do build our images, push them into a "build" project. The "build/image:tag-run12345" image is then used to run our integration tests. Depending on the result of those integration tests, we either promote the image into the actual "target_project/image:release/1.0" repository (or delete the image) again.

In Harbor v1 this did work quite well. In Harbor v2 this seems to be somewhat not possible. (would be nice to have those also in the UI)

so it would be nice to also:

• read Tags (list tags)
• copy images from A to B (copy artifact)

[ChrisJBurns]

I too am getting errors when listing tags on a Concourse build. Robot account doesn't have the permissions to list tags.

--- EDIT This has now been resolved due to the more enhanced permissions you can give Robot accounts. Although this is still something you can only do through the API as far as I'm aware.

[sphr2k]

Did I miss something, or is it still not possible to retrieve the vulnerability results via API usoing a robot account?

[orblazer]

Hello, For implement that in replacement of current dropdown i propose an table look The bellow example have the all permissions.

Project

Resource	list	read	create	delete	update	pull	push	stop
helm-chart	x	x	x	x
helm-chart-version	x	x	x	x
helm-chart-version-label			x	x
label
log	x
member	x	x	x	x	x
metadata	x	x	x	x	x
quota		x
repository	x	x		x	x	x	x
tag-retention	x	x	x	x	x
immutable-tag	x		x	x	x
robot	x	x	x	x	x
notification-policy	x	x	x	x	x
scan			x					x
scanner	x	x	x
artifact	x	x	x	x
tag	x		x	x
accessory	x
artifact-addition		x
artifact-label			x	x
preheat-policy	x	x	x	x	x
project	x	x	x	x	x

System

Resource	list	read	create	delete	update	stop
config		x			x
ldap-user	x		x
quota	x	x			x
tag-retention	x	x	x	x	x
robot	x	x	x	x	x
scanner	x	x	x	x	x
preheat-instance			x
audit-log	x
project	x		x
user	x	x	x	x	x
user-group	x	x	x	x	x
registry	x	x	x	x	x
replication	x	x	x	x	x
garbage-collection	x	x	x		x
replication-adapter	x
replication-policy	x	x	x	x	x
scan-all		x	x		x	x
system-volumes		x

Note

• The get repository ask list action instead of read https://github.com/goharbor/harbor/blob/fd92efe1400d4be45dee8427f8ee9bfd2e8214ce/src/server/v2.0/handler/repository.go#L201
• The list scanner candidate use create instead of list https://github.com/goharbor/harbor/blob/8554b7d7c598c5b7b7bc3f709853f003f5ce5310/src/server/v2.0/handler/project.go#L583

This issues have an fix: #16381

Thanks.

[ChrisJBurns]

I can confirm that I am allowed to give more robot permissions via the UI with the latest version of the harbor helm chart.

In interests to keep things easily automated, we are using a terraform provider to create these robot accounts with the necessary permissions. More specifically the harbor_robot_account resource found here.