[PUP-7510] FIPS-Enabled Puppet Created: 2017/05/09  Updated: 2018/02/12  Resolved: 2018/02/12

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: PUP 5.4.0

Type: Epic Priority: Normal
Reporter: Eric Sorenson Assignee: Unassigned
Resolution: Done Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
Relates
relates to PA-1642 Add EL 7 (FIPS) x86_64 as a supported... Closed
relates to SERVER-2524 FIPS-Enabled Puppet Server Side Developing
Epic Name: FIPS-Enabled Puppet
Template:
Acceptance Criteria:

Customers are able to pass an audit of their FIPS 140-2 compliance.

Team/s:
Platform Core
Release Notes: New Feature
Release Notes Summary: We are adding a new puppet-agent package intended to be deployed on FIPS enabled hosts. The new package is linked against system OpenSSL instead of the vendored version in the puppet-agent package. On FIPS enabled hosts, puppet will not use MD5 for file checksums or digital signature algorithms, and will gracefully error if configured to use MD5, e.g. Puppet[:digest_algorithm] = 'md5'. This only affect the puppet-agent package. Future releases will provide FIPS compliance for puppetserver and CA.
QA Risk Assessment: Needs Assessment

 Description   

The problem is that customers using our Puppet and Puppet Enterprise packages cannot meet the FIPS 140-2 requirements because we roll our own OpenSSL and do not link against the OpenSSL provided with RHEL. This causes them to fail "FISMA High" compliance standards.

This epic is the place to gather the stream of work required to remediate this issue, although some implications (such as for puppet-server) will require tickets outside the PUP jira project.



 Comments   
Comment by David Lutterkort [ 2017/05/18 ]

I asked Trevor Vaughn what platforms need to be covered here, and this was his reply:

RHEL, SuSE, and OEL are the main server-side platforms that have FIPS certifications.

Windows also has the certification on the client side (not sure how to handle that one).

The Linux side should be relatively easy and I would have tried it but I couldn't figure out how to build the AIO packages.

I did note that there were already some Ruby configuration files for different platforms in there that had different options so, in theory, you just need to tell the build to use the system libraries.

The Java side is more complex, but there is (as of last year) a Bouncy Castle library that might be a drop in replacement.

Comment by Bill Weiss [ 2017/06/13 ]

The Bouncy Castle FIPS library requests that we get on a support contract with them of $5k/year. Seems reasonable if we go down that route.

Comment by Jayant Sane [ 2017/06/13 ]

Our Java based components use crypto libs in Java and not from Bouncy Castle. We could try testing with Java's FIPS compliant crypto provider. Need to understand if SunPKCS11-NSS, which appears to be FIPS certified crypto provider, would be acceptable.

Comment by Trevor Vaughan [ 2017/06/16 ]

Jayant Sane I didn't see the Sun one on the list, but I did see the IBM Java libs http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2715.pdf.

There are definite pros and cons to using native vs Bouncy Castle. The pro to not using it is that you don't have to change any code. The con is that you need to wait for the next version of Java to be certified before you can actually upgrade. If you disconnect the crypto libs, then you should be able to upgrade asynchronously (I think).

Comment by Jayant Sane [ 2017/06/22 ]

Agree about use of native vs bouncy castle. I spoke to Jeremy Barlow. Last time, a few years ago, they had found Puppet Server performance with bouncy castle was quite unacceptable. Don't know if things have improved since.

Comment by Josh Cooper [ 2018/02/06 ]

FYI, I moved all of the server-side tickets to PUP-8423 as we're getting close to wrapping up 5.4.0 with the necessary puppet-agent changes.

Comment by Trevor Vaughan [ 2018/02/06 ]

Jayant Sane It's awesome that this is almost done. Is there an ETA at this point?

Comment by Josh Cooper [ 2018/02/12 ]

All agent changes are done. Closing the epic.

Trevor Vaughan we're looking to release 5.4.0 real soon(tm), within the week or so.

Generated at Mon Jan 27 10:49:21 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.