Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-6812

The SMCP 2.6 explicitly sets not FIPS compliant cipher suite (so sidecars are not able to run on fips cluster)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • None
    • OSSM 2.6.0
    • Maistra
    • None

      When you run SMCP v2.6 (istiod 1.20) on fips-enabled cluster and add some application into the mesh, the sidecar proxy container is not able to start with the log:

      2024-07-10T13:14:39.644864Z	info	dns	Starting local udp DNS server on 127.0.0.1:15053
      2024-07-10T13:14:39.645060Z	info	dns	Starting local tcp DNS server on 127.0.0.1:15053
      2024-07-10T13:14:39.664575Z	info	ads	All caches have been synced up in 26.250721ms, marking server ready
      2024-07-10T13:14:39.664898Z	info	xdsproxy	Initializing with upstream address "istiod-basic.istio-system.svc:15012" and cluster "Kubernetes"
      2024-07-10T13:14:39.673020Z	info	sds	Starting SDS grpc server
      2024-07-10T13:14:39.753635Z	info	xdsproxy	connected to upstream XDS server: istiod-basic.istio-system.svc:15012
      2024-07-10T13:14:39.773326Z	info	ads	ADS: new connection for node:productpage-v1-76fcc8dc78-b2gc8.bookinfo-1
      2024-07-10T13:14:39.773734Z	info	ads	ADS: new connection for node:productpage-v1-76fcc8dc78-b2gc8.bookinfo-2
      2024-07-10T13:14:39.830814Z	info	cache	generated new workload certificate	latency=165.990898ms ttl=23h59m59.169190248s
      2024-07-10T13:14:39.830845Z	info	cache	Root cert has changed, start rotating root cert
      2024-07-10T13:14:39.830861Z	info	ads	XDS: Incremental Pushing ConnectedEndpoints:2 Version:
      2024-07-10T13:14:39.830904Z	info	cache	returned workload trust anchor from cache	ttl=23h59m59.169096061s
      2024-07-10T13:14:39.830949Z	info	cache	returned workload certificate from cache	ttl=23h59m59.169052339s
      2024-07-10T13:14:39.831050Z	info	cache	returned workload trust anchor from cache	ttl=23h59m59.168956329s
      2024-07-10T13:14:39.831633Z	info	ads	SDS: PUSH request for node:productpage-v1-76fcc8dc78-b2gc8.bookinfo resources:1 size:4.0kB resource:default
      2024-07-10T13:14:39.832226Z	info	ads	SDS: PUSH request for node:productpage-v1-76fcc8dc78-b2gc8.bookinfo resources:1 size:1.1kB resource:ROOTCA
      2024-07-10T13:14:39.832293Z	info	cache	returned workload trust anchor from cache	ttl=23h59m59.167708798s
      2024-07-10T13:14:39.916257Z	warning	envoy config external/envoy/source/extensions/config_subscription/grpc/grpc_subscription_impl.cc:138	gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) virtualInbound: Failed to initialize cipher suites ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-GCM-SHA256. The following ciphers were rejected when tried individually: AES256-GCM-SHA384, AES128-GCM-SHA256
      	thread=14
      2024-07-10T13:14:40.526021Z	warn	Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
      2024-07-10T13:14:41.530112Z	warn	Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
      

      When I look into the sidecar proxy config via `/istioctl proxy-config all --namespace mkralik httpbin-6c746777b9-h9mn7`, the cipher_suites are explicitly specified there

      "transport_socket": {
                "name": "envoy.transport_sockets.tls",
                "typed_config": {
                 "@type": "type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext",
                 "common_tls_context": {
                  "tls_params": {
                   "cipher_suites": [
                    "ECDHE-ECDSA-AES256-GCM-SHA384",
                    "ECDHE-RSA-AES256-GCM-SHA384",
                    "ECDHE-ECDSA-AES128-GCM-SHA256",
                    "ECDHE-RSA-AES128-GCM-SHA256",
                    "AES256-GCM-SHA384",
                    "AES128-GCM-SHA256"
                   ]
                  },
      

      However, the `AES256-GCM-SHA384` is not FIPS compliant according to this: https://access.redhat.com/solutions/7052018

      When I tried to do the same in SMCP v2.5 (istiod 1.18), there was no problem because a sidecar proxy config doesn't contain explicitly specified `cipher_suites`.

      I found that there was a change in Istio 1.19.8 regarding this
      https://istio.io/latest/news/releases/1.19.x/announcing-1.19.8/

      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.
      

              jewertow@redhat.com Jacek Ewertowski
              mkralik@redhat.com Matej Kralik
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: