Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Harbor API access via OIDC from other clients not possible #14236

Open
kschu91 opened this issue Feb 11, 2021 · 7 comments · May be fixed by #20851
Open

Harbor API access via OIDC from other clients not possible #14236

kschu91 opened this issue Feb 11, 2021 · 7 comments · May be fixed by #20851
Assignees
@reasonerjt
Labels
area/auth-integration backlog kind/requirement New feature or idea on top of harbor

Comments

@kschu91
Copy link
Contributor

kschu91 commented Feb 11, 2021

We have configured OIDC as authentication mechanism for Harbor. Also, we have several other applications that are consuming the Harbor API.

With OIDC enabled, authentication against the Harbor API is only possible with a valid OpenID Connect ID Token as Bearer Authentication header.

As far as I understood the OpenID Connect specification, the ID Token should not be used to grant access to ressources - like the Harbor API. The Access Token is meant for that.

Harbor validates the ID Token for API requests using the go-oidc library internally. This library has SkipClientIDCheck enabled by default (which is totally fine for ID Tokens).

This leads to the fact, that Harbor does not allow access to the API with valid tokens, issued by other clients from the same issuer. You are forced to use Harbors OIDC client credentials in other applications to be able to interact with the Harbor API.

Expected behavior:
I would have expected that Harbor uses an Access Token to grant access to API resources rather than the ID Token. Then this should not be an issue, right?

I can see two possible solutions:

  • Change authorization of Harbor API to use Access Tokens instead of ID Tokens
  • Allow setting the SkipClientIDCheck via Harbor Configuration (leads to a possible security leak)

Steps to reproduce the problem:

  • Enable OIDC auth in Harbor with credentials for ClientA
  • Fetch an ID Token from the same Issuer with client credentials for ClientB
  • Make an API call against the Harbor API with that ID Token issued by ClientB

Harbor will fail with failed to verify token: oidc: expected audience ClientA got ClientB

Versions:
Please specify the versions of following systems.

  • harbor version: [v2.1.3]
  • docker engine version: [19.03.13]
  • docker-compose version: [1.24.0]
@Vad1mo Vad1mo mentioned this issue Feb 11, 2021
Closed
@Vad1mo
Copy link
Member

Vad1mo commented Feb 11, 2021 •
edited
Loading

Duplicate of #14145

2.2 has a more sophisticated Robot account that could also be used for API operations. We only need to request additional set of permission.

I suggest @kschu91 to contribute on that issue to raise more awareness!

@kschu91
Copy link
Contributor Author

kschu91 commented Mar 4, 2021

Duplicate of #14145

2.2 has a more sophisticated Robot account that could also be used for API operations. We only need to request additional set of permission.

I suggest @kschu91 to contribute on that issue to raise more awareness!

@Vad1mo thanks for your reply. But this does not solve everything. Robot accounts with access to the API will solve machine to machine authentication against the API. But what about personal access to the API? Every person is then required to use a robot account to access the API.

We are trying to follow the Zero Trust security principle, but since the harbor API is almost not usable with OpenID Connect it makes it really hard.

@kschu91
Copy link
Contributor Author

kschu91 commented Mar 4, 2021

@Vad1mo If it is not possible to fully support OpenID for the Harbor API, maybe a combination of #14145 and the possibility to support access to the API for OIDC Users with their cliSecret?

But I personaly would prefer a proper working OpenID authorization for the API. Is this something I might can contribute on or are guys sticking to the approach from #14145?

@reasonerjt reasonerjt added area/auth-integration backlog kind/requirement New feature or idea on top of harbor labels Mar 12, 2021
@reasonerjt
Copy link
Contributor

@kschu91
I don't think skip client ID is a good idea...
Implementing a STS for Harbor is heavy. Could you elaborate the flow in your mind regarding the access token?

@mdconner mdconner mentioned this issue May 24, 2021
Closed
@github-actions
Copy link

github-actions bot commented Jul 5, 2022

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 github-actions bot added the Stale label Jul 5, 2022
@Vad1mo Vad1mo removed the Stale label Jul 6, 2022
@Vad1mo
Copy link
Member

Vad1mo commented Jul 6, 2022

Lets don't close this one and try to come with a solution. Accessing Harbor AP via OIDC is generally something we want to make possible.

@kjenney
Copy link

kjenney commented Aug 11, 2023

Agreed! Accessing Harbor AP via OIDC is generally something we want to make possible.

@LGhoull LGhoull linked a pull request Aug 14, 2024 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@reasonerjt reasonerjt

Labels
area/auth-integration backlog kind/requirement New feature or idea on top of harbor
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Extend oidc_cli security context generator to include calls to the v2… LGhoull/harbor
4 participants
@Vad1mo @reasonerjt @kschu91 @kjenney