Add proposal CLI-secret-for-api #250

LGhoull · 2024-08-19T09:47:39Z

No description provided.

Signed-off-by: LGhoull <[email protected]>

LGhoull · 2024-08-19T09:48:41Z

This is a kind/proposal, but I can't add any labels

reasonerjt · 2024-08-22T08:45:35Z

proposals/new/CLI-secret-for-api

+
+- Extend oidc_cli security context generator to include calls to the v2 API
+- remove idtoken security context generator
+- rename and consolidate tests and names accordingly


We should add a case to make sure when the token is invalid the cli secret will not be usable for calling the API.

You mean the id token? From my understanding, harbor attempts to renew the id token to keep the secret valid. If that's not possible, the Secret becomes invalid. All this logic already exists for the CLI secret

proposals/new/CLI-secret-for-api

reasonerjt · 2024-08-22T08:47:18Z

proposals/new/CLI-secret-for-api

+
+## Rationale
+
+This change can be seen as a security "downgrade", but since this way of authenticating is already present when using the docker cli, the vulnerability already exists (if it can be considered one).


We should double check if the token is invalid the secret becomes invalid at the same time, and clarify it in the design. If there is vulnerability existing now, we should absolutely not move forward, we should fix the vulnerability.

What I meant with this being a possible "vulnerability" (depending on the way you look at it, personally I don't think it is a vulnerability) is the fact that the CLI secret only needs to be copied from the UI once and can be used repeatedly without signing in with OIDC again. But:

This is already the case for the CLI secret

The CLI secret is invalidated when the id token can not be renewed (for example when the user in the ID provider is deleted)

This is basically how API keys work in numerous other applications

LGhoull · 2024-09-12T11:55:33Z

@reasonerjt Could you respond to the discussions?

Signed-off-by: LGhoull <[email protected]>

LGhoull · 2024-10-10T14:21:31Z

@reasonerjt Could you respond to the discussions please?

LGhoull · 2024-10-24T12:38:37Z

@Vad1mo @zyyw @chlins Anyone? Can we discuss this?

Vad1mo

It is very difficult for me to follow on the details of the PR, on high level I think I understand what you are trying to achieve and why.

There are lot of details missing the description. Especially, all the backward-compatible and changes neeed to UI, Docs, and workflows are missing.

Vad1mo · 2024-10-24T15:39:12Z

proposals/new/CLI-secret-for-api

+
+## Abstract
+
+Allow basic auth, consisting of username and CLI secret, in addition to the OIDC id token when authenticating against the API when OIDC is enabled. Deprecate auth via OIDC id token.


Can you outline the backward compatibility or its lack of?

just added some more clarification in the compatibility section. The id token can still be used, but is deprecated.

Vad1mo · 2024-10-24T15:40:35Z

proposals/new/CLI-secret-for-api

+
+## Non-Goals
+
+-


What about docker login

docker login already works with the cli secret and nothing changes about that

Signed-off-by: LGhoull <[email protected]>

LGhoull · 2024-10-30T12:36:20Z

@Vad1mo I just added some clarification in the proposal. Of course we should document the new behavior. The UI doesn't have to change since CLI secrets already exist (maybe we can rename them).

LGhoull · 2025-01-23T09:09:06Z

Can we move forward here please?

VinuelMancent · 2025-04-09T07:23:06Z

Can I assist on getting this PR merged? The change is IMHO very important, but since nothing happened here for months, i fear this will never see the light of day

LGhoull · 2025-04-14T07:21:06Z

@Vad1mo @chlins @zyyw Can we move forward here please?

malmor · 2025-06-13T05:22:41Z

Hey there, any update on this proposal?

In goharbor/harbor#16647 (comment) a different concept of classic API keys was mentioned. Should this be re-written (or replaced) by that idea?

malmor · 2025-09-30T08:24:31Z

Hey @Vad1mo @reasonerjt,
just wanted to check in on this proposal. Is there anything we can do to support this in moving forward?

malmor · 2025-12-12T10:13:05Z

Hey @Vad1mo @reasonerjt,
is there any update regarding this proposal or the concept of "API Keys" in general? Thanks!

Vad1mo · 2025-12-12T10:55:41Z

the proposal and PR introduces a breaking change, this needs to be addressed and resolved, otherwise it has no chance getting in.

Vad1mo · 2025-12-12T10:59:01Z

The PR removes ID token support entirely, but the proposal says "deprecate".

In the proposal it states:
"ID token authentication will be deprecated initially, with removal planned for future releases"

But PR #20851 deletes idtoken.go completely. This inconsistency must be resolved. The implementation should:

deprecation warning logs when ID token is used?
Keep ID token functional for N releases?

How will existing integrations know ID token auth is deprecated?

Return Deprecation HTTP header?
Log warnings?
Documentation update plan?

Users currently using ID token auth need guidance:

How to obtain their CLI secret
How to update their scripts/tools
Timeline for mandatory migration

The proposal implies robot accounts are the only workaround. However, users CAN use ID tokens today - they're just hard to obtain. The proposal should clarify this is a usability improvement, not enabling previously impossible access.

Will CLI secret auth support all API operations? Including:
- System admin operations (/api/v2.0/configurations)
- User management (/api/v2.0/users)
- OIDC settings modification
Should admins be able to disable CLI secret API auth? A feature flag would address enterprise compliance concerns.
What happens to existing ID token integrations during deprecation? Are there any known consumers (CI/CD tools, SDK libraries)?

malmor · 2025-12-12T12:58:45Z

Hey @Vad1mo, thank you for these insights and feedback!

I see that there are some inconsistencies here, definitely something that needs to be figured / straighten out.

Maybe to address to core difference here: Do you think just adding support for using the CLI secret via the API would also be a valuable change?

This way ...

Existing integrations will not breaking, removing the need for complex deprecation phases etc.
For simple scenarios users can opt in to use the CLI secret for authentication, without having to implement the entire OIDC flow
For advanced scenarios (e.g. enterprise context) users can still implement the full OIDC flow, taking advantage of additional security and compliance features

Do you think this would make a "better" proposal, with an easier road ahead for implementation?

Add proposal CLI-secret-for-api

301ddcf

Signed-off-by: LGhoull <[email protected]>

LGhoull requested review from a team as code owners August 19, 2024 09:47

github-actions bot assigned chlins, Vad1mo and zyyw Aug 19, 2024

LGhoull mentioned this pull request Aug 19, 2024

Extend oidc_cli security context generator to include calls to the v2… goharbor/harbor#20851

Closed

5 tasks

reasonerjt reviewed Aug 22, 2024

View reviewed changes

proposals/new/CLI-secret-for-api Outdated Show resolved Hide resolved

reasonerjt reviewed Aug 22, 2024

View reviewed changes

Vad1mo added the kind/proposal label Oct 3, 2024

Only deprecate auth via Id token instead of removing it completely

3df2a7f

Signed-off-by: LGhoull <[email protected]>

Vad1mo requested changes Oct 24, 2024

View reviewed changes

Further clarify CLI-secret-for-api

34ad578

Signed-off-by: LGhoull <[email protected]>

reasonerjt mentioned this pull request Dec 12, 2024

401 Unauthorized on some API endpoints when using OIDC goharbor/harbor#16647

Open


		## Rationale

		This change can be seen as a security "downgrade", but since this way of authenticating is already present when using the docker cli, the vulnerability already exists (if it can be considered one).


		## Abstract

		Allow basic auth, consisting of username and CLI secret, in addition to the OIDC id token when authenticating against the API when OIDC is enabled. Deprecate auth via OIDC id token.

Add proposal CLI-secret-for-api #250

Are you sure you want to change the base?

Add proposal CLI-secret-for-api #250

Uh oh!

Conversation

LGhoull commented Aug 19, 2024

Uh oh!

LGhoull commented Aug 19, 2024

Uh oh!

reasonerjt Aug 22, 2024

Choose a reason for hiding this comment

Uh oh!

LGhoull Aug 22, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

reasonerjt Aug 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LGhoull Aug 22, 2024

Choose a reason for hiding this comment

Uh oh!

LGhoull commented Sep 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LGhoull commented Oct 10, 2024

Uh oh!

LGhoull commented Oct 24, 2024

Uh oh!

Vad1mo left a comment

Choose a reason for hiding this comment

Uh oh!

Vad1mo Oct 24, 2024

Choose a reason for hiding this comment

Uh oh!

LGhoull Oct 30, 2024

Choose a reason for hiding this comment

Uh oh!

Vad1mo Oct 24, 2024

Choose a reason for hiding this comment

Uh oh!

LGhoull Oct 30, 2024

Choose a reason for hiding this comment

Uh oh!

LGhoull commented Oct 30, 2024

Uh oh!

LGhoull commented Jan 23, 2025

Uh oh!

VinuelMancent commented Apr 9, 2025

Uh oh!

LGhoull commented Apr 14, 2025

Uh oh!

malmor commented Jun 13, 2025

Uh oh!

malmor commented Sep 30, 2025

Uh oh!

malmor commented Dec 12, 2025

Uh oh!

Vad1mo commented Dec 12, 2025

Uh oh!

Vad1mo commented Dec 12, 2025

Uh oh!

malmor commented Dec 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

reasonerjt Aug 22, 2024 •

edited

Loading

LGhoull commented Sep 12, 2024 •

edited

Loading