Improve OpenShift login experience

[manusa]

Context

I was in a Java user group (JUG) meetup yesterday giving a workshop about Kubernetes for Java developers.

The workshop includes several activities, the first one being deploying a Java application into OpenShift using the OpenShift Maven|Gradle plugin. Then it continues with other tasks involving the interaction with Kubernetes using Java (this includes tools such as the Fabric8 Kubernetes Client and JBang).

When performing the first task, users login into an OpenShift console with a user and credentials provided. The following steps apply:

1. Navigate to the OpenShift console in your browser: https://openshift.example.com
2. Login with the following credentials: example-user-nn | example-password
3. 🚨 Download the oc tool from the console
4. Get your credentials from the console (Display token)
5. 🚨 Login from your command line
6. 🚨 Create a project: oc new-project example-user-nn
7. Bootstrap an application (code.quarkus.io | start.spring.io)
8. Add the JKube OpenShift Maven|Gradle plugin
9. 🚀 Deploy your application

Experience issues

The purpose of steps 3 to 5 is just to add the appropriate entry in your .kube/config file so that JKube->Fabric8 can pick those up.

When performing step 3, we need to download a very big file and extract it just to achieve this very simple purpose. This simply adds a network overhead and extra steps that really won't provide much value for the Java only experience.

When performing step 5, most users will need to execute ./oc login $token which might cause a number of issues. The first thing is that most users won't have oc in their path, so they will need to open a terminal in the location of their Downloads directory. In some operating systems (OS)s this step might be prevented (security) and will need some override settings.

The last hassle during the workshop was the creation of the project (step 6). The provided cluster didn't have an assigned default project for each user and this step was required. We need to make sure (maybe this already works) that we can overcome this issue by using the JKube's built-in features to create a Namespace->Project and use it.

Possible solutions

Implement an OpenShift specific login goal/task that would allow the users to skip steps 3 to 5.

$ ./mvnw oc:login -Dtoken=$yourTokenFromTheConsole

[manusa]

This might also be interesting for CI purposes.

[ShivangMishra]

@manusa to implement this, can we directly edit the ./kube/config file in our new goal using oc config? I think this is a simple and straightforward solution, or am I missing something?

[rohanKanojia]

Sorry, I don't think this is a straightforward solution. We also need to check whether we even need to download oc CLI since we deal with REST API directly.

[manusa]

The solution should basically do whatever the oc login execution does. So the very first step is to identify where the oc login code is and analyze what path is followed when executed when the token is provided as an argument.

Downloading the oc client binary should be completely avoided (unless this is required for some reason).

[juazugas]

I can work on this

[manusa]

As agreed internally and based on @juazugas notes:

Goal/Task and properties (to be provided as command-line flags)

• Maven goal: oc:login
• Gradle task: ocLogin
• Properties/Flags:
  • token: The login token as retrieved from the OpenShift web console
  • server: The server address as retrieved from the OpenShift web console
  • kubernetes.trust.certificates: Trust the remote cluster's certificate in case it's unknown (n.b. this is a standard Fabric8 Kubernetes Client property that might not need to be handled by JKube's logic. However, it should be documented for this feature)

Expected behavior

1. User runs the goal with the token and server flags
   1. The server has a public, known certificate, continue to 2.
   2. The server has an unknown certificate, log WARNING and exit:

      The server uses a certificate signed by an unknown authority.
      You can bypass the certificate check, but any data you send to the server could be intercepted by others.
      To use insecure connections, repeat the command including the kubernetes.trust.certificates property.

   3. The server has an unknown certificate but the user has added the kubernetes.trust.certificates flag to skip the certificate verification, continue to 2.
2. JKube performs a request to the cluster
   1. Authentication is valid, continue to 3
   2. Authentication is not valid, log ERROR and exit: The token provided is invalid or expired.
3. JKube updates the user's .kube/config (or the one configured as environment variable KUBECONFIG -Fabric8 Kubernetes Client supports this-) with the following logic:
   1. clusters: Add/update entry with:
      • name (copy logic from oc to sanitize the name)
      • cluster.server: server URL as passed from the command-line (server property)
      • cluster.insecure-skip-tls-verify: if applicable, as passed from the command-line (kubernetes.trust.certificates property)
   2. users: Add/update entry with:
      • name: Follows pattern $username/$clusterName $username should be retrieved by getting the ~ user (see Other notes)
      • user.token: token as passed from the command-line (token property)
   3. contexts: Add/update entry with:
      • name: Follows pattern $namespace/$clusterName (namespace must be inferred, see _Current namespace computation logic`
      • context.cluster: Value used in clusters[].name
      • context.user: Value used in users[].name
      • context.namespace: Value as inferred using the Current namespace computation logic
   4. current-context: Value used in contexts[].name
4. Log INFO with message of the day (MOTD) if exists (See Other notes)

Current namespace computation logic:

The namespace/project is automatically selected, following is the logic and order of precedence (needs to match logic in oc client, spec probably needs updating):

1. Check if default exists and is accessible
2. Retrieve all user's accessible namespaces, if less than 50* use the first one.
3. Previously selected namespace (parse al .kube/config contexts and get first matching */cluster.name/user.name
4. '' blank otherwise

Other notes

• .kube/config naming convention is namespace/cluster.name/user.name
• OpenShift supports retrieving self user by getting the ~ resource from the user.openshift.io/v1/users API /apis/user.openshift.io/v1/users/~
• OpenShift supports retrieving the message of the day (MOTD) by getting the magic motd ConfigMap in the openshift namespace api/v1/namespaces/openshift/configmaps/motd
• https://github.com/openshift/oc/blob/master/pkg/cli/login/login.go
• https://github.com/openshift/oc/blob/master/pkg/cli/login/loginoptions.go
• https://github.com/openshift/oc/blob/master/pkg/cli/whoami/whoami.go

[Jurrie]

I would like to add that I use my password instead of a token when logging in from the commandline with oc. This saves me a round-trip to the web-based GUI to retrieve my token. So if this issue is about workflow speed-up / better experience, one might need to consider adding support for logging in with password also (not just logging in with token).

[manusa]

I would like to add that I use my password instead of a token when logging in from the commandline with oc. This saves me a round-trip to the web-based GUI to retrieve my token. So if this issue is about workflow speed-up / better experience, one might need to consider adding support for logging in with password also (not just logging in with token).

Right! Given the complexity of the issue/story at hand, I'd consider this as a separate issue to be completed once this one is done.