About Gloo Mesh Istio

Install Gloo Mesh Istio, a hardened Istio enterprise image, in your remote clusters.

About Gloo Mesh Istio

Gloo Mesh Istio is a hardened Istio enterprise image to maintain n-4 support for CVEs and other security fixes longer than the community Istio, which provides n-1 support with an additional 6 weeks of extended time to upgrade the n-2 version to n-1. Based on a cadence of 1 release every 3 months, Gloo Mesh's n-4 support provides an extra 9 months to run the hardened Istio version of your choice, compared to an open source strategy that also lacks enterprise support. Note that all backported functionality is available in the upstream community Istio, as there are no proprietary features or forked capabilities from community Istio.

Solo provides two main distributions for Gloo Mesh Istio as follows.

Additionally, the standard and solo distributions of Istio come in several varieties as follows.

To use the FIPS distribution, check out About Gloo Mesh Istio FIPS. To use a specific version of a distribution, see Get the Gloo Mesh Istio version that you want to use.

Version support

Review the following tables to determine Gloo Mesh Enterprise version compatibility with Gloo Mesh Istio and Kubernetes.

Gloo Mesh Enterprise Gloo Mesh Istio* Kubernetes
1.2 1.8 - 1.11 1.16 - 1.22
1.1 1.7 - 1.11 1.16 - 1.21
1.0 1.7 - 1.10 1.16 - 1.21

Additionally, the following Gloo Mesh Enterprise features require specific versions.

Gloo Mesh feature Required versions
directResponseAction in Gloo Mesh Gateway Gloo Mesh Istio 1.8 solo image or later
Multicluster subset routing in traffic policies Istio 1.8 or later
Rate limiting for Gloo Mesh Gateway Gloo Mesh Istio 1.8 solo image or later
XSLT filter Istio 1.11 or later

* Gloo Mesh Enterprise offers n-4 security patching support only with Gloo Mesh Istio versions, not community Istio versions. You must run the latest Gloo Mesh Enterprise patch version to get the backported Istio support. For more considerations when installing Gloo Mesh Istio, see Download a specific image.

Istio and Kubernetes: Supported Kubernetes versions are dependent on Gloo Mesh API version compatibility and on the version of Istio that is installed. For example, you cannot use Gloo Mesh Enterprise with Istio 1.9 on a Kubernetes 1.22 cluster, because Istio 1.9 does not support Kubernetes 1.22. To review Istio support of Kubernetes versions, see the Istio documentation. OpenShift and Kubernetes: The Istio and Kubernetes versions also determines which version of OpenShift you can run. For example, if you have Istio 1.11 you can run OpenShift 4.8, which uses Kubernetes 1.21. To review OpenShift Kubernetes support, see the OpenShift changelog documentation for the version you want to use.

Istio versions 1.8.0, 1.8.1, and 1.8.2 have a known issue where sidecar proxies might not start under specific circumstances. This bug might surface in sidecars configured by Failover Services. This issue is resolved in Istio 1.8.3.

About Gloo Mesh Istio FIPS

For use cases that require federal information processing capabilities, install a Gloo Mesh Istio images that are tagged with fips, which comply with National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS).

For example, you might provide a cloud service that runs in a Federal Risk and Authorization Management Program (FedRAMP) regulated environment. In such cases, Gloo Mesh offers FIPS builds of community Istio without the need for any additional tooling or CLIs. You can use the upstream-native Istio tooling, such istioctl or IstioOperator, to install Solo's FIPS builds of Istio.

Choosing a FIPS build

Gloo Mesh Istio is a hardened Istio enterprise image to maintain n-4 support for CVEs and other security fixes longer than the community Istio, which provides n-1 support with an additional 6 weeks of extended time to upgrade the n-2 version to n-1. Based on a cadence of 1 release every 3 months, Gloo Mesh's n-4 support provides an extra 9 months to run the hardened Istio version of your choice, compared to an open source strategy that also lacks enterprise support. Note that all backported functionality is available in the upstream community Istio, as there are no proprietary features or forked capabilities from community Istio.

Standard and Solo FIPS builds

Solo provides two main distributions for Gloo Mesh Istio, which both offer FIPS-compliant builds:

Depending on the distribution, the image tag for installation might look like 1.11.4-solo-fips.

Optional: Distroless FIPS builds

In addition, you can also choose a FIPS build that is distroless. A FIPS image that is tagged with distroless is a slimmed down distribution with the minimum set of binary dependencies to run the image, for enhanced performance and security. Keep in mind that there are some challenges around distroless builds; for example, if your app relies on package management, shell, or other operating system tools such as pip, apt, ls, grep, or bash, you must find another way to install these dependencies.

Depending on the distribution, the image tag for a distroless installation might look like 1.11.4-solo-fips-distroless.

More information

For more information:

Installing a FIPS build

After you choose your FIPS build, you can follow the steps in Install Gloo Mesh Istio to install Istio on each remote cluster. In the IstioOperator resource, be sure to specify the FIPS-tagged image that you want to use. For example, your IstioOperator might look like the following:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: gloo-mesh-istio
  namespace: istio-system
spec:
  # This value is required for Gloo Mesh Istio
  hub: gcr.io/istio-enterprise
  # This value can be any Gloo Mesh Istio tag
  tag: 1.11.4-solo-fips
... 

Verifying FIPS compliance

For most auditors, both the Istio control plane and the service mesh data plane in each remote cluster must be FIPS compliant. You can verify that your images are a FIPS-compliant version by checking Envoy and istiod on each cluster.

  1. To verify the Istio data plane in each remote cluster, check the Envoy proxy version.

    kubectl exec -it -n istio-system deploy/istio-ingressgateway -- /usr/local/bin/envoy --version
    

    Example output of FIPS compliance:

    /usr/local/bin/envoy  version: fa9fd362c488508a661d2ffa66e66976bb9104c3/1.15.1/Clean/RELEASE/BoringSSL-FIPS
    
  2. To verify the Istio control plane components in each remote cluster, copy the pilot-discovery binary out of the istiod container, and run goversion against the binary.

    1. Install goversion to your local machine.

      go get github.com/rsc/goversion
      
    2. Copy the binary out to the local disk.

      kubectl cp istio-system/<pod-name>:/usr/local/bin/pilot-discovery /tmp/pilot-discovery && chmod +x /tmp/pilot-discovery
      
    3. Run goversion against the binary.

      goversion -crypto /tmp/pilot-discovery
      

      Example output of FIPS compliance: Note that the type is indicated as boring and the version number includes a b.

      /tmp/pilot-discovery go1.14.12b4 (boring crypto)
      

      Example output of FIPS non-compliance: Note that the type is indicated as standard, which means that the image in not a FIPS build of Istio.

      /tmp/pilot-discovery go1.14.14 (standard crypto)
      

RSA 4096 key sizes

With Gloo Mesh Istio's FIPS builds, you can run the control plane in strict adherence to the original 140-2 standard that did not allow RSA 4096 key sizes, or in a mode that supports 4096 key sizes. For strict mode, append -fipsonly to the build tag.

If you run in strict mode (-fipsonly), your output for verifying the Istio control plane looks like the following. This mode does not allow keys up to 4096.

/tmp/pilot-discovery go1.14.12b4 (boring crypto) +crypto/tls/fipsonly

If your output looks like the following, the mode does allow keys up to 4096.

/tmp/pilot-discovery go1.14.12b4 (boring crypto)