3

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:

  1. Obtain a Kerberos ticket (kinit).
  2. 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 .k5users/.k5login.

What add-ons/plugins should I look at?

2
  • As far as I know the typical Kerberos plugins for Jenkins (and many other web applications as) only provide Single Sign On and authentication in the web front-end and won't provide Kerberos functionality for use in your r pipe-lines and jobs as the Kerberos ticket the Jenkins front-end will see will only be valid for authenticating to the Jenkins host. I think there are three problems you would need to solve:
    – HBruijn
    Apr 8 '19 at 6:24
  • the easier one to solve would be to ensure that you get Jenkins to request a ticket that has the forwardable and renewable flags set , then include that ticket in the pipeline, ensure renewal and finally even renewable tickets will still expire and break authentication in your pipe-line... That would at first glance appear a bit fragile.
    – HBruijn
    Apr 8 '19 at 6:30
1
  1. Obtaining a kerb ticket should be pretty easy since that's essentially what the Kerberos SSO plugin does. However...

  2. ...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.

1
  • I thought of using Jenkins credentials' store -- and limiting access to other people's tickets that way. However, it is not much of a concern anyway in our peculiar case... Lastly Kerberos SSO plugin is not a requirement - we could just use AD directly...
    – Mikhail T.
    Apr 10 '19 at 3:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.