zh-translation:/docs/tasks/security/mutual-tls/index.md (#5540)

* zh-translation:/docs/tasks/security/mutual-tls/index.md * fix lint_istio.io error: authn-policy path & faq ref link
2019-11-10 10:49:52 +08:00 · 2019-11-10 10:49:52 +08:00 · 4055f1902e
parent ff16e5f477
commit 4055f1902e
2 changed files with 54 additions and 58 deletions
--- a/content/zh/docs/tasks/security/mutual-tls/index.md
+++ b/content/zh/docs/tasks/security/mutual-tls/index.md
@ -1,27 +1,27 @@
 ---
-title: Mutual TLS Deep-Dive
-description: Shows you how to verify and test Istio's automatic mutual TLS authentication.
+title: 深入了解双向 TLS
+description: 对 Istio 双向 TLS 认证功能进行体验和测试。
 weight: 10
 keywords: [security,mutual-tls]
 ---

-Through this task, you can have closer look at mutual TLS and learn its settings. This task assumes:
+通过本任务，你可以进一步了解双向 TLS 以及如何配置。本任务假设：

-* You have completed the [authentication policy](/docs/tasks/security/authentication/authn-policy/) task.
-* You are familiar with using authentication policy to enable mutual TLS.
-* Istio runs on Kubernetes with global mutual TLS enabled. You can follow our [instructions to install Istio](/docs/setup/).
-If you already have Istio installed, you can add or modify authentication policies and destination rules to enable mutual TLS as described in this [task](/docs/tasks/security/authentication/authn-policy/#globally-enabling-istio-mutual-tls).
-* You have deployed the [httpbin]({{< github_tree >}}/samples/httpbin) and [sleep]({{< github_tree >}}/samples/sleep) with Envoy sidecar in the `default` namespace. For example, below is the command to deploy those services with [manual sidecar injection](/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection):
+* 您已经完成[认证策略](/zh/docs/tasks/security/authn-policy/) 任务.
+* 您熟悉如何通过认证策略开启双向 TLS。
+* Istio 在 Kubernetes 上运行，并且开启全局双向 TLS。可以按照 [Istio 安装说明文档](/zh/docs/setup/))。
+如果已经安装了 Istio，可以根据[为所有服务启用双向 TLS 认证](/zh/docs/tasks/security/authn-policy/#globally-enabling-istio-mutual-tls) 任务中说明，通过增加或者修改认证策略和目的规则来开启双向 TLS。
+* [httpbin]({{< github_tree >}}/samples/httpbin) 和 [sleep]({{< github_tree >}}/samples/sleep) 已经部署在了 `default` namespace，并且这两个应用带有 Envoy sidecar. 例如，可以通过以下命令[手动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) 来完成服务的部署:

    {{< text bash >}}
    $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@)
    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
    {{< /text >}}

-## Verify Citadel runs properly
+## 检查 Citadel 是否运行正常{#verify-citadel-runs-properly}

-[Citadel](/docs/concepts/security/#pki) is Istio's key management service. Citadel must run properly for mutual TLS to work correctly. Verify the
-cluster-level Citadel runs properly with the following command:
+[Citadel](/zh/docs/concepts/security/#PKI) 是Istio 的密钥管理服务，它必须正常运行才能使双向 TLS 正常工作。
+使用以下命令验证 Citadel 在集群中是否正确运行：

 {{< text bash >}}
 $ kubectl get deploy -l istio=citadel -n istio-system
@ -29,11 +29,11 @@ NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 istio-citadel   1         1         1            1           1m
 {{< /text >}}

-Citadel is up if the "AVAILABLE" column is 1.
+如果 "AVAILABLE" 列值为 1，则说明 Citadel 已经成功运行。

-## Verify keys and certificates installation
+## 校验密钥和证书的安装情况{#verify-keys-and-certificates-installation}

-Istio automatically installs necessary keys and certificates for mutual TLS authentication in all sidecar containers. Run command below to confirm key and certificate files exist under `/etc/certs`:
+Istio 会为所有的 sidecar 容器自动安装双向 TLS 认证所必要的密钥和证书。运行以下命令，确认 `/etc/certs` 目录下存在密钥和证书文件：

 {{< text bash >}}
 $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.name}) -c istio-proxy -- ls /etc/certs
@ -43,12 +43,10 @@ root-cert.pem
 {{< /text >}}

 {{< tip >}}
-`cert-chain.pem` is Envoy's cert that needs to be presented to the other side. `key.pem` is Envoy's private key
-paired with Envoy's cert in `cert-chain.pem`. `root-cert.pem` is the root cert to verify the peer's cert.
-In this example, we only have one Citadel in a cluster, so all Envoys have the same `root-cert.pem`.
+`cert-chain.pem` 是 Envoy 的证书，会在需要的时候提供给对端。而 `key.pem` 就是 Envoy 的私钥，和 `cert-chain.pem` 中的证书相匹配。`root-cert.pem` 是用于证书校验的根证书。这个例子中，我们集群中只部署了一个 Citadel，所以所有的 Envoy 共用同一个 `root-cert.pem`。
 {{< /tip >}}

-Use the `openssl` tool to check if certificate is valid (current time should be in between `Not Before` and `Not After`)
+使用 `openssl` 工具来检查证书的有效性（当前时间应该介于 `Not Before` 和 `Not After` 之间）

 {{< text bash >}}
 $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.name}) -c istio-proxy -- cat /etc/certs/cert-chain.pem | openssl x509 -text -noout  | grep Validity -A 2
