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

Add proposal CLI-secret-for-api #250

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Add proposal CLI-secret-for-api #250

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
301ddcf
Add proposal CLI-secret-for-api
LGhoull Aug 19, 2024
3df2a7f
Only deprecate auth via Id token instead of removing it completely
LGhoull Oct 10, 2024
34ad578
Further clarify CLI-secret-for-api
LGhoull Oct 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions proposals/new/CLI-secret-for-api
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Proposal: Use CLI secret for auth against the API (OIDC)

Author: Luis Fittkau

Discussion: -

## Abstract

Use basic auth, consisting of username and CLI secret, instead of the OIDC id token when authenticating against the API when OIDC is enabled

## Background

With OIDC enabled, it is not possible for a normal user to use the API without accessing the OIDC id token, which is not accessible by appropriate means; this proposal fixes that.

The usual workaround for this is to use robot accounts, but that would mean that each user has to own a separate robot account just to access the API, which doesn't seem clean to me.
Also, this means that robot accounts can not be created via the API by someone other than the local admin.

The OIDC id token is accessible via either the harbor debug log, which the user can't see, or via direct communication with the identity provider, which requires credentials that the user isn't supposed to have.

## Proposal

- 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Non-Goals

-
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about docker login

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## 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).
Copy link
Contributor

@reasonerjt reasonerjt Aug 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


This change disables the authentication via id token. Alternatively, one could allow both ways of authentication at the same time and only deprecate the id-token-way, but since the id token is such a "bumpy" solution (in my opinion) anyway, I don't think it is necessary.
LGhoull marked this conversation as resolved.
Show resolved Hide resolved

## Compatibility

Authentication against the API via OIDC id token will no longer be possible.

## Implementation

A first version is already done, see https://github.com/goharbor/harbor/pull/20851

## Open issues (if applicable)

https://github.com/goharbor/harbor/issues/14236
Loading