From 1e64a6c7f2dc61c5a4482d83025574beef0a4d47 Mon Sep 17 00:00:00 2001 From: SataQiu <1527062125@qq.com> Date: Thu, 11 Apr 2019 16:40:13 +0800 Subject: [PATCH] zh-trans: update docs/admin/accessing-the-api.md (#13744) --- content/zh/docs/admin/accessing-the-api.md | 72 +++++++++++----------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/content/zh/docs/admin/accessing-the-api.md b/content/zh/docs/admin/accessing-the-api.md index 930cf620fd..27540879b7 100644 --- a/content/zh/docs/admin/accessing-the-api.md +++ b/content/zh/docs/admin/accessing-the-api.md @@ -3,40 +3,40 @@ approvers: - bgrant0607 - erictune - lavalamp -title: Kubernetes API访问控制 +title: Kubernetes API 访问控制 --- -用户通过 `kubectl`、客户端库或者通过发送REST请求[访问API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和[Kubernetes服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行API访问。 -请求到达API服务器后会经过几个阶段，具体说明如图： +用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 +请求到达 API 服务器后会经过几个阶段，具体说明如图： ![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) ## 传输层安全 -在典型的Kubernetes集群中，API通过443端口提供服务。 -API服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常 -包含该API服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的`$USER/.kube/config`。 如果集群中存在多个用户，则创建者需要与其他用户共享证书。 +在典型的 Kubernetes 集群中，API 通过 443 端口提供服务。 +API 服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常 +包含该 API 服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的 `$USER/.kube/config`。 如果集群中存在多个用户，则创建者需要与其他用户共享证书。 ## 认证 -一旦 TLS 连接建立，HTTP请求就进入到了认证的步骤。即图中的步骤 **1** 。 -集群创建脚本或集群管理员会为API服务器配置一个或多个认证模块。 -更具体的认证相关的描述详见 [这里](/docs/admin/authentication/)。 +一旦 TLS 连接建立，HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。 +集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。 +更具体的认证相关的描述详见[这里](/docs/admin/authentication/)。 -认证步骤的输入是整个HTTP请求，但这里通常只是检查请求头和/或客户端证书。 +认证步骤的输入是整个 HTTP 请求，但这里通常只是检查请求头和 / 或客户端证书。 -认证模块支持客户端证书，密码和Plain Tokens， -Bootstrap Tokens，以及JWT Tokens (用于服务账户)。 +认证模块支持客户端证书，密码和 Plain Tokens， +Bootstrap Tokens，以及 JWT Tokens（用于服务账户）。 （管理员）可以同时设置多种认证模块，在设置了多个认证模块的情况下，每个模块会依次尝试认证， 直到其中一个认证成功。 -在 GCE 平台中，客户端证书，密码和Plain Tokens，Bootstrap Tokens，以及JWT Tokens同时被启用。 +在 GCE 平台中，客户端证书，密码和 Plain Tokens，Bootstrap Tokens，以及 JWT Tokens 同时被启用。 -如果请求认证失败，则请求被拒绝，返回401状态码。 +如果请求认证失败，则请求被拒绝，返回 401 状态码。 如果认证成功，则被认证为具体的 `username`，该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系，另一些则没有。 -尽管Kubernetes使用 "用户名" 来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。 +尽管 Kubernetes 使用“用户名”来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。 ## 授权 @@ -44,7 +44,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。 请求须包含请求者的用户名，请求动作，以及该动作影响的对象。 如果存在相应策略，声明该用户具有进行相应操作的权限，则该请求会被授权。 -例如，如果Bob有如下策略，那么他只能够读取`projectCaribou`命名空间下的pod资源： +例如，如果 Bob 有如下策略，那么他只能够读取 `projectCaribou` 命名空间下的 pod 资源： ```json { @@ -58,7 +58,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。 } } ``` -如果Bob发起以下请求，那么请求能够通过授权，因为Bob被允许访问 `projectCaribou` 命名空间下的对象： +如果 Bob 发起以下请求，那么请求能够通过授权，因为 Bob 被允许访问 `projectCaribou` 命名空间下的对象： ```json { @@ -74,20 +74,20 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。 } } ``` -如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。 +如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。 -Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的，因为除Kubernetes外，这些访问控制系统还可能与其他的API进行交互。 +Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的，因为除 Kubernetes 外，这些访问控制系统还可能与其他的 API 进行交互。 -Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook模式。 管理员创建集群时，会配置API服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝(HTTP状态码403)。 +Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhook 模式。 管理员创建集群时，会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes 将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝（HTTP 状态码 403）。 -要了解更多的Kubernetes授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。 +要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。 ## 准入控制 准入控制模块是能够修改或拒绝请求的软件模块。 作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。 -它们作用于对象的创建，删除，更新和连接 (proxy)阶段，但不包括对象的读取。 +它们作用于对象的创建，删除，更新和连接（proxy）阶段，但不包括对象的读取。 可以同时配置多个准入控制器，它们会按顺序依次被调用。 @@ -99,23 +99,23 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook 可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。 -一旦请求通过所有准入控制器，将使用对应API对象的验证流程对其进行验证，然后写入对象存储 (如步骤 **4**)。 +一旦请求通过所有准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储 （如步骤 **4**）。 -## API的端口和IP +## API 的端口和 IP -上述讨论适用于发送请求到API服务器的安全端口(典型情况)。 -实际上API服务器可以通过两个端口提供服务： +上述讨论适用于发送请求到 API 服务器的安全端口（典型情况）。 +实际上 API 服务器可以通过两个端口提供服务： -默认情况下，API服务器在2个端口上提供HTTP服务： +默认情况下，API 服务器在 2 个端口上提供 HTTP 服务： 1. `Localhost Port`: - 用于测试和启动，以及管理节点的其他组件 - (scheduler, controller-manager)与API的交互 - - 没有TLS - - 默认值为8080，可以通过 `--insecure-port` 标记来修改。 - - 默认的IP地址为localhost， 可以通过 `--insecure-bind-address`标记来修改。 + （scheduler, controller-manager）与 API 的交互 + - 没有 TLS + - 默认值为 8080，可以通过 `--insecure-port` 标记来修改。 + - 默认的 IP 地址为 localhost， 可以通过 `--insecure-bind-address` 标记来修改。 - 请求会 **绕过** 认证和鉴权模块。 - 请求会被准入控制模块处理。 - 其访问需要主机访问的权限。 @@ -124,12 +124,12 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook - 尽可能使用该端口访问 - 应用 TLS。 可以通过 `--tls-cert-file` 设置证书， 通过 `--tls-private-key-file` 设置私钥。 - - 默认值为6443，可以通过 `--secure-port` 标记来修改。 - - 默认IP是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。 + - 默认值为 6443，可以通过 `--secure-port` 标记来修改。 + - 默认 IP 是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。 - 请求会经过认证和鉴权模块处理。 - 请求会被准入控制模块处理。 - 要求认证和授权模块正常运行。 -通过 `kube-up.sh`创建集群时， 对 Google Compute Engine (GCE) -和一些其他的云供应商来说， API通过443端口提供服务。 对 -GCE而言，项目上配置了防火墙规则，允许外部的HTTPS请求访问API，其他（厂商的）集群设置方法各不相同。 +通过 `kube-up.sh` 创建集群时， 对 Google Compute Engine（GCE） +和一些其他的云供应商来说， API 通过 443 端口提供服务。 对 +GCE 而言，项目上配置了防火墙规则，允许外部的 HTTPS 请求访问 API，其他（厂商的）集群设置方法各不相同。