Explore: authenticating `cf-java-client`

[kieron-dev]

With the CF CLI, we found we could use pieces of client-go to authenticate exactly the same was as kubectl does.

Explore whether an analogue is possible using the cf-java-client, borrowing authentication mechanisms from the official java k8s client.

Outcomes:

• Identify the areas in the k8s java client that might be reused for k8s authentication in the cf client
• If reuse is possible, determine the mechanism for wrapping cf-java-client requests with UAA credentials, and see how this could be replaced with a k8s wrapper
• If possible, spike code using the cf-java-client to list Apps on the prototype shim, passing k8s credentials determined from the kube config by a new k8s credentials wrapper using pieces of the k8s java client.

[kieron-dev]

Getting the workstation ready, assuming we don't want this in eirini-station:

1. sudo apt get default-jdk - going for the default of java v11, as this is in LTS and things don't compile in v16, it seems...
2. sudo apt get maven
3. git clone https://github.com/cloudfoundry/cf-java-client
   • cd cf-java-client
   • gsu
   • export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
   • ./mvnw clean install -DskipTests
   • ./mvnw dependency:resolve
   • ./mvnw dependency:resolve -Dclassifier=sources
4. git clone https://github.com/kubernetes-client/java k8s-java-client
   • cd k8s-java-client
   • ./mvnw clean install -DskipTests
   • ./mvnw dependency:resolve
   • ./mvnw dependency:resolve -Dclassifier=sources

Then in nvim, :CocInstall coc-java will install a java LSP. Might be based on running eclipse in the background though! I've had better performance from using the build-in lsp: https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#java_language_server.

[kieron-dev]

Some notes on k8s java client. Importantly, pinniped is NOT supported, as it uses a client-go Exec Credentials plugin that returns a client certificate / key pair.

• We can create a KubeconfigAuthentication object. This will:
  • Get static client certificate and private key if present in the kube config
  • Get static token if present in the kube config
  • Get static basic auth if present in the kube config
  • Will get a token using the Azure, GCP or OpenIDConnect auth-provider if present in the kube config
  • Will get a token using the exec credentials plugin, if present in the kube config
    • If the plugin returns a certificate, like pinniped will, it will return null
• The constructor wires up an Authentication object which has a provide method taking the apiClient
  • If we have a token, this performs some wrapping with an interceptor
    • e.g. the TokenFileAuthentication object adds a Bearer token in an Authorization header
  • If we have a client certificate, the ClientCertificateAuthentication object sets the cert and key on the api client
• This is similar to the RoundTripper wrapping down in the client-go code
  • The key is to find out if it is compatible with the client in the cf-java-client code

[kieron-dev]

Some notes on cf-java-client.

• Configure a certain TokenProvider, and set it as the token provider for ReactorCloudFoundryClient and it will end up injected into an instance of AbstractReactorOperations. I think.
• The AbstractReactorOperations abstract class has the function that adds an Authorization header including the result of getToken() from the wired TokenProvider.
• Various concrete classes implement the TokenProvider: ClientCredentialsGrantTokenProvider, OneTimePasswordTokenProvider, PasswordGrantTokenProvider, RefreshTokenGrantTokenProvider. These all inherit from AbstractUaaTokenProvider
• AbstractUaaTokenProvider implements the code to grab the token from UAA.
• We should implement a new TokenProvider using the k8s java client to hopefully provide a token (or certificate)

[kieron-dev]

Back to the k8s client:

• Actually you just construct a KubeConfig using loadKubeConfig passing a Reader for the file content
• Find the kubeconfig by checking first $KUBECONFIG env var, and then looking in the homedir for ~/.kube/config
  • Need to copy the logic here which is implemented by private methods unfortunately
• That has methods to get:
  • inline username / password for basic auth
  • inline token
  • token from file
  • inline certificate and key
  • certificate and key from files
  • a dynamic token using auth-provider or exec credential plugin

This is used by the KubeConfigAuthentication object mentioned above, but has the benefit of not wrapping up the token up with the apiClient, meaning we can use this directly in a new cf-java-client TokenProvider.

It still has the problem mentioned above that exec credential plugins returning certificates will not be supported.

[kieron-dev]

Closing this exploration now.

Findings:

1. cf-java-client uses a mix of v2 and v3 endpoints. Our example app chose to list apps, and this uses v2 endpoints. This is not in scope currently for cf-on-k8s.
2. It is simple enough to use the official k8s java client to access the kubeconfig. See https://github.com/eirini-forks/cf-java-client/commit/90076e74cb15577e3d927e0426253af7020eafab. However, the logic of checking $KUBECONFIG, then $HOME/.kube/config, then in cluster configuration is hidden in private methods which need to be duplicated.
3. We have access to statically defined client certificates/keys and tokens, and tokens via auth-provider and exec-credential plugins. However, the k8s client does not yet support getting certificate/key from an exec-credential plugin. This is a deal-breaker for pinniped, say, which returns a certificate/key from an exec-credential plugin.
4. For the cf-java-client library to support cf-on-k8s, we would need to upgrade all relevant operations to use v3 endpoints, and look at other means to extract certificates/keys from an exec-credential plugin.