Navigation :

Gloo Gateway and Istio

You can configure your Gloo Gateway gateway with an Istio sidecar to secure the connection between your gateway and the services in your Istio service mesh. The sidecar in your Gloo Gateway gateway uses mutual TLS (mTLS) to prove its identity to the services in the mesh and vice versa.

Before you begin

Complete the following tasks before configuring an Istio sidecar for your Gloo Gateway gateway:

Create or use an existing cluster that runs Kubernetes a version supported by both your version of Edge and the version of Istio you intend to install.
Install Istio in your cluster. Istio versions 1.14 through 1.20 are supported in Gloo Gateway 1.16. See the support matrix for more details.
Set up a service mesh for your cluster. For example, you can use Gloo Mesh Enterprise to configure a service mesh that is based on Envoy and Istio, and that can span across multiple service meshes and clusters.
Install Helm version 3 on your local machine.

Configure the Gloo Gateway gateway with an Istio sidecar

Install the Gloo Gateway gateway and inject it with an Istio sidecar.

Add the Gloo Gateway Helm repo.

helm repo add gloo https://storage.googleapis.com/solo-public-helm

Update the repo.
```
helm repo update
```
Create a value-overrides.yaml file with the following content:

Set istioIntegration.disableAutoinjection to true so that Istio does not automatically inject a sidecar to the gateway proxy pods. This way, Gloo can configure the sidecar.
Set global.istioIntegration.enabled to true so that the Istio proxy is added to the gateway deployment. This way, the gateway proxy can use Istio certs despite not being in the mesh. Gloo uses a default sidecar configuration, which you can review in the gloo project on GitHub. You can also use the global.istioSDS.customSidecars[] setting to provide your own sidecar configuration for the Gloo Gateway Gateway.

Specify image fields under global.glooMtls.istioProxy.image and global.glooMtls.sds.image corresponding with the version of Istio and Gloo Gateway installed respectively

The default Istio version is 1.22.0

global:
  istioIntegration:
    disableAutoinjection: true
    enabled: true
  glooMtls:
    istioProxy:
      image:
        registry: docker.io/istio
        repository: proxyv2
        tag: 1.22.0
    sds:
      image:
        repository: sds
        tag: 1.15.7
gatewayProxies:
  gatewayProxy:
    podTemplate: 
      httpPort: 8080
      httpsPort: 8443

Although the istioProxy values are defined in the glooMtls block, the values are also used to configure istioMtls.

Install or upgrade Gloo Gateway.
- Install Gloo Gateway
- Upgrade Gloo Gateway
Install Gloo Gateway with the settings in the value-overrides.yaml file. This command creates the gloo-system namespace and installs the Gloo Gateway components into it.
```
 helm install gloo gloo/gloo --namespace gloo-system --create-namespace -f value-overrides.yaml
```
Upgrade Gloo Gateway with the settings in the value-overrides.yaml file.
```
helm upgrade gloo gloo/gloo --namespace gloo-system -f value-overrides.yaml
```
Verify your setup.

Verify that your gateway-proxy pod now has three containers.

kubectl get pods -n gloo-system

Example output:

NAME                             READY   STATUS      RESTARTS   AGE
discovery-6dcc8ddc58-q4zv7       1/1     Running     0          39s
gateway-certgen-xzr7t            0/1     Completed   0          43s
gateway-proxy-7bc5c97449-n9498   3/3     Running     0          39s
gloo-d8cfbf86b-v59j4             1/1     Running     0          39s
gloo-resource-rollout-hhvf9      0/1     Completed   0          38s

Describe the gateway-proxy pod to verify that the istio-proxy and sds containers are running.
```
kubectl describe <gateway-pod-name> -n gloo-system
```

Congratulations! You have successfully configured an Istio sidecar for your Gloo Gateway gateway.

Set up and verify the mTLS connection

To demonstrate that you can connect to your app via mutual TLS (mTLS), you can follow these step to:

Install the httpbin app in your cluster
Set up a virtual service to route incoming requests to the httpbin app
Require strict PeerAuthentication in the Istio mesh
Configure the relevant upstream(s) to use Istio mTLS

Install the httpbin app in your cluster as part of the Istio mesh.

kubectl label namespace default istio-injection=enabled
kubectl apply -f https://raw.githubusercontent.com/solo-io/workshops/master/gloo-edge/data/httpbin.yaml

Example output:

namespace/default labeled
serviceaccount/httpbin created
service/httpbin created
deployment.apps/httpbin created

Create a virtual service to set up the routing rules for your httpbin app. In the following example, you instruct the Gloo Gateway gateway to route incoming requests on the /productpage path to be routed to the productpage service in your cluster.

kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: vs
  namespace: gloo-system
spec:
  virtualHost:
    domains:
    - 'www.example.com'
    routes:
    - matchers:
      - prefix: /
      routeAction:
        single:
          upstream:
            name: default-httpbin-8000
            namespace: gloo-system
EOF

Test access to httpbin by sending a request to the /headers endpoint. This endpoint returns a response with all of the request headers received by httpbin.

curl -H "Host: www.example.com" $(glooctl proxy url)/headers

A response indicates that httpbin is reachable. However, traffic to the product page upstream is not encrypted with mTLS. We can tell this because the X-Forwarded-Client-Cert header is not present.

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.default",
    "User-Agent": "curl/7.88.1",
    "X-B3-Sampled": "0",
    "X-B3-Spanid": "b55df4f4d6d75692",
    "X-B3-Traceid": "c048ebc0bb22b1eeb55df4f4d6d75692",
    "X-Forwarded-Host": "www.example.com"
  }
}

To require all traffic in the mesh to use mTLS, apply the following STRICT PeerAuthentication policy.

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "test"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Repeat the same curl request to the product page.

curl -v -H "Host: www.example.com" $(glooctl proxy url)/headers

The 503 Service Unavailable response is returned because the upstream is not configured for Istio mTLS.

*   Trying 127.0.0.1:32000...
* Connected to localhost (127.0.0.1) port 32000 (#0)
> GET /headers HTTP/1.1
> Host: www.example.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 503 Service Unavailable
< content-length: 95
< content-type: text/plain
< date: Tue, 03 Oct 2023 20:15:55 GMT
< server: envoy
<
* Connection #0 to host localhost left intact
  upstream connect error or disconnect/reset before headers. reset reason: connection termination

Use glooctl to configure the upstream for Istio mTLS.

glooctl istio enable-mtls --upstream default-httpbin-8000

Repeat the same curl request to the product page.

curl -v -H "Host: www.example.com" $(glooctl proxy url)/headers

This time, the request succeeds because traffic is encrypted using mTLS. Note that httpbin received the X-Forwarded-Client-Cert header, indicating that Istio mTLS has occurred.

   {
     "headers": {
       "Accept": "*/*",
       "Host": "httpbin.default",
       "User-Agent": "curl/7.88.1",
       "X-B3-Sampled": "0",
       "X-B3-Spanid": "b34b0243f9a1e410",
       "X-B3-Traceid": "21dc96a98c29ef48b34b0243f9a1e410",
       "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=924e94ed5ff628e797d62acddf37d347ce3df827d5605727bae31a45025bb2a3;Subject=\"\";URI=spiffe://cluster.local/ns/gloo-system/sa/gateway-proxy",
       "X-Forwarded-Host": "www.example.com"
     }
   }

If you use Gloo Mesh Enterprise for your service mesh, you can configure your Gloo Gateway upstream resource to point to the Gloo Mesh ingress-gateway. For a request to reach the httpbin app in remote workload clusters, your virtual service must be configured to route traffic to the Gloo Mesh east-west gateway.