Can Jenkins utilize the user’s Kerberos ticket? – A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about Can Jenkins utilize the user’s Kerberos ticket? was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, kerberos, jenkins, , .
I’m setting up a new Jenkins server. It will authenticate users against the corporate AD. Most of the tasks we have in mind require logging-in to other hosts (via ssh).
Can Jenkins be configured to, upon a user’s login:
- Obtain a Kerberos ticket (
- Make that ticket available (as file, location set by an environment variable) to any Jenkins job run by that user — so that access to the other hosts can still be controlled via
What add-ons/plugins should I look at?
Obtaining a kerb ticket should be pretty easy since that’s essentially what the Kerberos SSO plugin does. However…
…it’s unlikely that you will be able to access the kerb ticket or user credentials from within your job in a satisfying manner.
- Firstly, it would be a huge security risk if it were possible, since if you can create a job that authenticates as an arbitrary user to a remote machine, then you can create a job that authenticates as any arbitrary user (who already has a valid kerb ticket) to a remote machine, which would potentially allow users to write custom jobs to authenticate as other users.
- Secondly, even if it is technically possible, it would not be simple. From my experience, the kerb ticket is stored locally, on the client machine used to access the web UI, not on the Jenkins server. Even if that’s not the case, Jenkins doesn’t really directly expose the profile of the user who triggered the job to the job itself. Ultimately, all Jenkins jobs are run by the Jenkins agent on the master and slave nodes. The person or agent who triggered the job is merely that – the one who triggered the job, not the one running it. You can, of course, fetch the information of the user who triggered the job, if there is one – jobs can also be triggered automatically, via cron jobs for instance. But this requires a convoluted series of API calls from within your Jenkins job definition, and I’m not even sure how to go from getting the name of the user who triggered the job to their kerb ticket. Nothing that seems remotely helpful is published by the Kerberos SSO Plugin API.
It sounds to me like you might want a plain old shell script or similar rather than a Jenkins job. I know a shell script won’t have all of the features of a Jenkins job, but if you want to run a job with the credentials of the current user, then a shell script is a much better bet.