search

jenkinsci / jep

Jenkins Enhancement Proposals
143 stars 98 forks source link

Scope of JEP-237 is ambiguous #405

Open basil opened 1 year ago

basil commented 1 year ago

JEP-237 states that

configuration of the JVM, platform etc. is out-of-scope, as is making every feature/plugin compliant

but does not describe which plugins are to be made compliant. In practice, Jenkins core is not usable in production scenarios without at least a few plugins, and its automated tests run with a small number of plugins installed. JEP-237 should clarify which plugins are in the project's scope.

EricHeath-AI commented 1 year ago

My rudimentary understanding of FIPS 140-2 is that all cryptographic routines should be implemented by a NIST certified cryptographic module that has a valid certificate in the NIST CMVP (https://csrc.nist.gov/projects/cryptographic-module-validation-program). One such for java is our old and dear friend Bouncy Castle: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4616

Installing appropriate bouncy castle libraries and configuring them correctly in the java security portion of the JRE is a large first step. Ensuring that application code within Jenkins makes use of the appropriate crypto routines from bouncy castle is another fun challenge, but even having a guide for getting the JVM used by Jenkins into the right starting place is quite valuable.

The goal here could be to solve some or all of controls like NIST 800.53 SC-08, SC-12, SC-28, which are briefly: encryption in transit, crytographic key creation/management, and encryption at rest. NIST is only one example security framework - there are certainly others, but maybe this can help to guide the refinement of goals here? Are we trying to make keystores use FIPS 140-2 validated modules, or passwords, or TLS, or storage? Maybe all of the above...? There are also limits on which crypto routines you can even run - eg. md5 is no good for security purposes.

https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home for more about the SC control family.

Jenkins is also fun with great features like shell script execution, you quickly find the need to also harden your OS. So you start doing things like https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-linux-2/ to get openssl running with FIPS-140-2 validated cryto for your curl calls...

basil commented 1 year ago

The point of this issue is to define (in broad terms) the set of plugins that will be adapted. JEP-237 (reasonably) states that "making every […] plugin compliant" is out of scope, but this raises the question as to which plugins do need to be made compliant as part of this JEP, since it isn't practical to run Jenkins without at least a few plugins.

jtnord commented 7 months ago

I will update the scope to be a type of inbound agent, with pipelines using the basic sh bat powershell / pwsh, node steps and the junit plugin as a minimally acceptable set.
We will need one authorisation and authentication strategy which I think can be left ambiguous until such time that we remove the JEP from draft status, or before should analysis find a reasonable target) . (but will likely be ldap and matrix-auth)

If you think there is some other minimally required plugin then please suggest it here.