mirror of https://github.com/istio/istio.io.git
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
Istio Automation
parent
fc85d7f9dd
commit
791b4d4c77
|
|
@ -1,64 +1,58 @@
|
|||
---
|
||||
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]
|
||||
weight: 20
|
||||
aliases:
|
||||
- /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
|
||||
service mesh, HTTP and HTTPS services can be accessed from applications inside the mesh. As described in that task,
|
||||
a [`ServiceEntry`](/docs/reference/config/networking/service-entry/) is used to configure Istio
|
||||
to access external services in a controlled way.
|
||||
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.
|
||||
[控制 egress 流量](/zh/docs/tasks/traffic-management/egress/)的任务向我们展示了位于服务网格内部的应用应如何访问外部的网页、HTTP 和 HTTPS 服务。
|
||||
正如该任务所述，[`ServiceEntry`](/zh/docs/reference/config/networking/service-entry/) 用于配置 Istio 以受控的方式访问外部服务。
|
||||
本示例将演示如何通过配置 Istio 去实现对外部流量的 {{< gloss >}}TLS origination{{< /gloss >}}。
|
||||
若此时原始的流量为 HTTP，则 Istio 会将其转换为 HTTPS 连接。
|
||||
|
||||
## Use case
|
||||
## 案例{#use-case}
|
||||
|
||||
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,
|
||||
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.
|
||||
假设有一个遗留应用正在使用 HTTP 和外部服务进行通信，而运行该应用的组织却收到了一个新的需求，该需求指出必须对所有外部的流量进行加密。
|
||||
此时，使用 Istio 便可通过修改配置实现此需求，而无需更改应用中的任何代码。
|
||||
该应用可以发送未加密的 HTTP 请求，然后 Istio 将为应用加密请求。
|
||||
|
||||
Another benefit of sending unencrypted HTTP requests from the source, and letting Istio perform the TLS upgrade,
|
||||
is that Istio can produce better telemetry and provide more routing control for requests that are not encrypted.
|
||||
从应用源头发送未加密的 HTTP 请求并让 Istio 执行 TSL 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。
|
||||
|
||||
## 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 >}}
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Otherwise, you have to manually inject the sidecar before deploying the `sleep` application:
|
||||
否则在部署 `sleep` 应用之前，您必须手动注入 Sidecar。
|
||||
|
||||
{{< 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 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.
|
||||
If you used the [sleep]({{< github_tree >}}/samples/sleep) sample, run:
|
||||
* 创建一个环境变量来保存用于将请求发送到外部服务的 pod 的名称。
|
||||
如果您使用 [sleep]({{< github_tree >}}/samples/sleep) 示例，请运行：
|
||||
|
||||
{{< text bash >}}
|
||||
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
{{< /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`,
|
||||
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.
|
||||
首先，使用与 [Egress 流量控制](/zh/docs/tasks/traffic-management/egress/)任务中的相同的技术，配置对外部服务 `edition.cnn.com` 的访问。
|
||||
但这一次我们将使用单个 `ServiceEntry` 来启用对服务的 HTTPS 和 HTTPS 访问。
|
||||
|
||||
1. Create a `ServiceEntry` and `VirtualService` to enable access to `edition.cnn.com`:
|
||||
1. 创建一个 `ServiceEntry` 和 `VirtualService` 以启用对 `edition.cnn.com` 的访问：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -99,7 +93,7 @@ This time, however, use a single `ServiceEntry` to enable both HTTP and HTTPS ac
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. Make a request to the external HTTP service:
|
||||
1. 向外部的 HTTP 服务发送请求：
|
||||
|
||||
{{< text bash >}}
|
||||
$ 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 >}}
|
||||
|
||||
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.
|
||||
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`.
|
||||
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.
|
||||
请注意 _curl_ 的 `-L` 标志，该标志指示 _curl_ 将遵循重定向。
|
||||
在这种情况下，服务器将把 HTTP 请求的重定向响应([301 Moved Permanently](https://tools.ietf.org/html/rfc2616#section-10.3.2))返回到 `http://edition.cnn.com/politics`。
|
||||
而重定向响应将指示客户端使用 HTTPS 向 `https://edition.cnn.com/politics` 重新发送请求。
|
||||
对于第二个请求，服务器则返回了请求的内容和 _200 OK_ 状态码。
|
||||
|
||||
Although the _curl_ command handled the redirection transparently, there are two issues here.
|
||||
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.
|
||||
If there is an attacker who sniffs the communication between your application and `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.
|
||||
尽管 _curl_ 命令简明地处理了重定向，但是这里有两个问题。
|
||||
第一个问题是请求冗余，它使获取 `http://edition.cnn.com/politics` 内容的延迟加倍。
|
||||
第二个问题是 URL 中的路径（在本例中为 _politics_ ）被以明文的形式发送。
|
||||
如果有人嗅探您的应用与 `edition.cnn.com` 之间的通信，他将会知晓该应用获取了此网站中哪些特定的内容。而出于隐私的原因，您可能希望阻止这些内容被披露。
|
||||
|
||||
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
|
||||
and add a `DestinationRule` to perform TLS origination.
|
||||
1. 重新定义上一节的 `ServiceEntry` 和 `VirtualService` 以重写 HTTP 请求端口，并添加一个 `DestinationRule` 以执行 TLS 源。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -188,12 +178,11 @@ Both of these issues can be resolved by configuring Istio to perform TLS origina
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
As you can see, the `VirtualService` redirects HTTP requests on port 80 to port 443 where the corresponding
|
||||
`DestinationRule` then performs the TLS origination.
|
||||
Notice that unlike the `ServiceEntry` in the previous section, this time the protocol on port 443 is HTTP, instead of HTTPS.
|
||||
This is because clients will only send HTTP requests and Istio will upgrade the connection to HTTPS.
|
||||
如您所见 `VirtualService` 将 80 端口的请求重定向到 443 端口，并在相应的 `DestinationRule` 执行 TSL 源。
|
||||
请注意，与上一节中的 `ServiceEntry` 不同，这次 443 端口上的协议是 HTTP，而不是 HTTPS。
|
||||
这是因为客户端仅发送 HTTP 请求，而 Istio 会将连接升级到 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 >}}
|
||||
$ 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 >}}
|
||||
|
||||
This time you receive _200 OK_ as the first and the only response. Istio performed TLS origination for _curl_ so
|
||||
the original HTTP request was forwarded to `edition.cnn.com` as HTTPS. The server returned the content directly,
|
||||
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
|
||||
of `edition.cnn.com`.
|
||||
您将会收到唯一的 _200 OK_ 响应。
|
||||
因为 Istio 为 _curl_ 执行了 TSL 源，原始的 HTTP 被升级为 HTTPS 并转发到 `edition.cnn.com`。
|
||||
服务器直接返回内容而无需重定向。
|
||||
这消除了客户端与服务器之间的请求冗余，使网格保持加密状态，隐藏了您的应用获取 `edition.cnn.com` 中 _politics_ 的事实。
|
||||
|
||||
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,
|
||||
without changing a line of code.
|
||||
请注意，您使用了一些与上一节相同的命令。
|
||||
您可以通过配置 Istio，使以编程方式访问外部服务的应用无需更改任何代码即可获得 TLS 源的好处。
|
||||
|
||||
## Additional security considerations
|
||||
## 其它安全注意事项{#additional-security-considerations}
|
||||
|
||||
Because the traffic between the application pod and the sidecar proxy on the local host is still unencrypted,
|
||||
an attacker that is able to penetrate the node of your application would still be able to see the unencrypted
|
||||
communication on the local network of the node. In some environments a strict security requirement
|
||||
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.
|
||||
由于应用容器与本地 Host 上的 Sidecar 代理之间的流量仍未加密，能够渗透到您应用 Node 的攻击者仍然可以看到未加密 Node 本地网络上的通信。
|
||||
在某些环境中，严格的安全性要求可能规定所有流量都必须加密，即使在 Node 的本地网络上也是如此。
|
||||
此时，使用在此示例中描述的 TLS 源是不能满足要求的，应用应仅使用 HTTPS（TLS）而不是 HTTP。
|
||||
|
||||
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).
|
||||
The _SNI_ field is sent unencrypted during the TLS handshake. Using HTTPS prevents the attackers from knowing specific
|
||||
topics and articles but does not prevent an attackers from learning that `edition.cnn.com` is accessed.
|
||||
还要注意，即使应用发起的是 HTTPS 请求，攻击者也可能会通过检查 [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) 知道客户端正在对 `edition.cnn.com` 发送请求。
|
||||
_SNI_ 字段在 TLS 握手过程中以未加密的形式发送。
|
||||
使用 HTTPS 可以防止攻击者知道客户端访问了哪些特点的内容，但并不能阻止攻击者得知客户端访问了 `edition.cnn.com` 站点。
|
||||
|
||||
## Cleanup
|
||||
## 清除{#cleanup}
|
||||
|
||||
1. Remove the Istio configuration items you created:
|
||||
1. 移除您创建的 Istio 配置项:
|
||||
|
||||
{{< text bash >}}
|
||||
$ 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
|
||||
{{< /text >}}
|
||||
|
||||
1. Shutdown the [sleep]({{< github_tree >}}/samples/sleep) service:
|
||||
1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f @samples/sleep/sleep.yaml@
|
||||
|
|
|
|||
Loading…
Reference in New Issue