Comments (12)
- Disable the login page from anywhere but the jumpbox
from jenkins-deploy.
@jerodweaver Would checking the user is on a particular GitHub team (in an org that enforces MFA) be acceptable for login here?
from jenkins-deploy.
@afeld Are you asking if that would meet the MFA requirement? Are you asking if you can use users/team membership within Github for authentication to Jenkins? Does Jenkins not have it's own users/roles within the application itself? Please clarify the question, and exactly what it applies to. Thanks Aidan!
from jenkins-deploy.
Are you asking if that would meet the MFA requirement?
Yep!
Are you asking if you can use users/team membership within Github for authentication to Jenkins?
Authorization, yes. Presumably we would map that team membership to a certain set of permissions / role in Jenkins.
Does Jenkins not have it's own users/roles within the application itself?
It does - I just figured it would be easier to manage membership in a single place. Also, I figured piggybacking off their MFA is easier than setting up our own.
from jenkins-deploy.
@afeld Would you be creating a new team in Github and restricting access to Jenkins based on membership to that team? or would you be essentially giving the whole team (current members) the same rights to login and operate within Jenkins? Can you give me a run down on how the process would look from your side? (for example: user navigates to url for jenkins, user is prompted for username and password, user enters Github credentials and is then prompted for MFA token, etc, etc).
from jenkins-deploy.
Would you be creating a new team in Github and restricting access to Jenkins based on membership to that team? or would you be essentially giving the whole team (current members) the same rights to login and operate within Jenkins?
The latter. I was thinking we'd give admin (or at least write) access to the d2d team, and maybe read-only access to the d2d-read-only team.
Can you give me a run down on how the process would look from your side?
I'll get a demo together
from jenkins-deploy.
From @jerodweaver:
@eyard talked with @boberlas about using Github for Jenkins and @boberlas said that is was going to need to go up to Kurt for evaluation. So once you have a writeup on how it works, if you would send it to @eyard and myself, we will review and send it on to @boberlas for review and forwarding to Kurt.
So, here we go:
GitHub OAuth proposal
We want/need to ensure our forthcoming Jenkins "master" is secure by ensuring that users can only log in with multi-factor auth. While we could probably implement this in Jenkins directly, my idea was to use single sign-on. This would provide a couple of benefits:
- We offload the complexities of authentication
- If we are managing access levels in the external service anyway, we can map those to privileges in Jenkins, meaning we have one less place to manage people.
Since Jenkins will primarily be used by technical folks, the first thing that came to mind was GitHub. Jenkins has a plugin for doing OAuth with GitHub, which would act like any other "sign in with X" you've seen across the web:
- The user visits the Jenkins URL
- They click "login"
- They are sent to the GitHub third-party auth flow
- If they aren't logged in to GitHub, they are prompted to log in.
- If they are in the 18F/GSA GitHub organizations, MFA is required on their accounts.
- If they aren't in the 18F/GSA GitHub organizations, MFA isn't enforced, but they will be blocked at a later step.
- They get the GitHub screen saying something like "[Project]'s Jenkins would like permission to access your account". This would require (at least?) the following scopes:
read:org
user:email
- If they authorize, they get redirected back to the Jenkins callback URL.
- If they aren't logged in to GitHub, they are prompted to log in.
- Jenkins exchanges the
code
for an access token. - Jenkins uses this token to check what GitHub teams the user belongs to in the organization.
- If they belong to one of the whitelisted teams, they are given access the corresponding permissions.
- If they don't belong to one of the whitelisted teams (or the organization), they are blocked.
Note that this flow is giving Jenkins access to GitHub, not the other way around.
Open questions
- What the session timeout would need to be.
Alternatives
- Keep Jenkins accessible behind the Jumpbox only, which (correct me if I'm wrong) wouldn't require Jenkins itself to have multi-factor auth
- We are planning to do this in the short term so that we aren't blocked, while we work out these other options.
- Implement MFA in Jenkins (or a proxy) directly
- Use single sign-on through a different external system. This would probably mean managing what users have what access in Jenkins directly.
- OMB MAX
- GSA SecureAuth
from jenkins-deploy.
Also, reminder that we're trying to figure out a solution that's a sensible default, which will work for more projects than just D2D.
from jenkins-deploy.
@jerodweaver If GitHub auth isn't (easily) acceptable, what would be a lower-friction choice? GSA SecureAuth? If so, how do we go about getting that set up on the GSA IT side? [Edit: nevermind, found an InSite page about it! and there's a Jenkins SAML plugin.]
from jenkins-deploy.
from jenkins-deploy.
- Add caveat to README about needing it to be in a private subnet in the meantime
from jenkins-deploy.
- Disable the login page from anywhere but the jumpbox
How can this be done?
from jenkins-deploy.
Related Issues (20)
- use Oracle Java by default HOT 5
- use HTTPS only
- distribute the builds HOT 2
- create a sample end-to-end deployment pipeline
- isolate the builds HOT 1
- support Ubuntu
- add automated tests / continuous integration
- harden nginx HOT 4
- split out an HTTPS proxy role HOT 1
- ensure that Jenkins does proper logging required by GSA HOT 6
- implement recommendations from SANS Securing Jenkins whitepaper
- discard old builds
- create a pipeline for building AMIs
- Add terraform and terragrunt HOT 1
- Instance should support changing the hostname parameter
- Conditionals needed for some commands HOT 1
- Minimum ansible version should be 2.4
- In jenkins_plugin module: Do not specify url_password in params as it may get logged
- Allow creation of tags from variables
- ensure that the global/job configuration is backed up HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jenkins-deploy.