Make invalidating CLI secrets feature optional

[j-zimnowoda]

Hi community,
I would like to share some thoughts about using CLI secret when OIDC is enabled and possible enhancements.

Is your feature request related to a problem? Please describe.
It often happens that CLI secret gets invalidated after JWT expiries.
I understand that by harbor's design, JWT is a single source of truth, thus CLI secrets gets invalidated if JWT is invalidated.

Anyway, I do not consider this as a security enhancement, because the same CLI secret can be used just after JWT is refreshed. Once an intruder obtains CLI secret, he just need to wait, until a user is logged in, so a new JWT becomes valid, so he can use the same CLI secret.

The OIDC login to harbor UI and registry login methods are two totally different ways of user authentication and in my opinion should not depend on each other.

This design is also source of unclear issues, because docker registry does not inform a user about need of refreshing the JWT. It just claims about Error response from daemon: Get https://<domain>/v2/: unauthorized: authentication required. This message is not actionable and a user is not able to come up with the solution.

Describe the solution you'd like
Companies should be able to define if they want CLI secrets to get invalidated together with JWT or not.
There should be a flag that allows to switch on/off this feature.

[reasonerjt]

IMO, the CLI secret SHOULD depends on the validity of ID token, otherwise if the user is removed from IDP the CLI still can be used.

If we make the disconnection, the IDP admin invalidate a user in the IDP, the user can no longer login to Harbor portal or access API but he can still use the CLI secret to pull/push artifacts.

This error Get https://<domain>/v2/: unauthorized: authentication required is hard-coded in docker, and on Harbor side we can only know the token associate with CLI secret is no longer valid.

[Morriz]

So can we at least be told how to work with this? Default TTL for a JWT is usually suggested to be 60 seconds. This is not problematic as dependent parts would just use the provided refresh token and get a new valid access token. Why is this problematic for harbor? Is harbor not transparently refreshing it's access token when docker client uses this secret? That would break the promise of OIDC imo.

[j-zimnowoda]

IMO, the CLI secret SHOULD depends on the validity of ID token, otherwise if the user is removed from IDP the CLI still can be used.

If we make the disconnection, the IDP admin invalidate a user in the IDP, the user can no longer login to Harbor portal or access API but he can still use the CLI secret to pull/push artifacts.

This error Get https://<domain>/v2/: unauthorized: authentication required is hard-coded in docker, and on Harbor side we can only know the token associate with CLI secret is no longer valid.

Thank for reply. I understand your reasoning but this hybrid solution results in quite ambiguous errors. Would it be possible to use OAuth2 mechanism for docker registry: https://docs.docker.com/registry/spec/auth/token/ ?

[reasonerjt]

@Morriz Under the hood Harbor does try to refresh the token when verifying the CLI secret.

@j-zimnowoda could you elaborate the solution? I don't think this works with regular OIDC providers out of the box.

[Morriz]

@Morriz Under the hood Harbor does try to refresh the token when verifying the CLI secret.

Isn't it strange then that we don't see a refreshed session when executing docker commands? It seems as if harbor code does not ask for a token refresh after the initial docker login. Subsequent docker commands seem to not trigger a refresh.

[github-actions]

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.