Connections should require some form of authentication about cryostat

[andrewazores]

https://docs.openshift.com/container-platform/4.1/authentication/configuring-internal-oauth.html

openshift/origin#3945

https://docs.openshift.com/enterprise/3.1/architecture/additional_concepts/authentication.html

https://docs.openshift.com/container-platform/3.5/rest_api/index.html

Last two links are for 3.x but general overview still seems accurate.

[andrewazores]

Using CRC as a test installation, a CLI client (ex curl) can gain an access token like so:

curl -k -I
  -H "X-CSRF-Token: 1"
  -H "Authorization: Basic $B64"
  "https://oauth-openshift.apps-crc.testing/oauth/authorize?client_id=openshift-challenging-client&
response_type=token"

where B64 is the base64 encoded string of username:password of the user's login credentials. The request URL host comes from oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host.

The response comes with an empty body and headers like this:

HTTP/1.1 302 Found
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: 0
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_token=TOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer
Pragma: no-cache
Pragma: no-cache
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Dns-Prefetch-Control: off
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
Date: Tue, 10 Dec 2019 21:26:52 GMT

Notably, the status of 302 indicates a success (401 if the bad credentials were given, some other code and response body describing if the request was invalid), and the token is available to be parsed from the Location header value under the implicit token parameter.

This token can then be reused for OpenShift API access. Example:

curl -k -v
  -H "Authorization: Bearer TOKEN"
  https://api.apps-crc.testing:6443/api

If this fails (ex. no or bad token supplied), it responds with a 403 status and a JSON response body explaining the failure. If it succeeds then it's a 200 and a response body with some information about the cluster API. There's probably some better way to validate tokens directly, but response codes on this endpoint might suffice.

[andrewazores]

There is also a graphical way to request a token via browser, by visiting the url https://oauth-openshift.apps-crc.testing/oauth/token/request. This brings the user to the cluster's OAuth login page. If they pass the credential challenge they are redirected back to a page that allows them to view their newly granted access token. Maybe there is a parameter that can be used to redirect from this OAuth challenge back to our application and supply the token?

[andrewazores]

I've hacked up a quick prototype for container-jfr to add platform-specific auth managers, and a corresponding KubeApi one (which is active when running in OpenShift/CRC). The current roadblock is that 1) the container-jfr serviceaccount does not have the permissions to list services in arbitrary namespaces (like openshift-authentication) 2) kubernetes-client has no concept of OpenShift Routes, so even once that namespace and route can be discovered, some work needs to be done to figure out how to parse out the route URL from there. https://github.com/openshift/openshift-restclient-java might be useful, even though it says it's for OpenShift 3.

[andrewazores]

Probably a better client: https://github.com/fabric8io/kubernetes-client

[andrewazores]

We also have environment variables which indirectly tell us our own cluster URL (ex. CONTAINER_JFR_LISTEN_HOST), so if we assume the oauth route exists, we can prepend it as a subdomain to the cluster domain parsed out of the env var. This is probably less fragile than it sounds.

[andrewazores]

Oh and of course, there are also the environment variables like KUBERNETES_SERVICE_HOST. However, in practice with CRC, this is set to an IP address, so the /api endpoint should be available there, but perhaps not /oauth?