mirror of https://github.com/istio/istio.io.git
translation for Chinese tasks/security/citadel-config/auth-sds/index.md (#6111)
* translation for zh/docs/tasks/security/citadel-config/auth-sds/index.md * Update content/zh/docs/tasks/security/citadel-config/auth-sds/index.md accept Co-Authored-By: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com> * fix review issues for zh/docs/tasks/security/citadel-config/auth-sds/index.md * fix lint error for zh/docs/tasks/security/citadel-config/auth-sds/index.md
This commit is contained in:
helight
Istio Automation
parent
4f6a7be627
commit
5fc6ecdb61
|
|
@ -1,60 +1,47 @@
|
|||
---
|
||||
title: Provisioning Identity through SDS
|
||||
description: Shows how to enable SDS (secret discovery service) for Istio identity provisioning.
|
||||
title: 通过 SDS 进行身份认证
|
||||
description: Istio 中如何通过启用 SDS （密钥发现服务）来进行身份认证。
|
||||
weight: 30
|
||||
keywords: [security,auth-sds]
|
||||
aliases:
|
||||
- /zh/docs/tasks/security/auth-sds/
|
||||
---
|
||||
|
||||
This task shows how to enable
|
||||
[SDS (secret discovery service)](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration)
|
||||
for Istio identity provisioning.
|
||||
这个任务是讲述 Istio 中如何通过启动 [SDS（密钥发现服务）](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration)来进行身份认证的。
|
||||
|
||||
Prior to Istio 1.1, the keys and certificates of Istio workloads were generated
|
||||
by Citadel and distributed to sidecars through secret-volume mounted files,
|
||||
this approach has the following minor drawbacks:
|
||||
在 Istio 1.1 之前，Istio workload 的密钥和证书都是由 Citadel 生成的，并且通过挂载 secret-volume 文件的方式下发给 sidecar 上。
|
||||
这种做法有下面一些小缺陷：
|
||||
|
||||
* Performance regression during certificate rotation:
|
||||
When certificate rotation happens, Envoy is hot restarted to pick up the new
|
||||
key and certificate, causing performance regression.
|
||||
* 证书替换期间的性能下降问题：
|
||||
在证书替换的时候，Envoy 通过热重启来获取新的密钥和证书，这会导致性能下降。
|
||||
|
||||
* Potential security vulnerability:
|
||||
The workload private keys are distributed through Kubernetes secrets,
|
||||
with known
|
||||
[risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks).
|
||||
* 有潜在的安全风险：
|
||||
workload 提供的密钥是通过 Kubernetes 证书来下发的，可以看已知的[风险](https://kubernetes.io/docs/concepts/configuration/secret/#risks)。
|
||||
|
||||
These issues are addressed in Istio 1.1 through the SDS identity provision flow.
|
||||
The workflow can be described as follows.
|
||||
这些问题都在 Istio 1.1 中通过提供 SDS 身份认证解决了。
|
||||
整个过程可以描述如下：
|
||||
|
||||
1. The workload sidecar Envoy requests the key and certificates from the Citadel
|
||||
agent: The Citadel agent is a SDS server, which runs as per-node `DaemonSet`.
|
||||
In the request, Envoy passes a Kubernetes service account JWT to the agent.
|
||||
1. workload 边车 Envoy 向 Citadel 代理请求密钥和证书：Citadel 代理是一个 SDS 服务，作为每个节点上的 `DaemonSet` 运行。 Envoy 在请求时会传一个 Kubernetes 服务帐号的 JWT 到代理。
|
||||
|
||||
1. The Citadel agent generates a key pair and sends the CSR request to Citadel:
|
||||
Citadel verifies the JWT and issues the certificate to the Citadel agent.
|
||||
1. Citadel 代理产生密钥对并且发送 CSR 请求给 Citadel 服务：Citadel 服务验证收到的 JWT 并且向 Citadel 颁发证书。
|
||||
|
||||
1. The Citadel agent sends the key and certificate back to the workload sidecar.
|
||||
1. Citadel 代理发送回密钥和证书给到 workload 边车。
|
||||
|
||||
This approach has the following benefits:
|
||||
这样做有如下优势：
|
||||
|
||||
* The private key never leaves the node: It is only in the Citadel agent
|
||||
and Envoy sidecar's memory.
|
||||
* 私钥是永远不会离开节点的：只保存在 Citadel 代理上和 Envoy 边车的内存中。
|
||||
|
||||
* The secret volume mount is no longer needed: The reliance on the Kubernetes
|
||||
secrets is eliminated.
|
||||
* 再也不需要挂载密钥卷了：不在依赖 Kubernetes 的密钥。
|
||||
|
||||
* The sidecar Envoy is able to dynamically renew the key and certificate
|
||||
through the SDS API: Certificate rotations no longer require Envoy to restart.
|
||||
* Envoy 边车可以通过 SDS 的 API 动态的更新密钥和证书：证书的更换也不再需要重启 Envoy 了。
|
||||
|
||||
## Before you begin
|
||||
## 开始之前{## before-you-begin}
|
||||
|
||||
Follow the [Istio installation guide](/zh/docs/setup/install/helm/) to set up Istio with SDS and global mutual TLS enabled.
|
||||
参考[Istio 安装指南](/zh/docs/setup/install/helm/) 来设置启动 SDS 和全局双向 TLS 。
|
||||
|
||||
## Service-to-service mutual TLS using key/certificate provisioned through SDS
|
||||
## 通过 SDS 使用密钥/证书为服务到服务提供双向 TLS{## service-to-service-mutual-TLS-using key/certificate-provisioned-through-SDS}
|
||||
|
||||
Follow the [authentication policy task](/zh/docs/tasks/security/authentication/authn-policy/) to
|
||||
setup test services.
|
||||
参考[认证策略任务](/zh/docs/tasks/security/authentication/authn-policy/)来设置测试服务。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create ns foo
|
||||
|
|
@ -65,7 +52,7 @@ $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n
|
|||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
|
||||
{{< /text >}}
|
||||
|
||||
Verify all mutual TLS requests succeed:
|
||||
验证是否所有的双向 TLS 请求都已经成功：
|
||||
|
||||
{{< text bash >}}
|
||||
$ for from in "foo" "bar"; do for to in "foo" "bar"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
|
||||
|
|
@ -75,32 +62,25 @@ sleep.bar to httpbin.foo: 200
|
|||
sleep.bar to httpbin.bar: 200
|
||||
{{< /text >}}
|
||||
|
||||
## Verifying no secret-volume mounted file is generated
|
||||
## 验证看是不是没有生成密钥卷文件{## verifying-no-secret-volume-mounted-file-is-generated}
|
||||
|
||||
To verify that no secret-volume mounted file is generated, access the deployed
|
||||
workload sidecar container:
|
||||
下面来验证是不是没有生成密钥卷文件，先访问部署的 workload 边车容器：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec -it $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c istio-proxy -n foo -- /bin/bash
|
||||
{{< /text >}}
|
||||
|
||||
As you can see there is no secret file mounted at `/etc/certs` folder.
|
||||
你可以看到 `/etc/certs` 目录下没有挂载密钥文件。
|
||||
|
||||
## Securing SDS with pod security policies
|
||||
## 使用 pod 上的安全策略来保护 SDS {## securing-SDS-with-pod-security-policies}
|
||||
|
||||
The Istio Secret Discovery Service (SDS) uses the Citadel agent to distribute the certificate to the
|
||||
Envoy sidecar via a Unix domain socket. All pods running in the same Kubernetes node share the Citadel
|
||||
agent and Unix domain socket.
|
||||
Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套接字来给 Envoy 边车分发证书。 所有在同一个 Kubernetes 节点上的 pod 通过 Unix domain 套接字共享同一个 Citadel 代理。
|
||||
|
||||
To prevent unexpected modifications to the Unix domain socket, enable the [pod security policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
|
||||
to restrict the pod's permission on the Unix domain socket. Otherwise, a malicious user who has the
|
||||
permission to modify the deployment could hijack the Unix domain socket to break the SDS service or
|
||||
steal the identity credentials from other pods running on the same Kubernetes node.
|
||||
为了防止对 Unix domain 套接字的意外修改，需要启用[pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)来限制 pod 对 Unix domain 套接字的权限。否则，有权限修改 deployment 的恶意用户会劫持 Unix domain 套接字来断开 SDS 服务，或者会从运行在同一个 Kubernetes 节点上的其它 pod 那里偷取身份证书。
|
||||
|
||||
To enable the pod security policy, perform the following steps:
|
||||
可以通过执行以下步骤来启用 pod 安全策略：
|
||||
|
||||
1. The Citadel agent fails to start unless it can create the required Unix domain socket. Apply the
|
||||
following pod security policy to only allow the Citadel agent to modify the Unix domain socket:
|
||||
1. Citadel代理创建成功 Unix domain 套接字才能启动成功。通过实施下面的 pod 安全策略才能只启用 Citadel 代理对 Unix domain 套接字的修改权限。
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -153,13 +133,10 @@ To enable the pod security policy, perform the following steps:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. To stop other pods from modifying the Unix domain socket, change the `allowedHostPaths` configuration
|
||||
for the the path the Citadel agent uses for the Unix domain socket to `readOnly: true`.
|
||||
1. 要阻止其它 pod 修改 Unix domain 套接字，就要修改配置项 `allowedHostPaths` ，读写权限配置为`readOnly: true`， 这个选项是 Citadel 代理用于配置 Unix domain 套接字路径的。
|
||||
|
||||
{{< warning >}}
|
||||
The following pod security policy assumes no other pod security policy was applied before. If you
|
||||
already applied another pod security policy, add the following configuration values to the existing
|
||||
policies instead of applying the configuration directly.
|
||||
假设以下的 pod 安全策略是之前其它 pod 没有使用过的。如果你已经实施了其它的 pod 安全策略，则给已经存在的策略新增以下的配置值，而不是直接实施配置。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -216,16 +193,13 @@ To enable the pod security policy, perform the following steps:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. Enable pod security policies for your platform. Each supported platform enables pod security
|
||||
policies differently. Please refer to the pertinent documentation for your platform. If you are
|
||||
using the Google Kubernetes Engine (GKE), you must [enable the pod security policy controller](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#enabling_podsecuritypolicy_controller).
|
||||
1. 给你的平台启用 pod 安全策略。不同的平台启用的 pod 安全策略是不一样的。请参考你用平台的相关文档。如果在使用 Google Kubernetes Engine (GKE)，你必须[启用 pod 安全策略控制器](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#enabling_podsecuritypolicy_controller)。
|
||||
|
||||
{{< warning >}}
|
||||
Grant all needed permissions in the pod security policy before enabling it. Once the policy is
|
||||
enabled, pods won't start if they require any permissions not granted.
|
||||
在启用 pod 安全策略之前要先授权它所需要的权限。一旦策略启用，授权不足 pod 将会无法启动。
|
||||
{{< /warning >}}
|
||||
|
||||
1. Run the following command to restart the Citadel agents:
|
||||
1. 使用下面的命令重启 Citadel 代理：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete pod -l 'app=istio-nodeagent' -n istio-system
|
||||
|
|
@ -234,8 +208,7 @@ To enable the pod security policy, perform the following steps:
|
|||
pod "istio-nodeagent-rz878" deleted
|
||||
{{< /text >}}
|
||||
|
||||
1. To verify that the Citadel agents work with the enabled pod security policy, wait a few seconds
|
||||
and run the following command to confirm the agents started successfully:
|
||||
1. 为了验证 Citadel 代理能否使用启用了的 pod 安全策略，等待几秒钟并且执行下面的命令来确认 Citadel 代理已经成功启动。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pod -l 'app=istio-nodeagent' -n istio-system
|
||||
|
|
@ -245,7 +218,7 @@ To enable the pod security policy, perform the following steps:
|
|||
istio-nodeagent-zsk2b 1/1 Running 0 14s
|
||||
{{< /text >}}
|
||||
|
||||
1. Run the following command to start a normal pod.
|
||||
1. 执行下面的命令来启动一个 normal pod。
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -271,8 +244,7 @@ To enable the pod security policy, perform the following steps:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. To verify that the normal pod works with the pod security policy enabled, wait a few seconds and
|
||||
run the following command to confirm the normal pod started successfully.
|
||||
1. 为了验证 normal pod 能不能使用启用了的 pod 安全策略，再等几秒钟并且执行下面的命令来确认 normal pod 已经成功启动。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pod -l 'app=normal'
|
||||
|
|
@ -280,7 +252,7 @@ To enable the pod security policy, perform the following steps:
|
|||
normal-64c6956774-ptpfh 2/2 Running 0 8s
|
||||
{{< /text >}}
|
||||
|
||||
1. Start a malicious pod that tries to mount the Unix domain socket using a write permission.
|
||||
1. 启动一个恶意 pod， 这个 pod 会尝试挂载一个有写权限的 Unix domain 套接字。
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -314,8 +286,7 @@ To enable the pod security policy, perform the following steps:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. To verify that the Unix domain socket is protected, run the following command to confirm the
|
||||
malicious pod failed to start due to the pod security policy:
|
||||
1. 为了验证这个 Unix domain 套接字被保护了，执行下面的命令来确认这个恶意 pod 无法启动，因为有安全策略。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl describe rs -l 'app=malicious' | grep Failed
|
||||
|
|
@ -324,9 +295,9 @@ To enable the pod security policy, perform the following steps:
|
|||
Warning FailedCreate 4s (x13 over 24s) replicaset-controller Error creating: pods "malicious-7dcfb8d648-" is forbidden: unable to validate against any pod security policy: [spec.containers[0].volumeMounts[0].readOnly: Invalid value: false: must be read-only]
|
||||
{{< /text >}}
|
||||
|
||||
## Cleanup
|
||||
## 清理{## cleanup}
|
||||
|
||||
1. Clean up the test services and the Istio control plane:
|
||||
1. 清理测试服务和 Istio 控制面。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete ns foo
|
||||
|
|
@ -334,10 +305,9 @@ To enable the pod security policy, perform the following steps:
|
|||
$ kubectl delete -f istio-auth-sds.yaml
|
||||
{{< /text >}}
|
||||
|
||||
1. Disable the pod security policy in the cluster using the documentation of your platform. If you are using GKE,
|
||||
[disable the pod security policy controller](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#disabling_podsecuritypolicy_controller).
|
||||
1. 根据你的平台文档关闭你集群的 pod 安全策略。如果你在使用 GKE，参考[关闭 pod 安全策略控制器](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#disabling_podsecuritypolicy_controller)。
|
||||
|
||||
1. Delete the pod security policy and the test deployments:
|
||||
1. 删除 pod 安全策略和测试 deployments：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete psp istio-sds-uds istio-nodeagent
|
||||
|
|
@ -349,11 +319,10 @@ To enable the pod security policy, perform the following steps:
|
|||
$ kubectl delete deploy normal
|
||||
{{< /text >}}
|
||||
|
||||
## Caveats
|
||||
## 注意事项{## caveats}
|
||||
|
||||
Currently, the SDS identity provision flow has the following caveats:
|
||||
目前，SDS 身份提供流程有以下注意事项：
|
||||
|
||||
* SDS support is currently in [Alpha](/zh/about/feature-stages/#security-and-policy-enforcement).
|
||||
* SDS 目前只支持[Alpha](/zh/about/feature-stages/#security-and-policy-enforcement)版本。
|
||||
|
||||
* Smoothly migrating a cluster from using secret volume mount to using
|
||||
SDS is a work in progress.
|
||||
* 目前还无法流畅的将群集从使用密钥卷装载方式迁移到使用 SDS ， 功能还在开发中。
|
||||
|
|
|
|||
Loading…
Reference in New Issue