I am looking in to developing Conjur Spring Cloud integration plugin. As part of this plugin I want to implement authn-k8s functionality in to Spring Cloud integration plugin. Idea behind such a plugin is that developers who are developing micro service can just include Spring Cloud plugin in to their dependency add configuration to their Spring configuration and then deploy it. No external dependency of sidecar authn-k8s resulting in frictionless integration for the Java developer community.
To that effect I was looking for authn-k8s implementation details on GITHub and I could not find any document detailing Certificate Signing Request and the API calls used by authn-k8s client for authentication.
Can you share these details?
Hello @subodh!
We weren’t adding design docs to github at the time we built this integration, but I did take some time today to add one of the original design docs to our github and update it with some of the details of the current implementation. You can find that doc here. There’s also a high level design doc for our authenticator pattern in the Conjur repo, but I suspect the design in the authn-k8s client repo would be much more useful to you.
The key logic in our Golang-based authenticator client is here - it gives the implementation for sending a Login request (to the inject_client_cert API route) and for sending an Authenticate request to the authn-k8s authenticate API route.
Our logic in the Go-based client is a little complicated, because it includes:
- automatic exponential-backoff retries built in to deal with any potential network flakiness
- automatic access token refresh at regular intervals before each token expires
- automatic kickoff of a new Login process once the signed certificate expires and the client needs to send a new CSR before attempting to authenticate again
If there are alternatives to building a duplicate client implementation for this, I think it would be worth exploring. For example, would it be helpful if we released the standalone go binary instead of just the Docker image, or explored running the go client as a service in Spring cloud (maybe as described in this blog post)? If any of those sound interesting to you, then we’d be glad to discuss them further.
Whatever path you choose, please feel free to get back in touch if you have more questions!
Geri