mirror of https://github.com/istio/istio.io.git
zh: update docs/concepts/security/index.md (#3036)
* zh: update docs/concepts/security/index.md * update docs/concepts/security/index.md
This commit is contained in:
SataQiu
istio-bot
parent
c9bec145d2
commit
222050d8a4
|
|
@ -105,7 +105,7 @@ Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。
|
|||
|
||||
### 本地机器方案
|
||||
|
||||
1. Citadel 创建 gRPC 服务以获取[证书签名请求](https://en.wikipedia.org/wiki/Certificate_signing_request)（CSR）。
|
||||
1. Citadel 创建 gRPC 服务来接受[证书签名请求](https://en.wikipedia.org/wiki/Certificate_signing_request)（CSR）。
|
||||
|
||||
1. 节点代理生成私钥和 CSR，并将 CSR 及其凭据发送给 Citadel 进行签名。
|
||||
|
||||
|
|
@ -181,7 +181,7 @@ Istio 隧道通过客户端和服务器端进行服务到服务通信 [Envoy 代
|
|||
|
||||
#### 安全命名
|
||||
|
||||
安全命名信息包含来自服务器标识的 *N 到 N* 映射，这些映射在证书中编码到由发现服务或 DNS 引用的服务名称。从身份 `A` 到服务名称 `B` 的映射意味着“允许 `A` 并授权其运行服务 `B` ”。Pilot 监视 Kubernetes `apiserver`，生成安全的命名信息，并将其安全地分发给 sidecar Envoy。以下示例说明了为什么安全命名在身份验证中至关重要。
|
||||
安全命名信息包含从编码在证书中的服务器标识到被发现服务或 DNS 引用的服务名称的 *N-到-N* 映射。从身份 `A` 到服务名称 `B` 的映射意味着“允许 `A` 并授权其运行服务 `B` ”。Pilot 监视 Kubernetes `apiserver`，生成安全的命名信息，并将其安全地分发给 sidecar Envoy。以下示例说明了为什么安全命名在身份验证中至关重要。
|
||||
|
||||
假设运行服务 `datastore` 的合法服务器仅使用 `infra-team` 标识。恶意用户拥有 `test-team` 身份的证书和密钥。恶意用户打算模拟服务以检查从客户端发送的数据。恶意用户使用证书和 `test-team` 身份的密钥部署伪造服务器。假设恶意用户成功攻击了发现服务或 DNS，以将 `datastore` 服务名称映射到伪造服务器。
|
||||
|
||||
|
|
@ -412,7 +412,7 @@ spec:
|
|||
- **`ServiceRole`** 定义了一组访问服务的权限。
|
||||
- **`ServiceRoleBinding`** 向特定主题授予 `ServiceRole`，例如用户、组或服务。
|
||||
|
||||
`ServiceRole` 和 `ServiceRoleBinding` 的组合规定： 允许**谁**在**哪些条件**下**做什么** 。特别：
|
||||
`ServiceRole` 和 `ServiceRoleBinding` 的组合规定： 允许**谁**在**哪些条件**下**做什么** 。明确地说：
|
||||
|
||||
- **谁**指的是 `ServiceRoleBinding` 中的 `subject` 部分。
|
||||
- **做什么**指的是 `ServiceRole` 中的 `permissions` 部分。
|
||||
|
|
@ -444,7 +444,7 @@ spec:
|
|||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
这是另一个角色：`products-viewer`，它有读取，`GET` 和 `HEAD`，访问 `default` 命名空间中的`products.default.svc.cluster.local` 服务。
|
||||
这是另一个角色：`products-viewer`，它有读取权限，包括 `GET` 和 `HEAD`，能够访问 `default` 命名空间中的 `products.default.svc.cluster.local` 服务。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -461,7 +461,7 @@ spec:
|
|||
此外，我们支持规则中所有字段的前缀匹配和后缀匹配。例如，您可以在 `default`命名空间中定义具有以下权限的 `tester` 角色：
|
||||
|
||||
- 完全访问前缀为 `test-*` 的所有服务，例如：`test-bookstore`、`test-performance`、`test-api.default.svc.cluster.local`。
|
||||
- 阅读（`GET`）使用 `*/reviews` 后缀访问所有路径，例如：`/books/reviews`、`/events/booksale/reviews`、`/reviews` in service`bookstore .default.svc.cluster.local`。
|
||||
- 读取（`GET`）使用 `*/reviews` 后缀访问的所有路径，例如：在 `bookstore .default.svc.cluster.local` 服务中的 `/books/reviews`、`/events/booksale/reviews`、`/reviews`。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -490,7 +490,6 @@ metadata:
|
|||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
|
||||
- services: ["products.default.svc.cluster.local"]
|
||||
methods: ["GET", "HEAD"]
|
||||
constraints:
|
||||
|
|
@ -509,8 +508,8 @@ spec:
|
|||
|
||||
下面的例子显示了一个名为 `test-binding-products` 的 `ServiceRoleBinding`，它将两个 `subject` 绑定到名为 `product-viewer` 的 `ServiceRole` 并具有以下 `subject`
|
||||
|
||||
- 代表服务的服务帐户 **a**，``service-account-a``。
|
||||
- 代表 Ingress 服务的服务帐户 `istio-ingress-service-account` **并且** JWT中的 `mail` 项声明为 `a@foo.com`。
|
||||
- 代表服务 **a** 的服务帐户，`service-account-a`。
|
||||
- 代表 Ingress 服务的服务帐户 `istio-ingress-service-account` **并且** 它的 JWT 中的 `mail` 项声明为 `a@foo.com`。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -520,7 +519,6 @@ metadata:
|
|||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
|
||||
- user: "service-account-a"
|
||||
- user: "istio-ingress-service-account"
|
||||
properties:
|
||||
|
|
|
|||
Loading…
Reference in New Issue