search

kubeshop / monokle-cli

CLI for Monokle core validation library
19 stars 3 forks source link

`--access-token` uses incorrect authorization scheme #25

Closed WitoDelnat closed 1 year ago

WitoDelnat commented 1 year ago

When an access token is directly passed we should not use Bearer but instead Apitoken.

Example

{
  "Authorization": "Apitoken mca_fsdjkl43fdsd"
}
f1ames commented 1 year ago

This will require updating @monokle/synchronizer package, see:

murarustefaan commented 1 year ago

Please take note of the following PR that implemented ApiKey authentication. https://github.com/kubeshop/monokle-saas/pull/1918/files#diff-7d82b84f6383f4b21259aa318e06568a705684968a921bf0474379c37cac899bR71-R83

The scheme for the Automation Token based Authorization Header is actually ApiKey instead of Apitoken.

f1ames commented 1 year ago

This got a bit broader in scope since initially we used device flow token and access token (now called automation token) interchangeably meaning both required the same access scope (getUser and getProject queries). Since the access scope is different it needs to work differently as @WitoDelnat mentioned:

The CLI has a project matching algorithm which uses all the projects for the currently authenticated user; of course for Automation we are not an actual authenticated user and this falls apart.

We’ll need to implement a different project matching algorithm which would look at all the projects for the current Automation token.

So we concluded that user/interactive login should only allow device flow. Automation tokens can be used only by passing with additional arg for commands which integrate with cloud (validate and config show AFAIR), and this token will not be stored anywhere for further use.

This behavior will be aligned with VSC ext too (https://github.com/kubeshop/vscode-monokle/pull/45).