is ingress-nginx still FIPS compliant?

[sei-avershave]

I only ask because I just deployed RKE2 and OpenSSL on the nginx controllers can still create MD5 hashes. I'm curious if there's something I'm missing?

thanks

[brandond]

You can reference the docs at https://docs.rke2.io/security/about_hardened_images :

Any binaries that are written in Go are compiled using a FIPS 140-2 compliant build process. For more information on this compiler, refer here.

OpenSSL in the nginx image is not a go binary, so it is not covered by FIPS restrictions.

[brandond]

Regardless of the client fips mode, when trying to connect to an endpoint running the nginx ingress, I get:

brandond@dev01:~$ openssl s_client -connect 172.17.0.3:443 -cipher CAMELLIA256-SHA
CONNECTED(00000003)
80FBA938297F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1588:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 241 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Which is what I would expect to see.

I'm not sure why you're poking at the openssl binary within the image, but if you're going to do that you'll need to export OPENSSL_FIPS=1 to put it in that mode. You can either do that manually, or configure it at a pod level by deploying the following:

 apiVersion: helm.cattle.io/v1
 kind: HelmChartConfig
 metadata:
   name: rke2-ingress-nginx
   namespace: kube-system
 spec:
   valuesContent: |-
     controller:
       extraEnvs:
         - name: OPENSSL_FIPS
           value: "1"

[brandond]

I will note that the ciphers supported by the ingress server are managed by the controller - they're embedded in the configuration it generates; see https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers

If you want to force all OpenSSL code running within the pod into FIPS mode, in addition to the restrictions enforced by the controller, you can set that environment variable - although I have never seen that be necessary.

[sei-avershave]

Everything I read about FIPS compliance always comes back to OpenSSL being FIPS enabled. Even NGINX themselves state they use OpenSSL in FIPS mode in order to be compliant in combination with being compiled a certain way.

Even your documentation states you have OpenSSL to be FIPS compliant which I don't think is running out of the box that way. Why have it in your documentation if it isn't important? I'm not trying to mean or poke it's just weird being deflected trying to understand. So, I guess the last question is, do you think OpenSSL not being in FIPS mode while trying to be credited not an issue?

[brandond]

The bits I know about are strictly related to nginx and the ingress controller; I've never had anyone ask about FIPS compliance for ad-hoc OpenSSL commands run within the ingress-nginx image. I'm not an expert in FIPS so I can't comment much beyond what our documentation covers, and what the upstream SLE BCI docs say at https://documentation.suse.com/sle-micro/5.3/html/SLE-Micro-all/cha-security-fips.html#ssec-fips-containers

I will also note that in my limited understanding, just running a FIPS-certified container image on a vanilla host does not get you anything; the base operating system must also be properly configured and operating in FIPS mode for the certification to apply. Have you also enabled FIPS compliance on the node you're testing on?

Can you help me understand what controls specifically you're trying to meet, and how you're evaluating them? Traditionally one would just scan the ingress endpoint and confirm the available cipher suites.

[sei-avershave]

Yes, the host OS is FIPS compliant but the container itself is not which doesn't make it FIPS compliant, correct?

I want to work backwards because I'm trying to understand. Does NGINX use OpenSSL for encryption and HTTPS termination? If yes, is it being terminated at the controller? I'm starting to second guess myself here.

[instagrim-dev]

Yes, the host OS is FIPS compliant but the container itself is not which doesn't make it FIPS compliant, correct?

I want to work backwards because I'm trying to understand. Does NGINX use OpenSSL for encryption and HTTPS termination? If yes, is it being terminated at the controller? I'm starting to second guess myself here.

Whats the verdict on this?

[sei-avershave]

Honestly, still didn't get a clear answer. Once you have a FIPS compliant OS with OpenSSL that is also running in FIPS mode then you should be compliant and test it using "ad-hoc OpenSSL commands."

I still don't understand how the container is FIPS compliant due to the incorrect version of OpenSSL and the person who answered kept editing their posts making it more confusing.

[sei-avershave]

I hope this helps a bit more.

[brandond]

I believe @galal-hussein is taking a pass at validating the steps to enable FIPS mode from top to bottom. There may be some documentation updates that come out of this, regarding kernel args and/or pod env vars that need to be set.