Jenkins not finding krb5.conf file in distributed build from scripted Jenkinsfile

Question

I have a scripted Jenkinsfile running in our distributed Jenkins build environment.

I have code performing Kerberos authentication in the Jenkinsfile. That code is based on two small Java programs, both successfully authenticating to Kerberos. Those two Java programs run on both my Windows workstation and a Linux virtual machine guest.

That is: I have a pair of working Java programs that successfully perform Kerberos authentication from Windows and from Linux using a set of Kerberos config files. When I translate the code to my Jenkinsfile, it apparently fails at step 1: finding my carefully constructed krb5.conf (and login.conf) files.

The Kerberos code is in a correctly configured global shared library. I know it is correctly configured because the library is used elsewhere in my Jenkinsfile and I know it has downloaded the correct Kerberos libraries from our repository because I don't get any kind of compilation or class not found errors.

The specific error message, which I have not managed to budge over dozens of different build, trying to put the krb5.conf file everywhere I can think Jenkins might look for it, is this:

GSSException: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm)

Yes, there's a longer stack trace, but if you know what's going on, that's all you should need.

I have tried using System.setProperty() from the Jenkinsfile to point at a file which has been checked in to the project, created using Jenkins file credentials, and by using the writeFile step to write a string containing the config file directly to the build workspace. In each case, Jenkins seems to simply not find the krb5.conf file and I get the same "Cannot locate default realm" error.

It's problematic to put the file in /etc for a variety of reasons. Plus, should I really have to put the Kerberos config files there when there is a clearly elucidated algorithm for finding them, and I seem to be following it?

If you have any idea what's going on, any help would be greatly appreciated.

NB: I have successfully authenticated to Kerberos using the krb5.conf and login.conf files at issue here. They work. Kerberos and my configs don't seem to be the issue. Whatever Jenkins is or is not doing seems to be the issue.

Answer 1

Answering my own question as I did eventually find a resolution to both this and to successfully using Kerberos authentication (after a fashion) with Jenkins Pipeline in part of our build process.

Our Jenkins instance uses a number of executors in our little part of the AWS cloud. Practically speaking, the only part of our pipeline that runs on the executors is the build step: Jenkins checks out workspaces to the build nodes (the executors) and performs builds on those nodes.

Almost everything else, and explicitly everything in Jenkins' so-called global shared libraries including the Kerberos code referenced in my original question, is actually run on master: even when you wrap calls to a function in a global shared library in a node() step in your Jenkinsfile, those calls still run on master.

Because, obviously, right?

What I was trying to do is place the krb5.conf file in all the places it should be on the build nodes. But since my Kerberos code wasn't part of the build (or one of the other few steps, like sh(), that run on nodes in Jenkins), it wasn't happening on the nodes: it was happening on the Jenkins master. Even though the calls were wrapped in a node step. I'm not bitter. It's fine.

Placing the krb5.conf file in the correct location on master resolved this issue, but created other problems. Ultimately, I put the Kerberos logic into a small Java command line utility in a jar, along with the appropriate config files. That was downloaded via curl and executed, all in an sh() step in our pipeline. Not the most elegant solution, but even after discussing the issue with Cloudbees support, this was the solution they recommended for what we were trying to do.