Do people still need to build the FIPS version of binaries/images with COMPLIANCE_POLICY: 1-140-2?

[qudongfang]

Regarding

Added an environment variable COMPLIANCE_POLICY to Istio components for enforcing TLS restriction for compliance with FIPS. When set to fips-140-2 on the Istiod container, the Istio Proxy container, and all other Istio components, the TLS version is restricted to v1.2. The cipher suites are limited to a subset of ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, and ECDH curves to P-256.

These restrictions apply on the following data paths:

mTLS communication between Envoy proxies;
regular TLS on the downstream and the upstream of Envoy proxies (e.g. gateway);
Google gRPC side requests from Envoy proxies (e.g. Stackdriver extensions);
Istiod xDS server;
Istiod injection and validation webhook servers.
The restrictions are not applied on the following data paths:

Istiod to Kubernetes API server;
JWK fetch from Istiod;
Wasm image and URL fetch from Istio Proxy containers;
ztunnel.
Note that Istio injector will propagate the value of COMPLIANCE_POLICY to the injected proxy container, when set. (Issue #49081)

Can you help to clarify if people still need to build the FIPS version of binaries/images with COMPLIANCE_POLICY: 1-140-2?

cc @kyessenov

[pmerrison]

Yes, people will still need to. The source of truth for all this is CMVP 4407. The short version is that for Istio to be FIPS compliant, two things are needed: the first is only to use TLS 1.2, and the second is to make sure that the build pipeline is configured according to the steps outlined in the security policy so that the BoringCrypto module is used correctly.