zh-translation:/docs/tasks/traffic-management/egress/egress-tls-origination/index.md (#5631)

* translate docs #1366

* Update attribute.md

* 	修改:     zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md

* 	修改:     content/zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md

* Update index.md
This commit is contained in:
ExBs2724 2019-11-18 09:56:44 +08:00 committed by Istio Automation
parent fc85d7f9dd
commit 791b4d4c77
1 changed files with 55 additions and 72 deletions

View File

@ -1,64 +1,58 @@
--- ---
title: Egress TLS Origination title: Egress TLS Origination
description: Describes how to configure Istio to perform TLS origination for traffic to external services. description: 描述如何配置 Istio 对来自外部服务的流量执行 TLS 源。
keywords: [traffic-management,egress] keywords: [traffic-management,egress]
weight: 20 weight: 20
aliases: aliases:
- /zh/docs/examples/advanced-gateways/egress-tls-origination/ - /zh/docs/examples/advanced-gateways/egress-tls-origination/
--- ---
The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external, i.e., outside of the [控制 egress 流量](/zh/docs/tasks/traffic-management/egress/)的任务向我们展示了位于服务网格内部的应用应如何访问外部的网页、HTTP 和 HTTPS 服务。
service mesh, HTTP and HTTPS services can be accessed from applications inside the mesh. As described in that task, 正如该任务所述,[`ServiceEntry`](/zh/docs/reference/config/networking/service-entry/) 用于配置 Istio 以受控的方式访问外部服务。
a [`ServiceEntry`](/docs/reference/config/networking/service-entry/) is used to configure Istio 本示例将演示如何通过配置 Istio 去实现对外部流量的 {{< gloss >}}TLS origination{{< /gloss >}}。
to access external services in a controlled way. 若此时原始的流量为 HTTP则 Istio 会将其转换为 HTTPS 连接。
This example shows how to configure Istio to perform {{< gloss >}}TLS origination{{< /gloss >}}
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 假设有一个遗留应用正在使用 HTTP 和外部服务进行通信,而运行该应用的组织却收到了一个新的需求,该需求指出必须对所有外部的流量进行加密。
application receives a new requirement which states that all the external traffic must be encrypted. With Istio, 此时,使用 Istio 便可通过修改配置实现此需求,而无需更改应用中的任何代码。
this requirement can be achieved just by configuration, without changing any code in the application. 该应用可以发送未加密的 HTTP 请求,然后 Istio 将为应用加密请求。
The application can send unencrypted HTTP requests and Istio will then encrypt them for the application.
Another benefit of sending unencrypted HTTP requests from the source, and letting Istio perform the TLS upgrade, 从应用源头发送未加密的 HTTP 请求并让 Istio 执行 TSL 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。
is that Istio can produce better telemetry and provide more routing control for requests that are not encrypted.
## Before you begin ## 开始之前{#before-you-begin}
* Setup Istio by following the instructions in the [Installation guide](/docs/setup/). * 根据[安装指南](/zh/docs/setup/)中的说明部署 Istio。
* Start the [sleep]({{< github_tree >}}/samples/sleep) sample which will be used as a test source for external calls. * 启动 [sleep]({{< github_tree >}}/samples/sleep) 示例,该示例将用作外部调用的测试源。
If you have enabled [automatic sidecar injection](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), deploy the `sleep` application: 如果启用了 [Sidecar 的自动注入功能](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection),运行:
{{< text bash >}} {{< text bash >}}
$ kubectl apply -f @samples/sleep/sleep.yaml@ $ kubectl apply -f @samples/sleep/sleep.yaml@
{{< /text >}} {{< /text >}}
Otherwise, you have to manually inject the sidecar before deploying the `sleep` application: 否则在部署 `sleep` 应用之前,您必须手动注入 Sidecar。
{{< text bash >}} {{< text bash >}}
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
{{< /text >}} {{< /text >}}
Note that any pod that you can `exec` and `curl` from will do for the procedures below. 实际上任何可以 `exec``curl` 的 Pod 都可以用来完成这一任务。
* Create a shell variable to hold the name of the source pod for sending requests to external services. * 创建一个环境变量来保存用于将请求发送到外部服务的 pod 的名称。
If you used the [sleep]({{< github_tree >}}/samples/sleep) sample, run: 如果您使用 [sleep]({{< github_tree >}}/samples/sleep) 示例,请运行:
{{< text bash >}} {{< text bash >}}
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
{{< /text >}} {{< /text >}}
## Configuring access to an external service ## 配置对外部服务的访问{#configuring-access-to-an-external-service}
First start by configuring access to an external service, `edition.cnn.com`, 首先,使用与 [Egress 流量控制](/zh/docs/tasks/traffic-management/egress/)任务中的相同的技术,配置对外部服务 `edition.cnn.com` 的访问。
using the same technique shown in the [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task. 但这一次我们将使用单个 `ServiceEntry` 来启用对服务的 HTTPS 和 HTTPS 访问。
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. 创建一个 `ServiceEntry``VirtualService` 以启用对 `edition.cnn.com` 的访问:
{{< text bash >}} {{< text bash >}}
$ kubectl apply -f - <<EOF $ kubectl apply -f - <<EOF
@ -99,7 +93,7 @@ This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS ac
EOF EOF
{{< /text >}} {{< /text >}}
1. Make a request to the external HTTP service: 1. 向外部的 HTTP 服务发送请求:
{{< text bash >}} {{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
@ -115,27 +109,23 @@ This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS ac
... ...
{{< /text >}} {{< /text >}}
The output should be similar to the above (some details replaced by ellipsis). 输出应与上面类似(某些细节用省略号代替)。
Notice the `-L` flag of _curl_ which instructs _curl_ to follow redirects. 请注意 _curl_`-L` 标志,该标志指示 _curl_ 将遵循重定向。
In this case, the server returned a redirect response ([301 Moved Permanently](https://tools.ietf.org/html/rfc2616#section-10.3.2)) 在这种情况下,服务器将把 HTTP 请求的重定向响应([301 Moved Permanently](https://tools.ietf.org/html/rfc2616#section-10.3.2))返回到 `http://edition.cnn.com/politics`
for the HTTP request to `http://edition.cnn.com/politics`. 而重定向响应将指示客户端使用 HTTPS 向 `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`. 对于第二个请求,服务器则返回了请求的内容和 _200 OK_ 状态码。
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. 尽管 _curl_ 命令简明地处理了重定向,但是这里有两个问题。
The first issue is the redundant request, which doubles the latency of fetching the content of `http://edition.cnn.com/politics`. 第一个问题是请求冗余,它使获取 `http://edition.cnn.com/politics` 内容的延迟加倍。
The second issue is that the path of the URL, _politics_ in this case, is sent in clear text. 第二个问题是 URL 中的路径(在本例中为 _politics_ )被以明文的形式发送。
If there is an attacker who sniffs the communication between your application and `edition.cnn.com`, 如果有人嗅探您的应用与 `edition.cnn.com` 之间的通信,他将会知晓该应用获取了此网站中哪些特定的内容。而出于隐私的原因,您可能希望阻止这些内容被披露。
the attacker would know which specific topics of `edition.cnn.com` the application fetched.
For privacy reasons, you might want to prevent such disclosure.
Both of these issues can be resolved by configuring Istio to perform TLS origination. 通过配置 `Istio` 执行 `TLS` 源,则可以解决这两个问题。
## TLS origination for egress traffic ## 用于 egress 流量的 TLS 源{#TLS-origination-for-egress-traffic}
1. Redefine your `ServiceEntry` and `VirtualService` from the previous section to rewrite the HTTP request port 1. 重新定义上一节的 `ServiceEntry``VirtualService` 以重写 HTTP 请求端口,并添加一个 `DestinationRule` 以执行 TLS 源。
and add a `DestinationRule` to perform TLS origination.
{{< text bash >}} {{< text bash >}}
$ kubectl apply -f - <<EOF $ kubectl apply -f - <<EOF
@ -188,12 +178,11 @@ Both of these issues can be resolved by configuring Istio to perform TLS origina
EOF EOF
{{< /text >}} {{< /text >}}
As you can see, the `VirtualService` redirects HTTP requests on port 80 to port 443 where the corresponding 如您所见 `VirtualService` 将 80 端口的请求重定向到 443 端口,并在相应的 `DestinationRule` 执行 TSL 源。
`DestinationRule` then performs the TLS origination. 请注意,与上一节中的 `ServiceEntry` 不同,这次 443 端口上的协议是 HTTP而不是 HTTPS。
Notice that unlike the `ServiceEntry` in the previous section, this time the protocol on port 443 is HTTP, instead of HTTPS. 这是因为客户端仅发送 HTTP 请求,而 Istio 会将连接升级到 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. 如上一节所述,向 `http://edition.cnn.com/politics` 发送 HTTP 请求:
{{< text bash >}} {{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
@ -204,33 +193,27 @@ Both of these issues can be resolved by configuring Istio to perform TLS origina
... ...
{{< /text >}} {{< /text >}}
This time you receive _200 OK_ as the first and the only response. Istio performed TLS origination for _curl_ so 您将会收到唯一的 _200 OK_ 响应。
the original HTTP request was forwarded to `edition.cnn.com` as HTTPS. The server returned the content directly, 因为 Istio 为 _curl_ 执行了 TSL 源,原始的 HTTP 被升级为 HTTPS 并转发到 `edition.cnn.com`
without the need for redirection. You eliminated the double round trip between the client and the server, and the 服务器直接返回内容而无需重定向。
request left the mesh encrypted, without disclosing the fact that your application fetched the _politics_ section 这消除了客户端与服务器之间的请求冗余,使网格保持加密状态,隐藏了您的应用获取 `edition.cnn.com`_politics_ 的事实。
of `edition.cnn.com`.
Note that you used the same command as in the previous section. For applications that access external services 请注意,您使用了一些与上一节相同的命令。
programmatically, the code does not need to be changed. You get the benefits of TLS origination by configuring Istio, 您可以通过配置 Istio使以编程方式访问外部服务的应用无需更改任何代码即可获得 TLS 源的好处。
without changing a line of code.
## Additional security considerations ## 其它安全注意事项{#additional-security-considerations}
Because the traffic between the application pod and the sidecar proxy on the local host is still unencrypted, 由于应用容器与本地 Host 上的 Sidecar 代理之间的流量仍未加密,能够渗透到您应用 Node 的攻击者仍然可以看到未加密 Node 本地网络上的通信。
an attacker that is able to penetrate the node of your application would still be able to see the unencrypted 在某些环境中,严格的安全性要求可能规定所有流量都必须加密,即使在 Node 的本地网络上也是如此。
communication on the local network of the node. In some environments a strict security requirement 此时,使用在此示例中描述的 TLS 源是不能满足要求的,应用应仅使用 HTTPSTLS而不是 HTTP。
might state that all the traffic must be encrypted, even on the local network of the nodes.
With such a strict requirement, applications should use HTTPS (TLS) only. The TLS origination described in this
example would not be sufficient.
Also note that even with HTTPS originated by the application, an attacker could know that requests to `edition.cnn.com` 还要注意,即使应用发起的是 HTTPS 请求,攻击者也可能会通过检查 [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) 知道客户端正在对 `edition.cnn.com` 发送请求。
are being sent by inspecting [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication). _SNI_ 字段在 TLS 握手过程中以未加密的形式发送。
The _SNI_ field is sent unencrypted during the TLS handshake. Using HTTPS prevents the attackers from knowing specific 使用 HTTPS 可以防止攻击者知道客户端访问了哪些特点的内容,但并不能阻止攻击者得知客户端访问了 `edition.cnn.com` 站点。
topics and articles but does not prevent an attackers from learning that `edition.cnn.com` is accessed.
## Cleanup ## 清除{#cleanup}
1. Remove the Istio configuration items you created: 1. 移除您创建的 Istio 配置项:
{{< text bash >}} {{< text bash >}}
$ kubectl delete serviceentry edition-cnn-com $ kubectl delete serviceentry edition-cnn-com
@ -238,7 +221,7 @@ topics and articles but does not prevent an attackers from learning that `editio
$ kubectl delete destinationrule edition-cnn-com $ kubectl delete destinationrule edition-cnn-com
{{< /text >}} {{< /text >}}
1. Shutdown the [sleep]({{< github_tree >}}/samples/sleep) service: 1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务:
{{< text bash >}} {{< text bash >}}
$ kubectl delete -f @samples/sleep/sleep.yaml@ $ kubectl delete -f @samples/sleep/sleep.yaml@