ensure users can only log in with multi-factor auth

[afeld]

• https://plugins.jenkins.io/github-oauth
• https://wiki.jenkins-ci.org/display/JENKINS/Matrix-based+security
• https://plugins.jenkins.io/role-strategy

Likely makes sense to address authorization as a separate issue.

[afeld]

• [ ] Disable the login page from anywhere but the jumpbox

[afeld]

@jerodweaver Would checking the user is on a particular GitHub team (in an org that enforces MFA) be acceptable for login here?

[jerodweaver]

@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!

[afeld]

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.

[jerodweaver]

@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).

[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?

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 😁 Should be fairly easy to set up.

[afeld]

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:

1. The user visits the Jenkins URL
2. They click "login"
3. They are sent to the GitHub third-party auth flow
   1. 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.
   2. 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
   3. If they authorize, they get redirected back to the Jenkins callback URL.
4. Jenkins exchanges the code for an access token.
5. 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

[afeld]

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.

[afeld]

@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.]

[afeld]

@maverickquant ^

[afeld]

• [ ] Add caveat to README about needing it to be in a private subnet in the meantime

[anazlateva]

• [ ] Disable the login page from anywhere but the jumpbox

How can this be done?