Keptn CLI multiple contexts like KUBECONFIG

[christian-kreuzberger-dtx]

Often users need to switch their kube context (e.g., kubectl config use-context my-cluster-name, or gcloud container clusters get-credentials ... or export KUBECONFIG=/etc/rancher/k3s/k3s.yaml), but they end up still being connected to previous Keptn installation.

To overcome this, users need to manually authenticate the Keptn CLI with the correct Kubernetes cluster, as detailed here: https://keptn.sh/docs/0.7.x/reference/cli/#authenticate-keptn-cli

This could be as easy as keptn auth --endpoint=$KEPTN_ENDPOINT --api-token=$KEPTN_API_TOKEN on Linux (where as KEPTN_ENDPOINT and KEPTN_API_TOKEN can be retrieved via kubectl commands), but requires some manual work.

Another use-case that appears is that users wants to share their Keptn credentials (endpoint and api-token) with another user, without having to share access to the Kubernetes cluster. Therefore the user might want to be able to export the credentials, as well as re-use the credentials via an environment variable, e.g.,

export KEPTNCONFIG=./keptn/workshop-credentials-1234
keptn send-event ...

Goal

Implementation of this issue should accomplish the following:

• make it easier for users to authenticate to a Keptn cluster by just configuring the Kubernetes context
• enable the user to switch between multiple Keptn installations (stored in config files locally)

Definition of Done

• Introduce a config file containing the API Token and endpoint (e.g., using cobra) - similar to what ~/.keptn/.keptn contains on Linux, but I'd prefer a format in JSON or YAML
• Introduce a command to export the current API Token and endpoint into a config file, e.g., keptn auth --export)
• CLI checks if KEPTNCONFIG is set, and uses the config file provided in this environment variable
• If KEPTNCONFIG is not set, the CLI should fall back to the existing mechanism (using credentialmanager for linux/darwin/windows)
• When executing keptn auth without any parameters and without KEPTNCONFIG, the CLI should try to do its best to try to authenticate with the Kubernetes cluster that kubectl is currently using.
  • In case of multiple Keptn installations on the same cluster, the CLI should list all of them separated by ID/namespace/whatever, and provide a parameter to the keptn auth command to select one (e.g., keptn auth --namespace=keptn-demo)
  • The credentials should be stored on the local system via the good old credentialmanager

Discussion

One missing link right now is that keptn CLI is not automatically connected to the currenct kube-context. This would require keptn auth to be executed for every time a keptn CLI command is executed. We could do that, but this sounds like it is calling for trouble: just imagine we try to fetch the keptn secret etc... every time we send an event to the Keptn API.

To prevent this, we could store a hash or an ID of the current kubecontext, and warn the user if we have detected a change.

[jetzlstorfer]

Related to #1863

[supra08]

I had a couple of ideas too. Would be glad to discuss them and work towards this feature.

[supra08]

Hi!
I would like to discuss some of the ideas that I came up for the implementation:

In case of multiple Keptn installations on the same cluster, the CLI should list all of them separated by ID/namespace/whatever, and provide a parameter to the keptn auth command to select one (e.g., keptn auth --namespace=keptn-demo)
These are my implementation considerations:

• We can use the 'namespace' as a safe parameter to distinguish between different kubernetes installations.
• If that is so, we can use the kubectl client to list all the available namespaces with keptn installations in the auth command. There might be no possibility to cache the list because the installations could be manual. And this wouldn't be required too as keptn auth will be used once only when connecting to a cluster and that information could be saved in persistent storage.
• Now the credential manager would have separate entries for each keptn namespace mapped to the corresponding creds (analogous to KEPTNCONFIG's purpose)

One missing link right now is that keptn CLI is not automatically connected to the currenct kube-context.

This, as mentioned in the issue itself, we can store the hash of the current kubecontext in a file in ~/.keptn/<context_store>(to limit it to the current user). So whenever a CLI command is executed, a hash is prepared of the context and cross-referenced by the stored hash. In case of difference, the user will be asked to redo the auth, on success of which shall the ~/.keptn/<context_store> file be updated.

KEPTNCONFIG's referencing of credentials json or yaml file is similar to what is discussed here: #1863. I would try working that out.

[ankitjain28may]

@bacherfl Please reopen the issue