mirror of https://github.com/istio/istio.io.git
A few more improvements to TLS origination example (#2826)
* Improve example subsection titles * simplify tls origination example * A few more tweaks
This commit is contained in:
parent
9481a38d6d
commit
770bc421b5
|
|
@ -12,17 +12,19 @@ a [`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntr
|
||||||
defined, or alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly)
|
defined, or alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly)
|
||||||
must be configured.
|
must be configured.
|
||||||
|
|
||||||
This example describes how to configure Istio to perform [TLS origination](/help/glossary/#tls-origination)
|
This example shows how to configure Istio to perform [TLS origination](/help/glossary/#tls-origination)
|
||||||
for traffic to an external service.
|
for traffic to an external service. Istio will open HTTPS connections to the external service while the original
|
||||||
|
traffic is HTTP.
|
||||||
|
|
||||||
## Use case
|
## Use case
|
||||||
|
|
||||||
Consider a legacy application that performs HTTP calls to external sites. Suppose the organization that operates the
|
Consider a legacy application that performs HTTP calls to external sites. Suppose the organization that operates the
|
||||||
application receives a new requirement which states that all the external traffic must be encrypted. With Istio,
|
application receives a new requirement which states that all the external traffic must be encrypted. With Istio,
|
||||||
this requirement can be achieved just by configuration, without changing the code of the application.
|
this requirement can be achieved just by configuration, without changing any code in the application.
|
||||||
|
The application can send unencrypted HTTP requests and Istio will then encrypt them for the application.
|
||||||
|
|
||||||
In this example, you configure Istio to open HTTPS connections to external services while the original traffic is
|
Another benefit of sending unencrypted HTTP requests from the source, and letting Istio perform the TLS upgrade,
|
||||||
HTTP. The application will send unencrypted HTTP requests and Istio will then encrypt the requests for the application.
|
is that Istio can produce better telemetry and provide more routing control for requests that are not encrypted.
|
||||||
|
|
||||||
## Before you begin
|
## Before you begin
|
||||||
|
|
||||||
|
|
@ -54,7 +56,7 @@ HTTP. The application will send unencrypted HTTP requests and Istio will then en
|
||||||
## Configuring access to an external service
|
## Configuring access to an external service
|
||||||
|
|
||||||
First start by configuring access to an external service, `edition.cnn.com`,
|
First start by configuring access to an external service, `edition.cnn.com`,
|
||||||
using the same technique as shown in the [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task.
|
using the same technique shown in the [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task.
|
||||||
This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS access to the service.
|
This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS access to the service.
|
||||||
|
|
||||||
1. Create a `ServiceEntry` and `VirtualService` to enable access to `edition.cnn.com`:
|
1. Create a `ServiceEntry` and `VirtualService` to enable access to `edition.cnn.com`:
|
||||||
|
|
@ -119,17 +121,17 @@ This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS ac
|
||||||
Notice the `-L` flag of _curl_ which instructs _curl_ to follow redirects.
|
Notice the `-L` flag of _curl_ which instructs _curl_ to follow redirects.
|
||||||
In this case, the server returned a redirect response ([301 Moved Permanently](https://tools.ietf.org/html/rfc2616#section-10.3.2))
|
In this case, the server returned a redirect response ([301 Moved Permanently](https://tools.ietf.org/html/rfc2616#section-10.3.2))
|
||||||
for the HTTP request to `http://edition.cnn.com/politics`.
|
for the HTTP request to `http://edition.cnn.com/politics`.
|
||||||
The redirect response instructed the client to send an additional request, this time by HTTPS, to `https://edition.cnn.com/politics`.
|
The redirect response instructs the client to send an additional request, this time using HTTPS, to `https://edition.cnn.com/politics`.
|
||||||
For the second request, the server returned the requested content and a _200 OK_ status code.
|
For the second request, the server returned the requested content and a _200 OK_ status code.
|
||||||
|
|
||||||
Although the _curl_ command handled the redirection transparently, there are two issues here.
|
Although the _curl_ command handled the redirection transparently, there are two issues here.
|
||||||
The first issue is the redundant first request, which doubles the latency of fetching the content of `http://edition.cnn.com/politics`.
|
The first issue is the redundant request, which doubles the latency of fetching the content of `http://edition.cnn.com/politics`.
|
||||||
The second issue is that the path of the URL, _politics_ in this case, is sent in clear text.
|
The second issue is that the path of the URL, _politics_ in this case, is sent in clear text.
|
||||||
If there is an attacker who sniffs the communication between your application and `edition.cnn.com`,
|
If there is an attacker who sniffs the communication between your application and `edition.cnn.com`,
|
||||||
the attacker would know which specific topics and articles of `edition.cnn.com` your application fetched.
|
the attacker would know which specific topics of `edition.cnn.com` the application fetched.
|
||||||
For privacy reasons, you might want to prevent such disclosure.
|
For privacy reasons, you might want to prevent such disclosure.
|
||||||
|
|
||||||
In the following section, you configure Istio to perform TLS origination to resolve these two issues.
|
Both of these issues can be resolved by configuring Istio to perform TLS origination.
|
||||||
|
|
||||||
## TLS origination for egress traffic
|
## TLS origination for egress traffic
|
||||||
|
|
||||||
|
|
@ -187,8 +189,10 @@ In the following section, you configure Istio to perform TLS origination to reso
|
||||||
EOF
|
EOF
|
||||||
{{< /text >}}
|
{{< /text >}}
|
||||||
|
|
||||||
Notice that unlike the `ServiceEntry` in the previous section, the protocol on port 433 is HTTP, instead of HTTPS.
|
As you can see, the `VirtualService` redirects HTTP requests on port 80 to port 443 where the corresponding
|
||||||
This is because clients will send HTTP requests and Istio will perform TLS origination for them.
|
`DestinationRule` then performs the TLS origination.
|
||||||
|
Notice that unlike the `ServiceEntry` in the previous section, this time the protocol on port 433 is HTTP, instead of HTTPS.
|
||||||
|
This is because clients will only send HTTP requests and Istio will upgrade the connection to HTTPS.
|
||||||
|
|
||||||
1. Send an HTTP request to `http://edition.cnn.com/politics`, as in the previous section:
|
1. Send an HTTP request to `http://edition.cnn.com/politics`, as in the previous section:
|
||||||
|
|
||||||
|
|
@ -213,17 +217,17 @@ In the following section, you configure Istio to perform TLS origination to reso
|
||||||
|
|
||||||
## Additional security considerations
|
## Additional security considerations
|
||||||
|
|
||||||
Note that the traffic between the application pod and the sidecar proxy on the local host is still unencrypted.
|
Because the traffic between the application pod and the sidecar proxy on the local host is still unencrypted,
|
||||||
This means that if an attacker was able to penetrate the node of your application, they would still be able to see
|
an attacker that is able to penetrate the node of your application would still be able to see the unencrypted
|
||||||
the unencrypted communication on the local network of the node. In some environments a strict security requirement
|
communication on the local network of the node. In some environments a strict security requirement
|
||||||
might exist that would state that all the traffic must be encrypted, even on the local network of the nodes.
|
might state that all the traffic must be encrypted, even on the local network of the nodes.
|
||||||
With such a strict requirement the applications should use HTTPS (TLS) only, the TLS origination described in this
|
With such a strict requirement, applications should use HTTPS (TLS) only. The TLS origination described in this
|
||||||
example will not be sufficient.
|
example would not be sufficient.
|
||||||
|
|
||||||
Also note that even for HTTPS originated by the application, the attacker could know that the requests to `edition.cnn.com`
|
Also note that even with HTTPS originated by the application, an attacker could know that requests to `edition.cnn.com`
|
||||||
are being sent, by inspecting [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication).
|
are being sent by inspecting [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication).
|
||||||
The _SNI_ field is sent unencrypted during the TLS handshake. Using HTTPS prevents the attackers from knowing specific
|
The _SNI_ field is sent unencrypted during the TLS handshake. Using HTTPS prevents the attackers from knowing specific
|
||||||
topics and articles, it does not prevent the attackers from learning that `edition.cnn.com` is accessed.
|
topics and articles but does not prevent an attackers from learning that `edition.cnn.com` is accessed.
|
||||||
|
|
||||||
## Cleanup
|
## Cleanup
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -86,8 +86,9 @@ from within your Istio cluster. This task shows you how to access an external HT
|
||||||
|
|
||||||
### Configuring an external HTTPS service
|
### Configuring an external HTTPS service
|
||||||
|
|
||||||
1. Create a `ServiceEntry` and a `VirtualService` to allow access to an external HTTPS service. Note that for TLS
|
1. Create a `ServiceEntry` to allow access to an external HTTPS service.
|
||||||
protocols, including HTTPS, a `VirtualService` is required in addition to the `ServiceEntry`.
|
For TLS protocols, including HTTPS, a `VirtualService` is required in addition to the `ServiceEntry`.
|
||||||
|
Without it, exactly what service or services are exposed by the `ServiceEntry` is undefined.
|
||||||
The `VirtualService` must include a `tls` rule with `sni_hosts` in the `match` clause to enable SNI routing.
|
The `VirtualService` must include a `tls` rule with `sni_hosts` in the `match` clause to enable SNI routing.
|
||||||
|
|
||||||
{{< text bash >}}
|
{{< text bash >}}
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue