-
Notifications
You must be signed in to change notification settings - Fork 80
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.
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
Add proposal CLI-secret-for-api #250
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
# Proposal: Use CLI secret for auth against the API (OIDC) | ||
|
||
Author: Luis Fittkau | ||
|
||
Discussion: - | ||
|
||
## 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. | ||
|
||
## 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 | ||
|
||
## Non-Goals | ||
|
||
- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 change disables deprecates the authentication via id token. | ||
|
||
## 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 (still needs to be adjusted to only deprecate and not remove the id Token) | ||
|
||
## Open issues (if applicable) | ||
|
||
https://github.com/goharbor/harbor/issues/14236 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you outline the backward compatibility or its lack of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just added some more clarification in the compatibility section. The id token can still be used, but is deprecated.