From 301ddcf479661045628cca2cd535738538885784 Mon Sep 17 00:00:00 2001 From: LGhoull <85150281+LGhoull@users.noreply.github.com> Date: Mon, 19 Aug 2024 11:46:45 +0200 Subject: [PATCH 1/3] Add proposal CLI-secret-for-api Signed-off-by: LGhoull <85150281+LGhoull@users.noreply.github.com> --- proposals/new/CLI-secret-for-api | 46 ++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 proposals/new/CLI-secret-for-api diff --git a/proposals/new/CLI-secret-for-api b/proposals/new/CLI-secret-for-api new file mode 100644 index 00000000..e0375f04 --- /dev/null +++ b/proposals/new/CLI-secret-for-api @@ -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 + +## Non-Goals + +- + +## 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). + +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. + +## 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 From 3df2a7f269ed5e5495bb32da7a08d0f331e86ff9 Mon Sep 17 00:00:00 2001 From: LGhoull <85150281+LGhoull@users.noreply.github.com> Date: Thu, 10 Oct 2024 16:20:41 +0200 Subject: [PATCH 2/3] Only deprecate auth via Id token instead of removing it completely Signed-off-by: LGhoull <85150281+LGhoull@users.noreply.github.com> --- proposals/new/CLI-secret-for-api | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/proposals/new/CLI-secret-for-api b/proposals/new/CLI-secret-for-api index e0375f04..b396bf0b 100644 --- a/proposals/new/CLI-secret-for-api +++ b/proposals/new/CLI-secret-for-api @@ -6,7 +6,7 @@ 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 +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 @@ -20,8 +20,6 @@ The OIDC id token is accessible via either the harbor debug log, which the user ## 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 ## Non-Goals @@ -31,7 +29,7 @@ The OIDC id token is accessible via either the harbor debug log, which the user 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). -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. +This change disables deprecates the authentication via id token. ## Compatibility @@ -39,7 +37,7 @@ 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 +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) From 34ad578e146e3a875492be6e55f82e7356801b83 Mon Sep 17 00:00:00 2001 From: LGhoull <85150281+LGhoull@users.noreply.github.com> Date: Wed, 30 Oct 2024 13:33:48 +0100 Subject: [PATCH 3/3] Further clarify CLI-secret-for-api Signed-off-by: LGhoull <85150281+LGhoull@users.noreply.github.com> --- proposals/new/CLI-secret-for-api | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/new/CLI-secret-for-api b/proposals/new/CLI-secret-for-api index b396bf0b..3aebba24 100644 --- a/proposals/new/CLI-secret-for-api +++ b/proposals/new/CLI-secret-for-api @@ -20,10 +20,11 @@ The OIDC id token is accessible via either the harbor debug log, which the user ## Proposal - Extend oidc_cli security context generator to include calls to the v2 API +- document the fact that the cli secret can be used for oidc authentication in general in the docs ## Non-Goals -- +- The UI doesn't really have to be changed since the cli secret is already a thing and used for docker login. Perhaps we can rename it to "user secret" or something similar. ## Rationale @@ -33,7 +34,7 @@ This change disables deprecates the authentication via id token. ## Compatibility -Authentication against the API via OIDC id token will no longer be possible. +Authentication against the API via OIDC id token will be deprecated (but still possible), and removed in a future release. ## Implementation