istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Improvements to egress examples (#2850) 

* Reorganize egress gateway and TLS origination examples

* More cleanup

* fix circleci errors

* nits

* another nit

* address review comments

* fix broken link
This commit is contained in:
Frank Budinsky 2018-11-08 10:44:10 -05:00 committed by GitHub
parent a514e979db
commit 93a928bc48
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 407 additions and 320 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

329
content/docs/examples/advanced-gateways/egress-gateway-mtls-origination/index.md → content/docs/examples/advanced-gateways/egress-gateway-tls-origination/index.md
View File

@ -1,22 +1,284 @@
---
title: Mutual TLS origination by Egress Gateway
description: Describes how to configure an Egress Gateway to perform mutual TLS origination to external services.
weight: 45
title: Egress Gateway with TLS Origination
description: Describes how to configure an Egress Gateway to perform TLS origination to external services.
weight: 40
keywords: [traffic-management,egress]
---
The [Configure an egress gateway](/docs/examples/advanced-gateways/egress-gateway) example describes how to configure
Istio to direct egress traffic through a dedicated service called _egress gateway_.
This example shows how to configure an egress gateway to enable mutual TLS for traffic to external services.
The [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination) example
shows how to configure Istio to perform [TLS origination](/help/glossary/#tls-origination) for traffic to an external service.
The [Configure an Egress Gateway](/docs/examples/advanced-gateways/egress-gateway) example shows how to configure
Istio to direct egress traffic through a dedicated _egress gateway_ service.
This example combines the previous two by describing how to configure an egress gateway to perform
TLS origination for traffic to external services.
To simulate an actual external service that supports the mTLS protocol, you first deploy an [NGINX](https://www.nginx.com)
server in your Kubernetes cluster, but running outside of the Istio service mesh, i.e., in a namespace
without Istio sidecar proxy injection enabled.
Next, you configure an egress gateway to perform mutual TLS with the external NGINX server.
Finally, you direct traffic from application pods inside the mesh to the NGINX server outside the mesh through
the egress gateway.
## Before you begin
## Generate client and server certificates and keys
* Setup Istio by following the instructions in the [Installation guide](/docs/setup/).
* Start the [sleep]({{< github_tree >}}/samples/sleep) sample
which will be used as a test source for external calls.
If you have enabled [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection), do
{{< text bash >}}
$ kubectl apply -f @samples/sleep/sleep.yaml@
{{< /text >}}
otherwise, you have to manually inject the sidecar before deploying the `sleep` application:
{{< text bash >}}
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
{{< /text >}}
Note that any pod that you can `exec` and `curl` from would do.
* Create a shell variable to hold the name of the source pod for sending requests to external services.
If you used the [sleep]({{<github_tree>}}/samples/sleep) sample, run:
{{< text bash >}}
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
{{< /text >}}
## Perform TLS origination with an egress gateway
This section describes how to perform the same TLS origination as in the
[TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example,
only this time using an egress gateway. Note that in this case the TLS origination will
be done by the egress gateway, as opposed to by the sidecar in the previous example.
1. Define a `ServiceEntry` for `edition.cnn.com`:
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: http-port-for-tls-origination
protocol: HTTP
resolution: DNS
EOF
{{< /text >}}
1. Verify that your `ServiceEntry` was applied correctly by sending a request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
location: https://edition.cnn.com/politics
...
command terminated with exit code 35
{{< /text >}}
Your `ServiceEntry` was configured correctly if you see _301 Moved Permanently_ in the output.
1. Create an egress `Gateway` for _edition.cnn.com_, port 443, and a destination rule for
sidecar requests that will be directed to the egress gateway.
Choose the instructions corresponding to whether or not you have
[mutual TLS authentication](/docs/tasks/security/mutual-tls/) enabled in Istio.
{{< tabset cookie-name="mtls" >}}
{{% tab name="mTLS enabled" cookie-value="enabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- edition.cnn.com
tls:
mode: MUTUAL
serverCertificate: /etc/certs/cert-chain.pem
privateKey: /etc/certs/key.pem
caCertificates: /etc/certs/root-cert.pem
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
sni: edition.cnn.com
EOF
{{< /text >}}
{{% /tab %}}
{{% tab name="mTLS disabled" cookie-value="disabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: http-port-for-tls-origination
protocol: HTTP
hosts:
- edition.cnn.com
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
EOF
{{< /text >}}
{{% /tab %}}
{{< /tabset >}}
1. Define a `VirtualService` to direct the traffic through the egress gateway, and a `DestinationRule`
to perform TLS origination for requests to `edition.cnn.com`:
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-tls-for-edition-cnn-com
spec:
host: edition.cnn.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com
EOF
{{< /text >}}
1. Send an HTTP request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 200 OK
...
content-length: 150793
...
{{< /text >}}
The output should be the same as in the [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/)
example, with TLS origination: without the _301 Moved Permanently_ message.
1. Check the log of the `istio-egressgateway` pod and you should see a line corresponding to our request.
If Istio is deployed in the `istio-system` namespace, the command to print the log is:
{{< text bash >}}
$ kubectl logs $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') egressgateway -n istio-system | tail
{{< /text >}}
You should see a line similar to the following:
{{< text plain>}}
"[2018-06-14T13:49:36.340Z] "GET /politics HTTP/1.1" 200 - 0 148528 5096 90 "172.30.146.87" "curl/7.35.0" "c6bfdfc3-07ec-9c30-8957-6904230fd037" "edition.cnn.com" "151.101.65.67:443"
{{< /text >}}
### Cleanup the TLS origination example
Remove the Istio configuration items you created:
{{< text bash >}}
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule originate-tls-for-edition-cnn-com
$ kubectl delete destinationrule egressgateway-for-cnn
{{< /text >}}
## Perform mutual TLS origination with an egress gateway
Similar to the previous section, this section describes how to configure an egress gateway to perform
TLS origination for an external service, only this time using a service that requires mutual TLS.
This example is considerably more involved because you need to first:
1. generate client and server certificates
1. deploy an external service that supports the mTLS protocol
1. redeploy the egress gateway with the needed mTLS certs
Only then can you configure the external traffic to go through the egress gateway which will perform
TLS origination.
### Generate client and server certificates and keys
1. Clone the <https://github.com/nicholasjackson/mtls-go-example> repository:
@ -34,7 +296,7 @@ the egress gateway.
Use any password with the following command:
{{< text bash >}}
$ ./generate.sh nginx.example.com <password>
$ ./generate.sh nginx.example.com password
{{< /text >}}
Select `y` for all prompts that appear.
@ -45,13 +307,17 @@ the egress gateway.
$ mkdir ../nginx.example.com && mv 1_root 2_intermediate 3_application 4_client ../nginx.example.com
{{< /text >}}
1. Change directory back:
1. Go back to your previous directory:
{{< text bash >}}
$ cd ..
{{< /text >}}
## Deploy an NGINX server
### Deploy an mTLS server
To simulate an actual external service that supports the mTLS protocol,
deploy an [NGINX](https://www.nginx.com) server in your Kubernetes cluster, but running outside of
the Istio service mesh, i.e., in a namespace without Istio sidecar proxy injection enabled.
1. Create a namespace to represent services outside the Istio mesh, namely `mesh-external`. Note that the sidecar proxy will
not be automatically injected into the pods in this namespace since the automatic sidecar injection was not
@ -213,7 +479,7 @@ to hold the configuration of the NGINX server:
EOF
{{< /text >}}
## Deploy a container to test the NGINX deployment
#### Deploy a container to test the NGINX deployment
1. Create Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) to hold the client's and CA
certificates:
@ -342,7 +608,7 @@ to hold the configuration of the NGINX server:
</html>
{{< /text >}}
## Redeploy the Egress Gateway with the client certificates
### Redeploy the Egress Gateway with the client certificates
1. Create Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) to hold the client's and CA
certificates.
@ -388,7 +654,7 @@ to hold the configuration of the NGINX server:
`tls.crt` and `tls.key` should exist in `/etc/istio/nginx-client-certs`, while `ca-chain.cert.pem` in
`/etc/istio/nginx-ca-certs`.
## Configure mutual TLS origination for egress traffic
### Configure mutual TLS origination for egress traffic
1. Create an egress `Gateway` for `nginx.example.com`, port 443, and destination rules and
virtual services to direct the traffic through the egress gateway and from the egress gateway to the external
@ -506,23 +772,20 @@ to hold the configuration of the NGINX server:
...
{{< /text >}}
1. Check the log of the `istio-egressgateway` pod and see a line corresponding to our request. If Istio is deployed in
the `istio-system` namespace, the command to print the log is:
1. Check the log of the `istio-egressgateway` pod for a line corresponding to our request.
If Istio is deployed in the `istio-system` namespace, the command to print the log is:
{{< text bash >}}
$ kubectl logs $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -n istio-system | grep 'nginx.example.com' | grep HTTP
{{< /text >}}
You should see a line related to your request, similar to the following:
You should see a line similar to the following:
{{< text plain>}}
[2018-08-19T18:20:40.096Z] "GET / HTTP/1.1" 200 - 0 612 7 5 "172.30.146.114" "curl/7.35.0" "b942b587-fac2-9756-8ec6-303561356204" "nginx.example.com" "172.21.72.197:443"
{{< /text >}}
## Cleanup
1. Perform the instructions in the [Cleanup](/docs/examples/advanced-gateways/egress-gateway/#cleanup)
section of the [Configure an Egress Gateway](/docs/examples/advanced-gateways/egress-gateway) example.
### Cleanup the mutual TLS origination example
1. Remove created Kubernetes resources:
@ -541,7 +804,7 @@ to hold the configuration of the NGINX server:
$ kubectl delete destinationrule egressgateway-for-nginx
{{< /text >}}
1. Delete the directory of the certificates and the repository used to generate them:
1. Delete the directory of certificates and the repository used to generate them:
{{< text bash >}}
$ rm -rf nginx.example.com mtls-go-example
@ -553,9 +816,11 @@ to hold the configuration of the NGINX server:
$ rm -f ./nginx.conf ./istio-egressgateway.yaml
{{< /text >}}
1. Delete the `sleep` service and deployment:
## Cleanup
{{< text bash >}}
$ kubectl delete service sleep
$ kubectl delete deployment sleep
{{< /text >}}
Delete the `sleep` service and deployment:
{{< text bash >}}
$ kubectl delete service sleep
$ kubectl delete deployment sleep
{{< /text >}}

382
content/docs/examples/advanced-gateways/egress-gateway/index.md
View File

@ -1,28 +1,37 @@
---
title: Configure an Egress Gateway
description: Describes how to configure Istio to direct traffic to external services through a dedicated gateway.
weight: 43
weight: 30
keywords: [traffic-management,egress]
---
The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external (outside the Kubernetes cluster) HTTP and HTTPS services can be accessed from applications inside the mesh. A quick reminder: by default, Istio-enabled applications are unable to access URLs outside the cluster. To enable such access, a [service entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) for the external service must be defined, or, alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly) must be configured.
The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task shows how to configure
Istio to allow access to external HTTP and HTTPS services from applications inside the mesh.
There, the external services are called directly from the client sidecar.
This example also shows how to configure Istio to call external services, although this time
indirectly via a dedicated _egress gateway_ service.
The [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example demonstrates how to allow the applications to send HTTP requests to external servers that require HTTPS.
This example describes how to configure Istio to direct the egress traffic through a dedicated service called _Egress Gateway_. We achieve the same functionality as described in the [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example, only this time we accomplish it with the addition of an egress gateway.
Istio uses [ingress and egress gateways](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
to configure load balancers executing at the edge of a service mesh.
An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through.
Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow
you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.
## Use case
Consider an organization that has strict security requirements. According to these requirements all the traffic that leaves the service mesh must flow through a set of dedicated nodes. These nodes will run on dedicated machines, separately from the rest of the nodes used for running applications in the cluster. The special nodes will serve for policy enforcement on the egress traffic and will be monitored more thoroughly than the rest of the nodes.
Consider an organization that has a strict security requirement that all traffic leaving
the service mesh must flow through a set of dedicated nodes. These nodes will run on dedicated machines,
separated from the rest of the nodes running applications in the cluster. These special nodes will serve
for policy enforcement on the egress traffic and will be monitored more thoroughly than other nodes.
Istio 0.8 introduced the concept of [ingress and egress gateways](/docs/reference/config/istio.networking.v1alpha3/#Gateway). Ingress gateways allow one to define entrance points into the service mesh that all incoming traffic flows through. _Egress gateway_ is a symmetrical concept, it defines exit points for the mesh. An egress gateway allows Istio features, for example, monitoring and route rules, to be applied to traffic exiting the mesh.
Another use case is a cluster where the application nodes do not have public IPs, so the in-mesh services that run on them cannot access the Internet. Defining an egress gateway, directing all the egress traffic through it and allocating public IPs to the egress gateway nodes allows the application nodes to access external services in a controlled way.
Another use case is a cluster where the application nodes don't have public IPs, so the in-mesh services that run
on them cannot access the Internet. Defining an egress gateway, directing all the egress traffic through it, and
allocating public IPs to the egress gateway nodes allows the application nodes to access external services in a
controlled way.
## Before you begin
* Setup Istio by following the instructions in the
[Installation guide](/docs/setup/).
* Setup Istio by following the instructions in the [Installation guide](/docs/setup/).
* Start the [sleep]({{< github_tree >}}/samples/sleep) sample
which will be used as a test source for external calls.
@ -42,15 +51,15 @@ Another use case is a cluster where the application nodes do not have public IPs
Note that any pod that you can `exec` and `curl` from would do.
* Create a shell variable to hold the name of the source pod for sending requests to external services.
If we used the [sleep]({{<github_tree>}}/samples/sleep) sample, we run:
If you used the [sleep]({{<github_tree>}}/samples/sleep) sample, run:
{{< text bash >}}
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
{{< /text >}}
## Define an egress `Gateway` and direct HTTP traffic through it
## Egress gateway for HTTP traffic
First direct HTTP traffic without TLS origination
First create a `ServiceEntry` to allow direct traffic to an external service.
1. Define a `ServiceEntry` for `edition.cnn.com`:
@ -74,7 +83,7 @@ First direct HTTP traffic without TLS origination
EOF
{{< /text >}}
1. Verify that your `ServiceEntry` was applied correctly. Send an HTTPS request to [http://edition.cnn.com/politics](http://edition.cnn.com/politics).
1. Verify that your `ServiceEntry` was applied correctly by sending an HTTP request to [http://edition.cnn.com/politics](http://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
@ -91,16 +100,20 @@ First direct HTTP traffic without TLS origination
{{< /text >}}
The output should be the same as in the
[TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example, without TLS
origination.
[TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example,
without TLS origination.
1. Create an egress `Gateway` for _edition.cnn.com_, port 80, and destination rules and virtual services to
direct the traffic through the egress gateway and from the egress gateway to the external service.
1. Create an egress `Gateway` for _edition.cnn.com_, port 80, and a destination rule for
traffic directed to the egress gateway.
If you have [mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio, use the following
command.
Choose the instructions corresponding to whether or not you have
[mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio.
{{< text bash >}}
{{< tabset cookie-name="mtls" >}}
{{% tab name="mTLS enabled" cookie-value="enabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
@ -140,11 +153,13 @@ First direct HTTP traffic without TLS origination
mode: ISTIO_MUTUAL
sni: edition.cnn.com
EOF
{{< /text >}}
{{< /text >}}
otherwise:
{{% /tab %}}
{{< text bash >}}
{{% tab name="mTLS disabled" cookie-value="disabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
@ -170,9 +185,14 @@ First direct HTTP traffic without TLS origination
subsets:
- name: cnn
EOF
{{< /text >}}
{{< /text >}}
1. Define a `VirtualService` to direct the traffic through the egress gateway:
{{% /tab %}}
{{< /tabset >}}
1. Define a `VirtualService` to direct traffic from the sidecars to the egress gateway and from the egress gateway
to the external service:
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -229,21 +249,23 @@ First direct HTTP traffic without TLS origination
The output should be the same as in the step 2.
1. Check the log of the `istio-egressgateway` pod and see a line corresponding to our request. If Istio is deployed in the `istio-system` namespace, the command to print the log is:
1. Check the log of the `istio-egressgateway` pod for a line corresponding to our request.
If Istio is deployed in the `istio-system` namespace, the command to print the log is:
{{< text bash >}}
$ kubectl logs $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') egressgateway -n istio-system | tail
{{< /text >}}
We should see a line related to our request, similar to the following:
You should see a line similar to the following:
{{< text plain >}}
[2018-06-14T11:46:23.596Z] "GET /politics HTTP/2" 301 - 0 0 3 1 "172.30.146.87" "curl/7.35.0" "ab7be694-e367-94c5-83d1-086eca996dae" "edition.cnn.com" "151.101.193.67:80"
{{< /text >}}
Note that we redirected only the traffic from the port 80 to the egress gateway, the HTTPS traffic to the port 443 went directly to _edition.cnn.com_.
Note that you only redirected the traffic from port 80 to the egress gateway. The HTTPS traffic to port 443
went directly to _edition.cnn.com_.
### Cleanup of the egress gateway for HTTP traffic
### Cleanup HTTP gateway
Remove the previous definitions before proceeding to the next step:
@ -254,222 +276,10 @@ $ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-cnn
{{< /text >}}
## Perform TLS origination with the egress `Gateway`
Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example. Note that in this case the TLS origination will
be done by the egress Gateway server, as opposed to by the sidecar in the previous example.
1. Define a `ServiceEntry` for `edition.cnn.com`:
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: http-port-for-tls-origination
protocol: HTTP
resolution: DNS
EOF
{{< /text >}}
1. Verify that your `ServiceEntry` was applied correctly. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
location: https://edition.cnn.com/politics
...
command terminated with exit code 35
{{< /text >}}
The output should be contain _301 Moved Permanently_, if you see it, your `ServiceEntry` was configured correctly.
The exit code _35_ is due to the fact that Istio did not perform TLS origination. The egress gateway will perform
TLS origination, proceed to the following steps to configure it.
1. Create an egress `Gateway` for _edition.cnn.com_, port 443, and destination rules and virtual services to
direct the traffic through the egress gateway and from the egress gateway to the external service.
If you have [mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio, use the following
command.
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- edition.cnn.com
tls:
mode: MUTUAL
serverCertificate: /etc/certs/cert-chain.pem
privateKey: /etc/certs/key.pem
caCertificates: /etc/certs/root-cert.pem
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
sni: edition.cnn.com
EOF
{{< /text >}}
otherwise:
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: http-port-for-tls-origination
protocol: HTTP
hosts:
- edition.cnn.com
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
EOF
{{< /text >}}
1. Define a `VirtualService` to direct the traffic through the egress gateway, and a `DestinationRule` to perform TLS
origination:
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-tls-for-edition-cnn-com
spec:
host: edition.cnn.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com
EOF
{{< /text >}}
1. Send an HTTP request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 200 OK
...
content-length: 150793
...
{{< /text >}}
The output should be the same as in the [TLS Origination for Egress Traffic](/docs/examples/advanced-gateways/egress-tls-origination/) example, with TLS origination: without the _301 Moved Permanently_ message.
1. Check the log of the `istio-egressgateway` pod and see a line corresponding to our request. If Istio is deployed in the `istio-system` namespace, the command to print the log is:
{{< text bash >}}
$ kubectl logs $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') egressgateway -n istio-system | tail
{{< /text >}}
We should see a line related to our request, similar to the following:
{{< text plain>}}
"[2018-06-14T13:49:36.340Z] "GET /politics HTTP/1.1" 200 - 0 148528 5096 90 "172.30.146.87" "curl/7.35.0" "c6bfdfc3-07ec-9c30-8957-6904230fd037" "edition.cnn.com" "151.101.65.67:443"
{{< /text >}}
### Cleanup of the egress gateway for TLS origination
Remove the Istio configuration items we created:
{{< text bash >}}
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule originate-tls-for-edition-cnn-com
$ kubectl delete destinationrule egressgateway-for-cnn
{{< /text >}}
## Direct HTTPS traffic through an egress gateway
## Egress gateway for HTTPS traffic
In this section you direct HTTPS traffic (TLS originated by the application) through an egress gateway.
You specify the port 443, protocol `TLS` in the corresponding `ServiceEntry`, egress `Gateway` and `VirtualService`.
You need to specify port 443 with protocol `TLS` in a corresponding `ServiceEntry`, an egress `Gateway` and a `VirtualService`.
1. Define a `ServiceEntry` for `edition.cnn.com`:
@ -490,8 +300,7 @@ You specify the port 443, protocol `TLS` in the corresponding `ServiceEntry`, eg
EOF
{{< /text >}}
1. Verify that your `ServiceEntry` was applied correctly. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
The output should be the same as in the previous section.
1. Verify that your `ServiceEntry` was applied correctly by sending an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
@ -502,13 +311,17 @@ The output should be the same as in the previous section.
...
{{< /text >}}
1. Create an egress `Gateway` for _edition.cnn.com_, port 443, protocol TLS, and destination rules and virtual services
1. Create an egress `Gateway` for _edition.cnn.com_, a destination rule and a virtual service
to direct the traffic through the egress gateway and from the egress gateway to the external service.
If you have [mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio, use the following
command.
Choose the instructions corresponding to whether or not you have
[mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio.
{{< text bash >}}
{{< tabset cookie-name="mtls" >}}
{{% tab name="mTLS enabled" cookie-value="enabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
@ -583,11 +396,13 @@ The output should be the same as in the previous section.
number: 443
weight: 100
EOF
{{< /text >}}
{{< /text >}}
otherwise:
{{% /tab %}}
{{< text bash >}}
{{% tab name="mTLS disabled" cookie-value="disabled" %}}
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
@ -651,9 +466,14 @@ The output should be the same as in the previous section.
number: 443
weight: 100
EOF
{{< /text >}}
{{< /text >}}
1. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics). The output should be the same as previously.
{{% /tab %}}
{{< /tabset >}}
1. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
The output should be the same as before.
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
@ -664,7 +484,7 @@ The output should be the same as in the previous section.
...
{{< /text >}}
1. Check the statistics of the egress gateway's proxy and see a counter that corresponds to our
1. Check the statistics of the egress gateway's proxy which includes a counter that corresponds to our
requests to _edition.cnn.com_. If Istio is deployed in the `istio-system` namespace, the command to print the
counter is:
@ -673,10 +493,10 @@ The output should be the same as in the previous section.
cluster.outbound|443||edition.cnn.com.upstream_cx_total: 1
{{< /text >}}
You may want to perform a couple of additional requests and verify that the counter above grows by 1 with each
You may want to perform a couple of additional requests and verify that the counter increases by 1 with each
request.
### Cleanup of the egress gateway for HTTPS traffic
### Cleanup HTTPS gateway
{{< text bash >}}
$ kubectl delete serviceentry cnn
@ -687,16 +507,19 @@ $ kubectl delete destinationrule egressgateway-for-cnn
## Additional security considerations
Note that defining an egress `Gateway` in Istio does not in itself provides any special treatment for the nodes on which the egress gateway service runs. It is up to the cluster administrator or the cloud provider to deploy the egress gateways on dedicated nodes and to introduce additional security measures to make these nodes more secure than the rest of the mesh.
Note that defining an egress `Gateway` in Istio does not in itself provides any special treatment for the nodes
on which the egress gateway service runs. It is up to the cluster administrator or the cloud provider to deploy
the egress gateways on dedicated nodes and to introduce additional security measures to make these nodes more
secure than the rest of the mesh.
Istio *cannot securely enforce* that all the egress traffic actually flows through the egress gateways. Istio only
enables said flow through its sidecar proxies. If attackers bypass the sidecar proxy, they could directly access
Istio *cannot securely enforce* that all egress traffic actually flows through the egress gateways. Istio only
enables such flow through its sidecar proxies. If attackers bypass the sidecar proxy, they could directly access
external services without traversing the egress gateway. Thus, the attackers escape Istio's control and monitoring.
The cluster administrator or the cloud provider must ensure that no traffic leaves the mesh bypassing the egress
gateway. Mechanisms external to Istio must enforce this requirement. For example, a firewall can deny all traffic not
coming from the egress gateway. The
[Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) can also forbid
all the egress traffic not originating from the egress gateway (see
gateway. Mechanisms external to Istio must enforce this requirement. For example, the cluster administrator
can configure a firewall to deny all traffic not coming from the egress gateway.
The [Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) can
also forbid all the egress traffic not originating from the egress gateway (see
[the next section](#apply-kubernetes-network-policies) for an example).
Additionally, the cluster administrator or the cloud provider can configure the network to ensure application nodes can
only access the Internet via a gateway. To do this, the cluster administrator or the cloud provider can prevent the
@ -705,13 +528,14 @@ the egress gateways.
## Apply Kubernetes network policies
In this section you create a
This section shows you how to create a
[Kubernetes network policy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) to prevent
bypassing the egress gateway. To test the network policy, you create a namespace, namely `test-egress`, and deploy
to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
bypassing of the egress gateway. To test the network policy, you create a namespace, `test-egress`, deploy
the [sleep]({{< github_tree >}}/samples/sleep) sample to it, and then attempt to send requests to a gateway-secured
external service.
1. Follow the steps in the
[Direct HTTPS traffic through an egress gateway](#direct-https-traffic-through-an-egress-gateway) section.
[Egress gateway for HTTPS traffic](#egress-gateway-for-https-traffic) section.
1. Create the `test-egress` namespace:
@ -733,7 +557,7 @@ to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
sleep-776b7bcdcd-z7mc4 1/1 Running 0 18m
{{< /text >}}
1. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics) from the `sleep` pod in
1. Send an HTTPS request to [https://edition.cnn.com/politics](https://edition.cnn.com/politics) from the `sleep` pod in
the `test-egress` namespace. The request will succeed since you did not define any restrictive policies yet.
{{< text bash >}}
@ -782,7 +606,7 @@ to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
EOF
{{< /text >}}
1. Resend the previous HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics). Now it
1. Resend the previous HTTPS request to [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Now it
should fail since the traffic is blocked by the network policy. Note that the `sleep` pod cannot bypass
`istio-egressgateway`. The only way it can access `edition.cnn.com` is by using an Istio sidecar proxy and by
directing the traffic to `istio-egressgateway`. This setting demonstrates that even if some malicious pod manages to
@ -824,7 +648,7 @@ to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
sleep istio-proxy
{{< /text >}}
1. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics). Now it should succeed
1. Send an HTTPS request to [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Now it should succeed
since the traffic flows to `istio-egressgateway` in the `istio-system` namespace, which is allowed by the
Network Policy you defined. `istio-egressgateway` forwards the traffic to `edition.cnn.com`.
@ -842,7 +666,7 @@ to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
{{< /text >}}
### Cleanup of the network policies
### Cleanup network policies
1. Delete the resources created in this section:
@ -854,16 +678,14 @@ to it the [sleep]({{< github_tree >}}/samples/sleep) sample.
$ kubectl delete namespace test-egress
{{< /text >}}
1. Perform the [Cleanup](#cleanup-of-the-egress-gateway-for-https-traffic) part of
[Direct HTTPS traffic through an egress gateway](#direct-https-traffic-through-an-egress-gateway) section
1. Follow the steps in the [Cleanup HTTPS gateway](#cleanup-https-gateway) section.
## Troubleshooting
1. Check if you have [mutual TLS Authentication](/docs/tasks/security/mutual-tls/) enabled in Istio, following the
steps in
[Verify mutual TLS configuration](/docs/tasks/security/mutual-tls/#verify-mutual-tls-configuration).
If mutual TLS is enabled, make sure you create the configuration
items accordingly (note the remarks _If you have mutual TLS Authentication enabled in Istio, you must create..._).
steps in [Verify mutual TLS configuration](/docs/tasks/security/mutual-tls/#verify-mutual-tls-configuration).
If mutual TLS is enabled, make sure you create the configuration
items accordingly (note the remarks _If you have mutual TLS Authentication enabled in Istio, you must create..._).
1. If [mutual TLS Authentication](/docs/tasks/security/mutual-tls/) is enabled, verify the correct certificate of the
egress gateway:

2
content/docs/examples/advanced-gateways/egress-tls-origination/index.md
View File

@ -2,7 +2,7 @@
title: TLS Origination for Egress Traffic
description: Describes how to configure Istio to perform TLS origination for traffic to external services.
keywords: [traffic-management,egress]
weight: 42
weight: 20
---
The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external, i.e., outside of the

6
content/docs/examples/advanced-gateways/ingress-sni-passthrough/index.md
View File

@ -1,7 +1,7 @@
---
title: Ingress gateway without TLS termination
title: Ingress Gateway without TLS Termination
description: Describes how to configure SNI passthrough for an ingress gateway.
weight: 31
weight: 10
keywords: [traffic-management,ingress, https]
---
@ -33,7 +33,7 @@ Generate the certificates and keys in the same way as in the [Securing Gateways
Use any password with the following command:
{{< text bash >}}
$ ./generate.sh nginx.example.com <password>
$ ./generate.sh nginx.example.com password
{{< /text >}}
When prompted, select `y` for all the questions.

8
content/docs/examples/advanced-gateways/wildcard-https-egress-gateway/index.md
View File

@ -2,12 +2,12 @@
title: Configure Egress Gateway for HTTPS traffic to wildcarded domains
description: Use an SNI proxy in addition to the Envoy instance in the istio-egressgateway for wildcarded domains.
keywords: [traffic-management,egress]
weight: 44
weight: 50
---
The [Configure an Egress Gateway](/docs/examples/advanced-gateways/egress-gateway/) example, the
[Direct HTTPS traffic through an egress gateway](/docs/examples/advanced-gateways/egress-gateway/#direct-https-traffic-through-an-egress-gateway)
section described how to configure an Istio egress gateway for HTTPS traffic for specific hostnames, like
The [Configure an Egress Gateway](/docs/examples/advanced-gateways/egress-gateway/) example, in the
[Egress gateway for HTTPS traffic](/docs/examples/advanced-gateways/egress-gateway/#egress-gateway-for-https-traffic)
section, described how to configure an Istio egress gateway for HTTPS traffic for specific hostnames, like
`edition.cnn.com`. This example explains how to enable an egress gateway for HTTPS traffic to a set of domains, for
example to `*.wikipedia.org`, without the need to specify each and every host.