search

cyberark / conjur-authn-k8s-client

Authentication sidecar for Conjur Kubernetes integration.
https://www.conjur.org
Apache License 2.0
11 stars 14 forks source link

FIPS compliance for authn-client-k8s #91

Closed hilagross closed 4 years ago

hilagross commented 4 years ago

FIPS compliance for authn-client-k8s

Overview

The National Institute of Standards and Technology (NIST) issued the FIPS 140-2 Publication Series to coordinate the requirements and standards for cryptography modules that include both hardware and software components.

The requirements are to support FIPS in all cryptography 3rd parties, preferably as one source code if possible, otherwise by configuration.

As making Conjur product FIPS compliant, our costumer will gain a cryptographic standard to protect their unclassified, but sensitive data.

As part of the effort of making Conjur FIPS compliant, we tackled an issue regarding Golang. The issue is that Golang, by nature, is not FIPS compliant and they claim that they are not going to be (https://github.com/golang/go/issues/11658#issuecomment-120441723).

There are three alternatives:

  1. Use cgo to call out to an existing certified library

    • This alternative disqualified due to its complexity and consuming time and effort as we will have to replace any usage of crypto.

  2. Use BoringSSL based crypto

    • Use Google’s fork of Golang that uses dev.boringcrypto as its crypto engine. dev.boringcrypto wraps BoringSSL which is FIPS compliant.
    • disadvantage of this approach is that Google does not guarantee any “support” or responsibility on this version being FIPS compliant.

  3. Use RHEL go toolchain.

    • RHEL takes the ownership on the encryption, and bridges between the Golang encryption and OpenSSL.
    • What needs to be done is build the Golang project on subscribed RHEL machine/UBI container with the relevant go-toolset installed on it. than, we can take the compiled binary and copy it into the containers as usual.
    • A big advantage of this approach is that we are aligning with Red Hat which is one of the big players in the field of certifications, enterprise, and federal market.
    • The pipeline should use and subscribe RHEL / UBI on-the-fly.

Requirement

Compare all options (cgo, google toolset, RHEL) and decide on the best approach. should include also in seed-fetcher container. Consider all 3 alternatives:

  1. Use cgo to call out to an existing certified library
  2. Use BoringSSL based crypto.
  3. Use RHEL go toolchain. Create a test plan and design the solution before implementing it.

our goal:

Consider: a. Dev vs Test vs Prod i. UX wise ii. Pipeline iii. RHEL subscription (PR needed?)

b. If deciding on the 3rd option (RHEL), we should compare between RHEL and UBI i. PoC ii. Understand concerns iii. share with security expert

Performance Same SLA of performance should be kept.

DoD

Team

SDLC Timeline

Stage Updates Artifact
Project Initialization
Kickoff
Feature Proposal
Functional Sign-off
Technical D&D
Solution Sign-off
Execution
Acceptance
izgeri commented 4 years ago

Is it possible to create a separate FIPS-compliant image of golang and keep pretty much everything else the same?

For example, it appears from the boringcrypto docs that you can use the goboring Docker image in place of the standard golang Docker image with (likely) no other modifications.

Can we add a Dockerfile.fips to this project that uses the goboring base image but is otherwise identical to the Dockerfile, and is only built when a special command is passed to ./bin/build? That would preserve the development experience in almost all cases, and the pipeline could build this custom image in addition to the other images and push it to DockerHub and/or our internal registry.

Tovli commented 4 years ago

@hilagross - I think a PR would be easier for comments

regarding the doc - is this a requirement? "Compiling the authenticator on RHEL" why do we must use RHEL?

orenbm commented 4 years ago

@shaharglazner @hilagross how do we decide that a solution is FIPS compliant. For example, in the description of the GoBoring solution you say disadvantage of this approach is that Google does not guarantee any “support” or responsibility on this version being FIPS compliant.. Does this mean that we can't use this solution?

orenbm commented 4 years ago

@izgeri when you say 

Can we add a Dockerfile.fips to this project that uses the goboring base image but is otherwise identical to the Dockerfile, and is only built when a special command is passed to ./bin/build?

why would we have another image instead of building our main image from the goboring base image? Are there any risks here?

izgeri commented 4 years ago

@orenbm goboring is a fork of Go (see here).

What is the benefit to all of our customers from requiring that the binary is built using FIPS-compliant libraries for everyone? It does not add much complexity for us to build the binary using the official Golang project and distribute Docker images that include that, and separately create a binary using the goboring and distribute a Docker image which includes that for end-users interested in a FIPS-compliant version of this project.

orenbm commented 4 years ago

thanks @izgeri , that sounds like a good reason. It's really not hard to have 2 images, just wondered why we need the original one.

izgeri commented 4 years ago

@orenbm there is more work in this epic still, correct? I understood there would be additional test changes to happen - is there a separate issue for tracking that work?

orenbm commented 4 years ago

@izgeri you are correct. It moved to Closed by accident when I merged #97.

I added now all the relevant issues that needs to be done as part of this effort.

Thanks!