Externalize the CERT_FILE = "/run/secrets/kubernetes.io/serviceaccount/ca.crt";

[dnguyen9]

there are potential needs to use the jenkins-agent from one openshift cluster to talk to another cluster. Given that the ca.crt is generated defined by the CERT_FILE is generated as self-signed certificate, you would expect to see TLS errors unless you use the SKIP_TLS.

we would like to have the ability to specify the ability to certify the CERT_FILE as an environmental variable to specify our own x509 PEM files.

in the source code: private static final String CERT_FILE = "/run/secrets/kubernetes.io/serviceaccount/ca.crt";

[gabemontero]

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

[dnguyen9]

@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

[gabemontero]

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?

[bparees]

@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/....)

?

[gabemontero]

On Tue, Aug 22, 2017 at 5:08 PM, Ben Parees notifications@github.com wrote:

@gabemontero https://github.com/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/....)

?

yep .... could argue the new var, 2), takes precedence over 1), or argue 1, 2 is the right precedence, but yep

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openshift/jenkins-plugin/issues/151#issuecomment-324152170, or mute the thread https://github.com/notifications/unsubscribe-auth/ADbadO4EbEbhR3NEhyylz8flMU1ionDPks5sa0M6gaJpZM4O_App .

[bparees]

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.

[dnguyen9]

That works for me! Not strong preference either way.