CI Login

[ianaya89]

Rationale

A user should be able to authenticate the CLI in a non-interactive mode. This is specifically useful for throw-away environments like in a typical CI provider, or when used in bash scripts. In all of these cases, an interactive web-based login is not an option.

Instead, the Checkly CLI should have a --token flag that overrides any current, local auth tokens. The user gets this token by creating it explicitly in the Checkly web UI.

Acceptance criteria

• [x] The CLI has a --token flag at the global level. This flag has a per-invocation scope. It is not stored anywhere locally.
• [x] The Checkly web UI has an option to create and delete this token.
• [x] The CLI, when invoked with --token overrides any locally available auth methods.

Example:

# checkly status --token ABCD123XYZ

[ianaya89]

Will this token be an API_KEY or we will use something new?

[tnolet]

Will this token be an API_KEY or we will use something new?

@ianaya89 it will practically work the same. I think we just need to generate a new type of token that is user specific. However, a fallback to just the standard API_KEY could also work. The big downside is that is will immediately give access to all account resources and is not user specific.

[ndom91]

So the initial release of this is merged in CLI and will merge the backend PR as soon as our merge window opens back up tomorrow.

Next steps in terms of this cli oauth user login flow requires us to make some more significant changes on the backend in order to add user based apiKeys in addition to the preexisting account based ones.

Therefore I will set this issue to "completed" now. The backend work will be tracked to a ~clubhouse~ shortcut issue ch-4670 as well as has to do with #46 here on Github.

[tnolet]

So the initial release of this is merged in CLI and will merge the backend PR as soon as our merge window opens back up tomorrow.

Next steps in terms of this cli oauth user login flow requires us to make some more significant changes on the backend in order to add user based apiKeys in addition to the preexisting account based ones.

Therefore I will set this issue to "completed" now. The backend work will be tracked to a ~clubhouse~ shortcut issue ch-4670 as well as has to do with #46 here on Github.

This is a good comment that informs public readers and keep some of the security parts private. Kudos.

[ianaya89]

I think we should only use env variables for CI authentication and not a token argument. The token argument could be bad in terms of security because it will write sensitive data in CI/user logs.

We can unify API Keys and User Keys at the same env variable (ie: CHECKLY_AUTH_KEY) and use that as the source of truth. If the env variable is present, CLI will use that otherwise will ask for login.

[ianaya89]

CLI login could be done in two different ways

• Run login command with API key and Account ID flags:

  $ checkly login --api-key xxx -account-id zzz

• Exporting global env variables:

  $ export CHECKLY_API_KEY=xxx
  $ export CHECKLY_ACCOUNT_ID=zzz

The main difference is that login command will persist data in config files and env variables are scoped to bash current session