[Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

I've been hammering my head against the problem of registering and
authenticating Jenkins Essentials instances all week (and boy does my head
hurt!) but now, after 6pm on Friday evening, do I feel like I have a
design/concept worth soliciting feedback on.

Since there's so much context and detail necessary, I went ahead and wrote the
majority of the JEP document here:
https://github.com/rtyler/jep/tree/essentials-registration/jep/0000


I'm not sure how familiar this topic area is to many Jenkins contributors, so
I'm also asking for feedback off-list from colleagues of mine from previous
jobs where we built similar systems with similar requirements. If you have
similarly skilled colleagues or security professionals you work with, I would
appreciate you asking for their thoughts if they have the time as well.


The local prototype code I have for this is so gnarly and embarrassing that I'm
not going to show you all just yet :) But suffice it to say, the approach
generally works, just needs more tests ;)



Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Jesse Glick]

Jenkins already includes the `instance-identity` module, which is the
standard mechanism¹ for both uniquely identifying a Jenkins
installation, and permitting asymmetrically-encrypted communications
with it. Is there a reason you are not using it? If so, that should be
clearly documented under “Alternative Approaches”. There is a vague
mention of OpenSSH keys, but this module is not limited to SSH (much
less OpenSSH), and public-key encryption has widespread library
support.


¹ https://wiki.jenkins.io/display/JENKINS/Instance+Identity

[R. Tyler Croy]

(replies inline)

On Mon, 26 Mar 2018, Jesse Glick wrote:

> Jenkins already includes the `instance-identity` module, which is the
> standard mechanism¹ for both uniquely identifying a Jenkins
> installation, and permitting asymmetrically-encrypted communications
> with it. Is there a reason you are not using it? If so, that should be

> clearly documented under ???Alternative Approaches???. There is a vague

> mention of OpenSSH keys, but this module is not limited to SSH (much
> less OpenSSH), and public-key encryption has widespread library
> support.

Thanks for taking a look Jesse! You're right that Jenkins already does have an
instance identity floating around. In a much earlier iteration of my thinking I was
considering using this until I started to think about how this would work in
practice for new installations.

Unfortunately when the jenkins/evergreen image comes online and checks for
updates, it will not have run `jenkins.war` at all yet, and therefore no
instance identity. Rather than have one unprotected/identified route in the
service backend for bootstrapping new nodes, I am erring on the side of
treating all "got updates?" requests the same, which requires a client
registration and identity to kick the process off.

You're absolutely right that the 'Alternative Approaches" section doesn't list
this and should, I'll update shortly.

[Baptiste Mathus]

(Adding in CC Emmanuel Lécharny, who took a look at the proposal)

Trying to summarize our chat on Twitter, I see two outstanding points:

* Emmanuel is rightly questioning/concerned about the potential of DDoS for this JEP. 

Tyler, should we add something about this in the JEP, or do you consider it more something to be addressed in an IEP on the infra side? 

(also, downstream to it AIUI, the Telemetry and other services are all DDoS vectors)

* "MITM for expiry": it seems possible to reuse an UUID signed with the PK.

"Ideally, to renew the token, you should have a 'nonce' to avoid MITM"

@Emmanuel thanks again. If you have any other feedback, feel free to enrich or correct what I wrote you said :).

Thanks everyone!

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180326153407.5on7xn7gdl7odfue%40blackberry.coupleofllamas.com.

For more options, visit https://groups.google.com/d/optout.

[Baptiste Mathus]

Replying just to get Emmanuel's answer's in. I just remembered we are now requiring being subscribed and approved with all the spam attacks we had. See below.

2018-03-27 9:44 GMT+02:00 Emmanuel Lécharny <elec...@gmail.com>:

I want to add that if you want to eliminate the possibility of a MITM,
you will most certainly require a TLS connection to be established at
some point.

But then that means the server will issue some keys based on a
certificate. At that point, I would rather decide to make the server to
know about the clients (and that would require some registration), and
validate those clients based on a certificate signed by the server. If
so, you are back to a standard PKI.

There is no magic bullet...


