Stops display of the token if not JWT and if Openshift cluster fetches the username from the master API

[phantomjinx]

Asks the Openshift cluster for the username associated with the given token.

If using form-login and connecting to Openshift, it is possible to obtain the username associated with the login token using the OS REST API.

Adds a small function to the form-service.ts that fetches the username upon successful login.

[phantomjinx]

Was experimenting with the cluster REST API and tried this out. Seems to work correctly but will probably need tidying up if we want to include it. Anyway, post what you think of it.

[tadayosi]

The username resolution logic looks good, but there are other comments that need to be addressed.

[tadayosi]

And while it's fine to support such case, it's important that it's just an edge case and should never impede the normal case with K8s and serviceaccount token by adding extra load.

[phantomjinx]

And while it's fine to support such case, it's important that it's just an edge case and should never impede the normal case with K8s and serviceaccount token by adding extra load.

Despite attempts to avoid an enquiry of the API Server to determine if it belongs to an OpenShift cluster, I have found no other way to get that result. The form config makes no mention of the type of cluster (we could include it but then it is dependent on the user correctly supplying it).

So the latest version:

• no longer displays the token as the subject;
• Evaluates the response of the base /api to determine if it contains the core OpenShift groups;
• Only in the event that the cluster is OpenShift will it then enquire as to the username.

[tadayosi]

@phantomjinx

Despite attempts to avoid an enquiry of the API Server to determine if it belongs to an OpenShift cluster, I have found no other way to get that result. The form config makes no mention of the type of cluster (we could include it but then it is dependent on the user correctly supplying it).

Just an idea to explore: What about using local storage and cache the result on whether it's OCP or K8s there? The reasoning is that local storage is tied to a hostname and it's highly unlikely that the same hostname changes the type of cluster. If the result is cached, we only need to inquire once. If a similar inquiry has been done in other places in hawtio-online, we might also be able to use the cached result to remove extra burden on API server further.

[tadayosi]

Yet another option might be that the nginx server holds the result of the inquiry [1] somewhere on the server in some way and provides an extra endpoint like /cluster-type which returns whether it's on OCP or K8s. That way we only need to inquire to the nginx server but not to the API server.

[1]

hawtio-online/docker/nginx.sh

Lines 18 to 31 in 79baa70

	check_openshift_api() {
	APISERVER="https://${CLUSTER_MASTER:-kubernetes.default.svc}"
	SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
	TOKEN=$(cat ${SERVICEACCOUNT}/token)
	CACERT=${SERVICEACCOUNT}/ca.crt
	STATUS_CODE=$(curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/apis/apps.openshift.io/v1 --write-out '%{http_code}' --silent --output /dev/null)
	if [ "${STATUS_CODE}" != "200" ]; then
	OPENSHIFT=false
	fi
	echo OpenShift API: ${OPENSHIFT} - ${STATUS_CODE} ${APISERVER}/apis/apps.openshift.io/v1
	}
	check_openshift_api

[phantomjinx]

Went with the second approach, ie. injecting the flag from the server by adding it to osconsole/config.json.