Certificate authority is always expected about jenkins-client-plugin HOT 14 CLOSED

Setting the CA as part of the cluster configuration doesn't seem that unreasonable to me (presumably you have to do other cluster configuration anyway), though the ability to use the default CA baked into a slave image makes sense.

from jenkins-client-plugin.

Currently, yes, i need to create a cluster configuration, but if i could disable the plugin adding the certificate-authority onto the command line, i could just do the below, and it would work, because the cluster2 is already trusted by the jenkins slave:

stages {
    stage ('Do something') {
        steps {
            script {
                openshift.withCluster("https://cluster2.corp:8443") {
                    openshift.withProject("test") {
                        //do something within project
                    }   
                }
            }
        }
    }
}

But because there is no cluster configuration, and the above is running in cluster1, the plugin try's to connect to cluster2 with cluster1s certificate-authority.

from jenkins-client-plugin.

@garethahealy - remind me, if the CA is already baked in, does Java store it in a well known location of the file system, or does some env var need to be set?

If so, then when a URL is the value passed into withCluster, we could just determine if the CA is baked in. If so, avoid setting the oc option.

I'm also wondering if defaulting to the pod cert when an arbitrary URL is passed in makes sense. It is sort of a last ditch effort / assumption that the mounted cert would work. Perhaps we should default to skip tls verify, and if a user wants full SSL, create an appropriate jenkins cluster config, etc.

@bparees @jim-minter @coreydaley any thoughts there?

from jenkins-client-plugin.

Perhaps we should default to skip tls verify

we should never do that :)

As to whether we should be defaulting to the mounted pod cert(as we currently do), or just hoping/assuming the system certs in the image will suffice, I can see arguments for both. Allowing the user to explicitly indicate they want to use the image's system certs (ie they do not want the plugin to add a --certificate-authority flag to the oc command) seems reasonable to me, I think that's what's being asked for here.

from jenkins-client-plugin.

Yeah it is just what to do when they do NOT specify that they want to use the image's certs. As you said, and as to what lead to me originally bringing it up, there are arguments both ways.

from jenkins-client-plugin.

Yeah it is just what to do when they do NOT specify that they want to use the image's certs.

since we've already established that if they don't specify anything, they get the mounted pod certs, i don't think we can change that (it could break people in unexpected ways), so i think the only path forward is to allow users to explicitly request that we do not use the mounted pod certs (so that oc falls back to the system certs)

from jenkins-client-plugin.

btw i don't think java is involved, this is all about what ca certs the oc client binary is going to use (either the ones provided as an arg to oc by the plugin, or the system defaults)

from jenkins-client-plugin.

from jenkins-client-plugin.

As @bparees has said, the certs are added at OS level via update-ca-trust

from jenkins-client-plugin.

ok thanks - I believe I've connected the dots

so, how to expose this option to the user via the client plugin surgary dsl syntax (that has been giving me a fair amount of heartburn this week ;-) ) ?

Any opinions folks?

Both withCredentials (formerly doAs) and withCluster have credentialIds ... do we just add a ignoreMountedCerts flag on those?

from jenkins-client-plugin.

Both withCredentials (formerly doAs) and withCluster have credentialIds ... do we just add a ignoreMountedCerts flag on those?

sounds right to me. I was thinking "useSystemCerts" but we don't have to debate the name extensively.

from jenkins-client-plugin.

Another Red Hatter here at a customer. This is also a problem for us and the use case we have is for an external Jenkins talking to an openshift cluster and the Jenkins host OS trust store (/etc/pki/ca-trust/source/anchors/) needs to be used for tls purposes. The default (/var/run/secrets/kubernetes.io/serviceaccount/ca.crt) makes no sense when jenkins is not running on openshift. A flag might not be needed if a reliable check can be done to see if jenkins is running on openshift or not, but we could work with a useSystemCerts flag as well.

from jenkins-client-plugin.

For now opened https://trello.com/c/6AlVfZ2X/1511-2-allow-use-system-certs-ignore-mounted-certs-for-client-plugin-pipelineintegration

Before following the process and closing this out in favor of the card, I'll double check with @bparees - do we still want to consider this as an enhancement, or instead pivot and consider it a "shortcoming bordering on problem that needs to be fixed"

from jenkins-client-plugin.

it's an RFE. Especially since there appear to be valid workarounds (use a cluster configuration to set the cert to use)

from jenkins-client-plugin.