Le 27/03/2018 à 09:24, Baptiste Mathus a écrit :
> (Adding in CC Emmanuel Lécharny <http://people.apache.org/~elecharny/>, who

--
Emmanuel Lecharny

Symas.com
directory.apache.org

[R. Tyler Croy]

(replies inline)

On Tue, 27 Mar 2018, Baptiste Mathus wrote:

> (Adding in CC Emmanuel Lécharny <http://people.apache.org/~elecharny/>, who

> took a look at the proposal)
>
> Trying to summarize our chat on Twitter, I see two outstanding points:
>
> * Emmanuel is rightly questioning/concerned about the potential of DDoS for
> this JEP.
> Tyler, should we add something about this in the JEP, or do you consider it
> more something to be addressed in an IEP on the infra side?
> (also, downstream to it AIUI, the Telemetry and other services are all DDoS
> vectors)

I consider the discussion about rate limiting (for example) to be the future of
the deployment aspect of these services as well, but guess who will be writing
the IEP! :)

Concerns about a DDoS as they might apply to the client/service interaction are
definitely worth discussing in relation to the JEP. However, based on what I
interpret is Emmanuel's feedback, it's not the interactions necessarily but
rather a "good infra hygiene" concern which I understand.

> * "MITM for expiry": it seems possible to reuse an UUID signed with the PK.
> "Ideally, to renew the token, you should have a 'nonce' to avoid MITM"

This feedback I'm not sure I understand. The UUID and public key are only ever
exchanged on initial registration, and then the signed payload (indicating
authenticity) is use for the "login" behavior. On JWT expiry, the login flow is
re-initiated rather than the registration flow, so I'm not sure I understand
where the Man-in-the-Middle for expiry concern would come in.

Perhaps something is getting lost in translation here on my end?




Thanks for acting as a proxy Baptiste, and thanks Emmanuel for taking the time
to look at the proposal!

[R. Tyler Croy]

My colleague in CloudBees Operations, Ben Walding, shared some feedback with me
off list, which he's allowed me to share more broadly. A summary of his
questions are below with some of my responses inline

* UUID: If the UUID is the fingerprint of the Jenkins instance, are there any
PII issues?


In this design the UUID is literally a UUID generated on the server
side by the Node `uuid` module, so it's only correlated to the
instance after the registration has completed. That said, yes there is
a GDPR identification concern if/when that Instance UUID is associated in a
backend database with an individual's identity (e.g. GitHub Username). At this
point this is a concern which I am aware of, but we're not far enough along in
Jenkins Essentials to where this affects our designs.


* Service Authentication: I'm assuming you're thinking of TLS/HTTPS for
transport protection between the client and the server?


TLS is definitely a requirement full stop. I have updated the document with
this under the Security section.


* JWT Bearer Tokens vs. Request Signing: IIUC, the JWT is used as part of an
HMAC signing of the request? The way you've talked about it, it seems more
like a Bearer token (which have risks around replay).


JWT is being used much more as a bearer token rather than HMAC
signing of the request. ("JWT Simple" :))

At this point I do not see additional value in request signing, for the
additional key management overhead to pass a client's public key around between
backend services in order to verify request signatures. I've added some
additional notes to the "Alternative Approaches" section of the document to
capture this concern however.




I've had some constructive discussions around this design, and have made
substantial progress on the implementation work, so I have proposed my JEP
document for numbering and Draft status in this pull request:
https://github.com/jenkinsci/jep/pull/74




Thanks for providing feedback everybody!

[R. Tyler Croy]

Just a heads up to any of those interested, the pull requests implemneting this
functionality, described in JEP-303
(https://github.com/jenkinsci/jep/tree/master/jep/303)
can be found here:

* Registration component: https://github.com/jenkins-infra/evergreen/pull/37
* Login component: https://github.com/jenkins-infra/evergreen/pull/42


Since Kohsuke has added me as the BDFL delegate for this JEP, once the
appropriate review has finished, I expect to mark JEP-303 as 'Accepted' by
mid-next week.


Thanks for all your feedback and help on this one!


Cheers
- R Tyler Croy