@ -57,7 +55,7 @@ Validity
        Not After : Aug 15 23:02:11 2018 GMT
 {{< /text >}}

-You can also check the _identity_ of the client certificate:
+也可以检查客户端证书的**身份**标示（SAN）：

 {{< text bash >}}
 $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.name}) -c istio-proxy -- cat /etc/certs/cert-chain.pem | openssl x509 -text -noout  | grep 'Subject Alternative Name' -A 1
@ -65,49 +63,48 @@ $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.na
            URI:spiffe://cluster.local/ns/default/sa/default
 {{< /text >}}

-Please check [Istio identity](/docs/concepts/security/#istio-identity) for more information about  _service identity_ in Istio.
+请参阅 [Istio 认证](/zh/docs/concepts/security/#istio-identity) 一节，可以了解更多**服务身份**方面的内容。

-## Verify mutual TLS configuration
+## 验证双向 TLS 配置{#verify-mutual-TLS-configuration}

-Use [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) to check if the mutual TLS settings are in effect. The `istioctl` command needs the client's pod because the destination rule depends on the client's namespace.
-You can also provide the destination service to filter the status to that service only.
+您可以按照 [`istioctl 检查 TLS 认证`](/zh/docs/reference/commands/istioctl/#istioctl-authn-tls-check) 检查双向 TLS 设置是否有效。`istioctl` 命令需要知道客户端 pod 名称，因为目标规则依赖客户端的 namespace。
+您也可以根据目标服务过滤只显示该服务的状态。

 {{< tip >}}
-This tool only checks the consistency of the static TLS settings between destination rules and authentication policies. It doesn't take into account whether or not the
-corresponding workloads have sidecars or not. When they don't, the policy and destination rules are not enforced, so note that status `CONFLICT` doesn't always mean that traffic is broken.
+这个工具只能检查目标规则与认证策略之间 TLS 设置的一致性，它并不能用于判断对应的负载中是否存在 sidecar。如果不存在 sidecar，认证策略和目标规则没有被执行，状态 `CONFLICT` 并不意味着流量被破坏。
 {{< /tip >}}

-The following commands identify the authentication policy for the `httpbin.default.svc.cluster.local` service and identify the destination rules for the service as seen from the same pod of the `sleep` app:
+下面的命令验证针对同一个`sleep` 应用 pod，`httpbin.default.svc.cluster.local` 服务的认证策略与目标规则相一致。

 {{< text bash >}}
 $ SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
 $ istioctl authn tls-check ${SLEEP_POD} httpbin.default.svc.cluster.local
 {{< /text >}}

-In the following example output you can see that:
+在以下示例输出中，您可以看到：

-* Mutual TLS is consistently setup for `httpbin.default.svc.cluster.local` on port 8000.
-* Istio uses the mesh-wide `default` authentication policy.
-* Istio has the `default` destination rule in the `istio-system` namespace.
+* 在 8080 端口上始终为 `httpbin.default.svc.cluster.local` 设置双向 TLS。
+* Istio 使用网格范围的 `default` 身份验证策略。
+* Istio 在 `istio-system` 命名空间中有 `default` 目的地规则。

 {{< text plain >}}
 HOST:PORT                                  STATUS     SERVER     CLIENT     AUTHN POLICY        DESTINATION RULE
 httpbin.default.svc.cluster.local:8000     OK         mTLS       mTLS       /default            istio-system/default
 {{< /text >}}

-The output shows:
+输出显示：

-* `STATUS`: whether the TLS settings are consistent between the server, the `httpbin` service in this case, and the client or clients making calls to `httpbin`.
+* `STATUS`：本例中的 `httpbin` 服务和调用 `httpbin` 的客户端之间的 TLS 设置是否一致。

-* `SERVER`: the mode used on the server.
+* `SERVER`：服务器上使用的模式。

-* `CLIENT`: the mode used on the client or clients.
+* `CLIENT`：所有客户端使用的模式。

-* `AUTHN POLICY`: the namespace and name of the authentication policy. If the policy is the mesh-wide policy, namespace is blank, as in this case: `/default`
+* `AUTHN POLICY`：身份验证策略的名称和命名空间。如果策略是网格范围的策略，则命名空间为空，如本例所示：`default/`

-* `DESTINATION RULE`: the namespace and name of the destination rule used.
+* `DESTINATION RULE`：使用的目标规则的名称和名称空间。

-To illustrate the case when there are conflicts, add a service-specific destination rule for `httpbin` with incorrect TLS mode:
+为了说明存在冲突的场景，为具有错误 TLS 模式的 `httpbin` 添加特定的服务目标规则：

 {{< text bash >}}
 $ cat <<EOF | kubectl apply -f -
@ -124,7 +121,7 @@ spec:
 EOF
 {{< /text >}}

-Run the same `istioctl` command as above, you now see the status is `CONFLICT`, as client is in `HTTP` mode while server is in `mTLS`.
+运行与上面相同的 `istioctl` 命令，您现在看到状态为 `CONFLICT` ，因为客户端处于 `HTTP` 模式，而服务器处于 `mTLS` 。

 {{< text bash >}}
 $ istioctl authn tls-check ${SLEEP_POD} httpbin.default.svc.cluster.local
@ -132,30 +129,30 @@ HOST:PORT                                  STATUS       SERVER     CLIENT     AU
 httpbin.default.svc.cluster.local:8000     CONFLICT     mTLS       HTTP       /default            default/bad-rule
 {{< /text >}}

-You can also confirm that requests from `sleep` to `httpbin` are now failing:
+您还可以确认从 `sleep` 到 `httpbin` 的请求现在已失败：

 {{< text bash >}}
 $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n'
 503
 {{< /text >}}

-Before you continue, remove the bad destination rule to make mutual TLS work again with the following command:
+在继续之前，请使用以下命令删除错误的目标规则以使双向 TLS 再次起作用：

 {{< text bash >}}
 $ kubectl delete destinationrule --ignore-not-found=true bad-rule
 {{< /text >}}

-## Verify requests
+## 验证请求{#verify-requests}

-This task shows how a server with mutual TLS enabled responses to requests that are:
+此任务演示已启用双向 TLS 的服务器如何对以下请求响应：

-* In plain-text
-* With TLS but without client certificate
-* With TLS with a client certificate
+* 使用明文请求中（即 HTTP 请求）
+* 使用 TLS 但没有客户端证书
+* 使用 TLS 和客户端证书

-To perform this task, you want to by-pass client proxy. A simplest way to do so is to issue request from `istio-proxy` container.
+要执行此任务，您需要绕过客户端代理。最简单的方法是从 `istio-proxy` 容器发出请求。

-1. Confirm that plain-text requests fail as TLS is required to talk to `httpbin` with the following command:
+1. 确认执行下面明文请求失败，因为调用 `httpbin` 服务需要 TLS 认证：

    {{< text bash >}}
    $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n'
@ -164,10 +161,10 @@ To perform this task, you want to by-pass client proxy. A simplest way to do so
    {{< /text >}}

    {{< tip >}}
-    Note that the exit code is 56. The code translates to a failure to receive network data.
+    请注意，退出代码为 56，代表无法接收网络数据。
    {{< /tip >}}

-1. Confirm TLS requests without client certificate also fail:
+1. 确认没有客户端证书的 TLS 请求也会失败：

    {{< text bash >}}
    $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl https://httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n' -k
@ -176,10 +173,10 @@ To perform this task, you want to by-pass client proxy. A simplest way to do so
    {{< /text >}}

    {{< tip >}}
-    This time the exit code is 35, which corresponds to a problem occurring somewhere in the SSL/TLS handshake.
+    这次，退出代码为 35，这对应于 SSL/TLS 握手中某处发生的问题。
    {{< /tip >}}

-1. Confirm TLS request with client certificate succeed:
+1. 确认使用客户端证书的 TLS 请求成功：

    {{< text bash >}}
    $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl https://httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n' --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem -k
@ -187,14 +184,13 @@ To perform this task, you want to by-pass client proxy. A simplest way to do so
    {{< /text >}}

 {{< tip >}}
-Istio uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) as service identity, which
-offers stronger security than service name (for more details, see [Istio identity](/docs/concepts/security/#istio-identity)). Thus, the certificates Istio uses do
-not have service names, which is the information that `curl` needs to verify server identity. To prevent the `curl` client from aborting, we use `curl`
-with the `-k` option. The option prevents the client from verifying and looking for the server name, for example, `httpbin.default.svc.cluster.local` in the
-certificate provided by the server.
+Istio 使用 [Kubernetes Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 作为服务标识，
+提供比服务名称更强的安全性（有关更多详细信息，请参阅 [Istio 身份](/zh/docs/concepts/security/#istio-identity)）。因此，Istio 使用的证书没有注明服务名称，
+但是 `curl` 需要利用这些信息验证服务器的身份。为了防止 `curl` 客户端报错，我们使用 `curl` 的 `-k` 参数。该参数可跳过客户端对服务器名称的验证，
+例如，`httpbin.default.svc.cluster.local` 服务器提供的证书。
 {{< /tip >}}

-## Cleanup
+## 清理{#cleanup}

 {{< text bash >}}
 $ kubectl delete --ignore-not-found=true -f @samples/httpbin/httpbin.yaml@
--- a/content/zh/faq/security/check-policy.md
+++ b/content/zh/faq/security/check-policy.md
@ -13,4 +13,4 @@ httpbin.default.svc.cluster.local:8000     OK         mTLS       mTLS       /def

 其中 `$CLIENT_POD` 是作为客户端服务运行的 pod 中的任意一个的 ID。

-请参见[验证双向 TLS 配置](/zh/docs/tasks/security/mutual-tls/#verify-mutual-tls-configuration)以获取更多细节。
+请参见[验证双向 TLS 配置](/zh/docs/tasks/security/mutual-tls/#verify-mutual-TLS-configuration)以获取更多细节。