Obvious authn-k8s token question

[leighcee]

Hi,

I’ve got a question which might seem obvious, but I cannot get my Kubernetes Authenticator Client to work as a sidecar with conjur-oss on GKE so I don’t know the answer.

I have conjur-oss working outside of Kubernetes with docker-compose and use the Java API to retrieve secrets. The Conjur object is initialised using:
c = new Conjur (user, API-KEY)

All works well. Looking at the code, the authentication token is retrieved and automatically reloaded every 6 minutes by the Conjur API so that it always remains valid for subsequent calls to retrieve secrets. My Conjur object never needs to be re-initialised.

Moving to k8s, the sidecar client requests a token every 6 minutes and this is written to a volume which is shared with my app. My app reads this from the volume and calls:
c = new Conjur (token)

The question is, do I need to re-initialise my Conjur object before every call to retrieve secrets as the token will be rejected as invalid/out of date by the Conjur server after around 8 minutes?

Like I say, seems obvious but I have not see example Java API code which clarifies this.

Thanks,
Lee

[sgnn7 (Srdjan Grubor)]

do I need to re-initialise my Conjur object before every call to retrieve secrets as the token will be rejected as invalid/out of date by the Conjur server after around 8 minutes?

Yes, your hunch is correct. if you’re manually doing the secret fetch with the authnenticator-provided token value, you have to use whatever the current state of the token is so you should read the file and initialize Conjur() at the point(s) that you use them. The main reason why this isn’t too obvious in the docs is that usually credentials are either fetched during that initial stage only once or used with something like secretless-broker that reads that token just-in-time. I guess we could add a constructor that takes a token path instead of the raw token value as well but that will probably make the Conjur class itself decently more fragile.

Srdjan

[leighcee]

Wonderful, thanks @sgnn7 for the clarification!