Externalize the CERT_FILE = "/run/secrets/kubernetes.io/serviceaccount/ca.crt"; about jenkins-plugin HOT 7 CLOSED

Per https://github.com/openshift/jenkins-plugin#certificates-and-encryption you should already be able to put the contents of your x509 PEM files in CA_CERT env var / build parameter. This will override what is read in from "/run/secrets/kubernetes.io/serviceaccount/ca.crt".

Please try that. If there are issues in doing that we can reopen this issue and diagnose.

thanks

from jenkins-plugin.

@gabemontero Gabe - Yes process outlined in your document works for us. The concern is that the certs have a shelf life and the preference is use the linux managed certificates (example - /etc/pki/tls/certs/ca-bundle.crt). The linux managed certificates renewal is managed by the OS

from jenkins-plugin.

ah - yeah, OK that makes sense @dnguyen9

There are a couple of ways to go about it. A new env var along the same lines as CA_CERT is quick and easy enough.

We've also got requirements on the back burner to leverage the jenkins credentials support. I think you can point those to specific cert files.

The other point to mention is that we have started putting more focus on the plugin at https://github.com/openshift/jenkins-client-plugin
Among other things, it already allows for integration with jenkins credentials. Have you looked at that / would that one work for you as well?

@bparees FYI ... also, thoughts on the quick/easy CA_CERT_FILE tweak?

from jenkins-plugin.

@gabemontero you're proposing we would have a hierarchy of:

1. if $CA_CERT is set, use that
2. if $CA_CERT_FILE is set, use the file at that location
3. if none of the above, use the file at the CERT_FILE constant path (/run/secrets/....)

?

from jenkins-plugin.

from jenkins-plugin.

if it works for @dnguyen9 i'm ok with it. Agree the precedence could go either way, I guess I don't have a strong opinion.

from jenkins-plugin.

That works for me! Not strong preference either way.

from jenkins-plugin.