The use case is a sudo for a dual-role user who wants to switch user accounts to perform Jenkins administrative tasks when no GitHub account is authorized as a local Jenkins admin and GitHub OAuth Plugin manages authentication (overshadowing Jenkins built-in authentication form).
More info
A power user with two roles (Jenkins admin and DevOps) wants to perform some administrative task (like adding an access token to Jenkins keyring), but none of the linked GitHub accounts (that can be authenticated by Jenkins using its GitHub OAuth Plugin) is authorized as Jenkins admin (using Matrix Authorization Strategy). Is the admin account effectively locked out, because Jenkins GitHub OAuth Plugin does not let us log in with local Jenkins admin rights? If so, then shouldn't this situation be prevented by the GitHub OAuth Plugin, ensuring that at least one GitHub user has retained Jenkins admin role?
Side note: out of all alternatives such as (over)shadowing, hiding, or obscuring, the first sounded the most exciting, but feel free to fix the term if necessary.
I managed to turn off security, i.e. escalate to admin... using Jenkins own interface. But wait, there's more: I was led there by... Jenkins' security tip.
Just go to:
https://<JENKINS_URL>/configureSecurity/
(then change Security Realm to "None" and Authorization to "Anyone can do anything").
Key take-away: never run Jenkins without proper air-gapping.
Related
We would like users to use their username/password along with another form of Multifactor Authentication, such as Google Auth (or Authy), to log into Jenkins.
We did not find any plugins that support this.
We are using AWS, so one of the things we looked at was putting an ALB in front of Jenkins and then putting, but this may interfere with getting POST requests from github to trigger builds.
Any ideas/plugins/suggestions on how to enable MFA on Jenkins?
Thanks!
I believe it is recommended to use SSO (something like SAML: https://wiki.jenkins.io/display/JENKINS/SAML+Plugin) and then as part of the SSO you can implement MFA. The problem with doing MFA directly with Jenkins is that Jenkins has pretty rudimentary user management.
Actually the authentication into our Jenkins is done through LDAP.
Some people in my team are not member of the LDAP.
Is there a way to use both LDAP and Jenkins user database?
This is not possible as described. The feature request is JENKINS-15063.
However, it is possible to approximate in a few ways (though the Jenkins user database still won't be usable).
For multiple LDAP realms you can set up a single proxy server that combines the forests.
Using PAM you can define multiple authentication sources and fallbacks in e.g. /etc/pam.d/jenkins
Yes that's possible and requires 2 steps:
Add a userNavigate to Jenkins -> Manage Jenkins -> Configure Global Security.
Under Authorization you need to configure who can do what. You can add LDAP groups and/or users and fine tune what they are allowed to do.
If you enabled Matrix-based or Project/Matrix-based authorization then you have a field to add new users/groups. You can add users that are known to LDAP or not known.
Add Credentials
If you added a user that is not known to LDAP you need to create the credentials in Jenkins (i.e. password).
Navigate to Jenkins -> Credentials -> System -> Global Credentials -> Add Credentials
Then add username and password.
I have a Gerrit instance that was setup to authenticate users over LDAP. A second team came along and can only be authenticated over a second LDAP server. IT intends on keeping the two servers separate, and as far as I can tell it is not possible to authenticate against multiple LDAP servers in Gerrit.
We have a Gitlab server internally that is able to authenticate against both groups of users, possibly by magic. I have created an Application in Gitlab as an OAuth provider so that Gerrit can authenticate against it.
Everything appeared to work- everybody is able to login successfully. However, it is a bit annoying because with each login from Gerrit, the user needs to click "Authorize". What doesn't work, however, is that the Gerrit Trigger in Jenkins could no longer post the build results to Gerrit due to a 500 error.
My questions:
- What's the best way to solve this issue?
- Is there a way to support local accounts in Gerrit, when it is configured for OAuth?
- Is there a way to skip the "Authorize" page when logging in?
Please let me know if there are important details that I left out which can help with the answer.
I had installed Jenkins in Ubuntu machine and making build successfully. I want to have authentication with help of Google apps. I feel it would be better, I searched the plugin respective to this, but i can't find it. whether this can be attained by means of plugin or otherways? Please do let me know the ways to do. Thanks in advance
Now that Google deprecated support for OpenID, you can use Google Login Plugin which works well with Google Apps.
In Jenkins by default user authentication is not enabled but we can establish the user authentication from the Global Security section. We have to create users for team members and it maintains all user in its own database. But we can also configure Jenkins with Google OAuth. So, if you are leveraging Google services and already have users on it. The users can login to Jenkins and perform their task.
To implement Google OAuth we'll recommend jenkinsci/google-login-plugin (https://github.com/jenkinsci/google-login-plugin) this is a Jenkins plugin which lets you login to Jenkins with your Google account. Also allows you to restrict access to accounts in a given Google Apps domain.
I am assuming that we have already installed Jenkins server and have admin right to make changes in it. The whole configuration is divided into three easy steps.
1. Get Google OAuth Credentials
To use this plugin, you must obtain OAuth 2.0 credentials from the Google Developers Console (https://console.developers.google.com). These don't need to belong to a special account, or even one associated with the domain you want to restrict logins to.
Instructions to create the Client ID and Secret:
Login to the Google Developers Console
Create a new project, in the pop-up window specify your project
name it can be any name which is more meaning full to you, eg:
Jenkins OAuth. In this project we will generate authantication
credentials to enable OAuth API.
On the left sidebar under APIs & Services (API Manager) ->
Credentials, Create credentials, OAuth client ID (It will genrate API
credentials and these credentails are required to configure in
Jenkins in last step).
As we are going to integrate this in Jenkins and it is a web
service, the application type should be "Web Application"
Register Jenkins URI from where we allowed to access the Google
APIs. We have to provide Jenkins server detail. You can replace your
JENKINS_ROOT_URL = http:jenkins.mydomain.com with your own Jenkins URI. This will be the landing page of your Jenkins server.
Once you hit this page it will be redirected to google for the
authentication.
The authorized redirect URIs is required to redirect you after
successful login. It is the combination of your Jenkins landing page
and a suffix string to validate you are a logged in user. As we want
to land user to Jenkins dashboard, so it has the same URI which we
mentioned in the previous step and don’t forget to include
securityRealm/finishLogin at the end. So the authorized redirect
URLs should result like this
${JENKINS_ROOT_URL}/securityRealm/finishLogin.
eg: http://jenkins.mydoamin.com/securityRealm/finishLogin
Copy and save Client ID and Client Secret, these credential
will be used to enable Google APIs in Jenkins (Security Realm
Configuration).
2. Install Google Login Plugin
In Jenkins there is no mechanism to configure OAuth but there are many plugins are available and we are using Google Login plugin. We can easily install this plugin from Manage Jenkins –> Manage Plugins –> Available and search for “Google Login”. Select the plugin. There is no need to restart to install this plugin. This plugin allows for the register Google OAuth and performs authentication.
3. Configure Jenkins
In this step, we will setup Google security credentials in installed plugin. Navigate to Manage Jenkins –> Configure Global Security and select Login with Google under Security Realm paste credentials (Client ID and secret) generated in the first step. In the last field do not forget to enter your domain name it allows you to restrict access to given domain name.
Immediately after saving changes Jenkins will allow access to all users in your domain. Now, try to login into your Jenkins it will redirect you to Google Authentication page. If everything is set up properly you will be logged in but just in case you’re still facing any problem go back and check each step. The logged in user can do anything and if you want to restrict users you can implement Role Strategy Plugin (https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin) security.
You can achieve Single Sign On with Google Apps using the OpenID Plugin. It's very easy to set up, you basically install the plugin, select "Google Apps SSO (with OpenID)" and enter your domain. Note that users will have to have a google apps account to login after that.
Tip: you might consider using it in combination with the Role Strategy Plugin
I used a command line browser called elinks to sign in to their html mail server http://m.gmail.com.
Use shift in Elinks to copy and paste.
http://minimallinux.blogspot.com/2012/07/centos-6rhel-install-elinks-text-browser.html
I switched a text message script from one jenkins box to another and had to do this to get Google to let me use that IP.
Goal:
I want do write an application that can trigger Jenkins jobs and itself also authenticates users against the Crowd server. The users must be in a separate crowd group to be authorized to act on Jenkins.
Setup:
I am using the Crowd2 plugin to authenticate Jenkins users against an Atlassian Crowd 2.1 server.
My thoughts:
Now, Jenkins has two types of remote execution:
Jenkins REST API (uses a per-user Token for authentication)
A build can be triggered through this call using a "TOKEN" in a way like this:
JENKINS_URL/job/JOBNAME/build?token=TOKEN
Jenkins CLI (uses an SSH key for authentication)
A build can be triggered through an command line tool using the SSH private key to authenticate the user.
The token-approach (REST API)...
... requires my application to know the API token.
How could I bypass the API token limitation?
Storing the API token within Crowd?
The Crowd2 Jenkins plugin could store the Jenkins API token as an crowd attribute (user-defined properties which can be stored within the crowd user directory), is one way. Even though I think this could be a security flaw, as the attribute might be retrieved from all other applications registered at Crowd (which would enable them to execute Jenkins jobs on the users behalf).
Q: Good approach and secure enough? In my opinion, this is not secure enough.
Authenticating with my applications crowd token against Jenkins?
I've also tried generating a crowd-token through Crowd's API and then requesting the Jenkins REST API with that token as Cookie in the hope that the Jenkins crowd2 plugin validates the passed Crowd token against Crowd. But it does not work (when using the crowd token from my browser, by examining the page information in Firefox, it works, of course).
I am not sure if this approach (if the crowd2 plugin would check the passed token) has security flaws in it and if the crowd-token mechanism is designed to work in that way. I am sure though, that it might negatively affect Jenkins' performance as every API request has to check if the token is valid.
Q: Good approach and possible?
The CLI-approach...
...requires my application to know a SSH private key registered at Jenkins.
It would be good approach, if Jenkins would support adding SSH Keys. My application could generate a SSH key pair (with random) password and automatically store the public key on the users behalf within Jenkins.
I think this is the right way, even though it requires to extend Jenkins and maybe the authentication plugins.
Q: Is this approach possible and secure enough?
Q: Are there other approaches?
I think Jenkins should implement an OAuth endpoint for authorization (in case of the crowd plugin, it then has to delegate the authorization to Crowd) or completely detach user management from its core. Am I wrong?
Please help me improving this question, if neccessary. I can imagine that I've mixed two problems and didn't described by goal clear enough.
Note: Edited this question ~1 hr after creation (see my 1st comment).