Mechanism to get user token about jenkins-client-plugin HOT 12 CLOSED

@paterczm

We have the same policy. Service accounts are not permitted, only ldap managed user accounts.
Therefore I also need a user/password authentication.

from jenkins-client-plugin.

Yep, a use case of note @garethahealy , even if it is not our "primary" one at this time. It also has commonality with openshift/jenkins-openshift-login-plugin#28 which was opened over the holidays.

There are a couple of ways to go about this:

1. we just exposed in our centos image a functional openshift secret to jenkins credential mapping capability; you label secrets in any of the projects our openshift sync plugin is configured to monitor, and a jenkins credential is created; it will be part of the 3.9 openshift jenkins rhel image; this plugin is able to consume jenkins credentials (https://github.com/openshift/jenkins-client-plugin#setting-up-credentials); without knowing exactly how the customer is handling authentication into their cluster, it seems at least feasible that capturing that in openshift secrets, etc. etc. is a viable option

2. Or yep, this plugin will currently default to the jenkins service account of the pod running jenkins in absence of credential/cluster directive... we could explore some first class method / means of altering that and then do the oc login, etc. under the covers as you describe.

At first blush I'm in more favor of options 1), but will profess I've just started considering this and may be blind to something.

Certainly chime in with any additional thoughts you may have @garethahealy - thanks!!

Otherwise, per our process, I'm going to close this out in favor of a trello card, so that this can get prioritized and funneled through any needed architectural discussions.

from jenkins-client-plugin.

It seems slightly odd that you have the user's password(params.SYSTEM_ACCOUNT_PASSWORD) available, but can't just have them provide a token directly instead? Is the concern that tokens expire so the user would have to periodically provide a new token? (service account tokens do not expire, of course, or at least not for long durations, so if you're doing this with service accounts, or could, that would not be a problem).

from jenkins-client-plugin.

@bparees - that question addressed to @garethahealy, right ? Just in case, SYSTEM_ACCOUNT_PASSWORD, etc. is not something provided by this plugin, nor is it something mounted in the pod. It must have been a param that was part of @garethahealy 's jenkins job.

And yeah, service account secrets were part of what I was thinking in my 1) option previously (along with user credentials if that was a must); I just failed to explicitly cite them.

from jenkins-client-plugin.

I'll defer on opening a card in case SAs, etc. and 1) pan out.

from jenkins-client-plugin.

@bparees - that question addressed to @garethahealy, right ?

right. I just meant the job has been setup w/ a user-supplied parameter named "password" so why not just change it to "token" and skip the login/extract token step is my suggestion/question.

from jenkins-client-plugin.

Hello! I'm also interested in this functionality, but would prefer not to use service accounts. Reasons:

1. I think using actual user account is more secure, because it ties job execution to a person and that person's access defined in OpenShift (so Jenkins job inherits OpenShift permissions from the person who runs it).
2. Assuming user accounts in OpenShift are already properly configured, managing service accounts to be used by Jenkins jobs seems like an unnecessary administration overhead.

Note: In my use case, there is a standalone Jenkins instance which interacts with more than one OpenShift cluster. This is because we have separate prod and pre-prod OpenShift environments.

from jenkins-client-plugin.

@bparees we get the username/password via the params, as this jenkins job is called from another tool. That tool aims to make it easy for people to use, so asking a user to provide their token before hand is regarded as "complicated" - some users have very basic OCP knowledge.

The customer i am with also associates a valid LDAP user with each project, they call these users "service accounts". That user is the preferred way for any APIs to interact with OCP, instead of using OCP service account tokens.

from jenkins-client-plugin.

This could be solved if the plugin supported kubernetes-credentials-plugin, but that currently requires Java8, where as the plugin is at 7.

• https://github.com/jenkinsci/kubernetes-credentials-plugin/blob/master/src/main/java/org/jenkinsci/plugins/kubernetes/credentials/OpenShiftBearerTokenCredentialImpl.java

from jenkins-client-plugin.

Sorry, this one slipped though the cracks a bit.

First, yes @garethahealy , if you look at https://github.com/openshift/jenkins-client-plugin/blob/master/src/main/java/com/openshift/jenkins/plugins/OpenShiftTokenCredentials.java#L9 , lining up kubernetes-credential (which the kubernetes-plugin uses) is a known to-do.

That said, there is another path (with less change), and leads to one more item of follow up, after looking at this again with a fresh set of eyes. Around the time or soon after this item was opened, the withCredentials step was added (a rework of the doAs method).

We didn't discuss this previously.

This method allows passing in the ID of a jenkins credential, where that credential contains the authentication information for the user.

Technically, the credential ID passed in does not have to correspond to an OpenShift service account. It can be any user.

But this plugin currently supports tokens for users, not usernames and passwords for users.

So to confirm, everyone's requirement centers around their using authentication mechanisms, or having company specific guidelines perhaps, where they can ONLY supply the username and password for a user, not the token assigned to that same user (re: the LDAP note from @ramato-procon )? If so, we could just add a new username/password credential type and go from there.

Or is there more nuance than that?

Back to your original description for example @garethahealy , with your asking about an oc whoami equivalent, I could see you perhaps creating

• different jenkins credentials with the token for the various users specified by params.SYSTEM_ACCOUNT_NAME
• have the components which set params.SYSTEM_ACCOUNT_NAME on the job today simply set it to the corresponding jenkins credentials id
• use withCredentials

Or was there something besides the token vs. username/password distinction that prevented you doing that?

Anyway, thanks for any feedback, and again, sorry for the delay.

from jenkins-client-plugin.

@gabemontero ; yes, i'd had a look at withCredentials, which is what led to the kubernetes-creds-plugin while looking at:

• https://github.com/openshift/jenkins-client-plugin/blob/master/src/main/resources/com/openshift/jenkins/plugins/OpenShiftDSL.groovy#L135-L142

No, i think you've understand it. The customer wants to be able to use a stored token (as-is now) or a username/password credential.

from jenkins-client-plugin.

OK thanks for the confirmation @garethahealy

Upon reviewing existing req's, I think this is then covered by https://trello.com/c/rum3SCfs/1538-follow-k8s-plugin-lead-switch-to-plain-credentials-plugin-for-all-our-plugins-jenkinsintegration

Per our process, closing this issue with that card.

Adding this issue to that card for reference.

from jenkins-client-plugin.