About Solo distributions of Istio

The Solo distribution of Istio is a hardened Istio enterprise image, which maintains n-4 support for CVEs and other security fixes. The image support timeline is longer than the community Istio support timeline, 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 Core’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 forked capabilities from community Istio.

The following image provides an overview of how Solo engineers harden the base Istio image release.

Solo image hardening overview
Figure: Solo image hardening overview

To use a version of Istio that is no longer supported by the community with Gloo Mesh Core, you must install the Solo distribution of Istio. If the Istio version that you want to use is currently supported by the community, you can use either the community Istio or the Solo distribution of Istio. To review supported Solo distributions of Istio, see the versions table. To review supported community versions, see the Istio documentation.

Distributions

Solo provides two main distributions of Istio as follows.

  • Standard: An enterprise distribution of the community Istio project with additional security patches. Example: 1.22.4
  • Solo: An enterprise distribution of the community Istio project with additional security patches, as well as certain Envoy filters to enable Gloo Mesh Core features, such as support for deploying Istio service meshes in ambient mode. You must use the solo image to use these features. Example: 1.22.4-solo

Both Solo’s standard and solo distributions of Istio come in the following optional varieties.

  • FIPS: An image that is tagged with fips complies with NIST FIPS, for use cases that require federal information processing capabilities. Examples: 1.22.4-fips, 1.22.4-solo-fips
  • Distroless: An 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. Note that 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. Examples: 1.22.4-distroless, 1.22.4-solo-distroless
  • ARM: An image that is tagged with arm is compatible with ARM64 architectures. Support for ARM images varies with your Istio version and distribution.
    • 1.16.0 and later: Both the standard and Solo distributions of Istio are now multi-architecture Docker images, which work for both AMD and ARM architectures. The -arm tag is no longer needed or supported. For example, 1.22.4-solo, 1.22.4-fips, and 1.22.4-solo-fips work for both AMD and ARM.
    • 1.15.3 and later 1.15 versions: ARM images (tagged with -arm) are supported for the standard distribution with FIPS and the Solo distribution without FIPS. For example, 1.15.3-fips-arm and 1.15.3-solo-arm are supported, but 1.15.3-solo-fips-arm and 1.15.3-arm are not supported.
    • 1.15.0 - 1.15.2: ARM images are not supported for either distribution of these versions.

An image might be tagged to meet multiple use cases, such as 1.22.4-solo-fips-distroless.

About Solo FIPS distribution of Istio

For use cases that require federal information processing capabilities, install Solo distributions of Istio 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 Istio Helm charts, to install Solo’s FIPS builds of Istio.

Standard and Solo FIPS builds

Solo provides two main distributions of Istio, which both offer FIPS-compliant builds:

  • Standard: An enterprise distribution of the community Istio project with additional security patches.
  • Solo: An enterprise distribution of the community Istio project with additional security patches, as well as certain Envoy filters to enable Gloo Mesh Core features.

Depending on the distribution, the image tag for installation might look like 1.22.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.22.4-solo-fips-distroless.

Installing a FIPS build

To find the FIPS build that you want, see Download a specific Solo distribution of Istio. You can then use the image to install Istio in one of the following ways.

  • To use Gloo Mesh Core to deploy and manage the lifecycle of your Istio service meshes across clusters, see Deploy Gloo-managed service meshes. In the example files that you download in this guide, make sure to replace any images with a Solo FIPS distribution of Istio-tagged image.
  • To manually install Istio, you can use an installation method such as using istioctl, the Istio Operator, or Helm. When you install Istio, make sure to replace any images with a Solo FIPS distribution of Istio-tagged image. For more information, see the Istio documentation.

Verifying FIPS compliance

For most auditors, both the Istio control plane and the service mesh data plane in each workload 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 workload 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 workload 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)