From e41eb58bc2c2e143098e6ec2085408cd3479b4fe Mon Sep 17 00:00:00 2001 From: zhaojizhuang <571130360@qq.com> Date: Fri, 27 Nov 2020 01:01:56 +0800 Subject: [PATCH] [zh]sync remoed file for content/en/docs/reference --- .../access-authn-authz/controlling-access.md | 134 ---------- content/zh/docs/reference/glossary/rkt.md | 44 ---- .../docs/reference/using-api/api-overview.md | 232 ------------------ 3 files changed, 410 deletions(-) delete mode 100644 content/zh/docs/reference/access-authn-authz/controlling-access.md delete mode 100644 content/zh/docs/reference/glossary/rkt.md delete mode 100644 content/zh/docs/reference/using-api/api-overview.md diff --git a/content/zh/docs/reference/access-authn-authz/controlling-access.md b/content/zh/docs/reference/access-authn-authz/controlling-access.md deleted file mode 100644 index 933072d606..0000000000 --- a/content/zh/docs/reference/access-authn-authz/controlling-access.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -approvers: -- erictune -- lavalamp -title: Kubernetes API 访问控制 ---- - -用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/zh/docs/tasks/access-application-cluster/access-cluster/)。 用户和 [Kubernetes 服务账户](/zh/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`。 如果集群中存在多个用户，则创建者需要与其他用户共享证书。 - -## 认证 - -一旦 TLS 连接建立，HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。 -集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。 -更具体的认证相关的描述详见[这里](/zh/docs/reference/access-authn-authz/authentication/)。 - -认证步骤的输入是整个 HTTP 请求，但这里通常只是检查请求头和 / 或客户端证书。 - -认证模块支持客户端证书，密码和 Plain Tokens， -Bootstrap Tokens，以及 JWT Tokens（用于服务账户）。 - -（管理员）可以同时设置多种认证模块，在设置了多个认证模块的情况下，每个模块会依次尝试认证， -直到其中一个认证成功。 - -在 GCE 平台中，客户端证书，密码和 Plain Tokens，Bootstrap Tokens，以及 JWT Tokens 同时被启用。 - -如果请求认证失败，则请求被拒绝，返回 401 状态码。 -如果认证成功，则被认证为具体的 `username`，该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系，另一些则没有。 - -尽管 Kubernetes 使用“用户名”来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。 - -## 授权 - -当请求被认证为来自某个特定的用户后，该请求需要被授权。 即图中的步骤 **2** 。 - -请求须包含请求者的用户名，请求动作，以及该动作影响的对象。 如果存在相应策略，声明该用户具有进行相应操作的权限，则该请求会被授权。 - -例如，如果 Bob 有如下策略，那么他只能够读取 `projectCaribou` 命名空间下的 pod 资源： - -```json -{ - "apiVersion": "abac.authorization.kubernetes.io/v1beta1", - "kind": "Policy", - "spec": { - "user": "bob", - "namespace": "projectCaribou", - "resource": "pods", - "readonly": true - } -} -``` -如果 Bob 发起以下请求，那么请求能够通过授权，因为 Bob 被允许访问 `projectCaribou` 命名空间下的对象： - -```json -{ - "apiVersion": "authorization.k8s.io/v1beta1", - "kind": "SubjectAccessReview", - "spec": { - "resourceAttributes": { - "namespace": "projectCaribou", - "verb": "get", - "group": "unicorn.example.org", - "resource": "pods" - } - } -} -``` -如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。 - -Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的，因为除 Kubernetes 外，这些访问控制系统还可能与其他的 API 进行交互。 - -Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhook 模式。 管理员创建集群时，会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes 将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝（HTTP 状态码 403）。 - -要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/zh/docs/reference/access-authn-authz/authorization/)。 - - -## 准入控制 - -准入控制模块是能够修改或拒绝请求的软件模块。 -作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。 -它们作用于对象的创建，删除，更新和连接（proxy）阶段，但不包括对象的读取。 - -可以同时配置多个准入控制器，它们会按顺序依次被调用。 - -即图中的步骤 **3** 。 - -与认证和授权模块不同的是，如果任一个准入控制器拒绝请求，那么整个请求会立即被拒绝。 - -除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。 - -可用的准入控制模块描述 [如下](/zh/docs/reference/access-authn-authz/admission-controllers/)。 - -一旦请求通过所有准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储 （如步骤 **4**）。 - - -## API 的端口和 IP - -上述讨论适用于发送请求到 API 服务器的安全端口（典型情况）。 -实际上 API 服务器可以通过两个端口提供服务： - -默认情况下，API 服务器在 2 个端口上提供 HTTP 服务： - - 1. `Localhost Port`: - - - 用于测试和启动，以及管理节点的其他组件 - （scheduler, controller-manager）与 API 的交互 - - 没有 TLS - - 默认值为 8080，可以通过 `--insecure-port` 标记来修改。 - - 默认的 IP 地址为 localhost， 可以通过 `--insecure-bind-address` 标记来修改。 - - 请求会 **绕过** 认证和鉴权模块。 - - 请求会被准入控制模块处理。 - - 其访问需要主机访问的权限。 - - 2. `Secure Port`: - - - 尽可能使用该端口访问 - - 应用 TLS。 可以通过 `--tls-cert-file` 设置证书， 通过 `--tls-private-key-file` 设置私钥。 - - 默认值为 6443，可以通过 `--secure-port` 标记来修改。 - - 默认 IP 是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。 - - 请求会经过认证和鉴权模块处理。 - - 请求会被准入控制模块处理。 - - 要求认证和授权模块正常运行。 - -通过 `kube-up.sh` 创建集群时， 对 Google Compute Engine（GCE） -和一些其他的云供应商来说， API 通过 443 端口提供服务。 对 -GCE 而言，项目上配置了防火墙规则，允许外部的 HTTPS 请求访问 API，其他（厂商的）集群设置方法各不相同。 diff --git a/content/zh/docs/reference/glossary/rkt.md b/content/zh/docs/reference/glossary/rkt.md deleted file mode 100644 index 6ba0e19d7d..0000000000 --- a/content/zh/docs/reference/glossary/rkt.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: rkt -id: rkt -date: 2019-01-24 -translater: Coffey Gao -full_link: https://coreos.com/rkt/ -short_description: > - 一个安全的、基于标准的容器引擎。 - -aka: -tags: -- security -- tool ---- - - - - - - 一个安全的、基于标准的容器引擎。 - - - - - -rkt 是一个应用程序 {{< glossary_tooltip text="容器" term_id="container" >}} 引擎，它具有原生的 {< glossary_tooltip text="Pod" term_id="pod" >}} 方法、可插拔的执行环境和定义良好的接口。rkt 允许用户在 Pod 和应用程序级别应用不同的配置。每个 Pod 在一个自包含的、独立的经典 Unix 进程模型中直接执行。 \ No newline at end of file diff --git a/content/zh/docs/reference/using-api/api-overview.md b/content/zh/docs/reference/using-api/api-overview.md deleted file mode 100644 index 4c08851654..0000000000 --- a/content/zh/docs/reference/using-api/api-overview.md +++ /dev/null @@ -1,232 +0,0 @@ ---- -title: Kubernetes API 总览 -content_type: concept -weight: 10 -card: - name: reference - weight: 50 - title: API 总览 ---- - - - - - - -此页提供 Kubernetes API 的总览 - - - - - - - -REST API 是 Kubernetes 的基础架构。组件之间的所有操作和通信，以及外部用户命令都是 API Server 处理的 REST API 调用。因此，Kubernetes 平台中的所有资源被视为 API 对象，并且在 -[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 中都有对应的定义项。 - -大多数操作可以通过 [kubectl](/docs/reference/kubectl/overview/) 命令行界面或其他命令行工具执行，例如 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)，它们本身也使用 API。但是，您也可以使用 REST 调用直接访问 API。 - -如果您正在使用 Kubernetes API 编写应用程序，请考虑使用 [客户端库](/docs/reference/using-api/client-libraries/)。 - - -## API 版本控制 - -为了消除字段或重组资源表示形式，Kubernetes 支持多个 API 版本，每个版本在不同的 API 路径下。例如：`/api/v1` 或者 `/apis/extensions/v1beta1`。 - -版本是在 API 级别而非资源或字段级别配置的： - -- 确保 API 呈现出清晰一致的系统资源和行为视图。 -- 允许控制对已寿终正寝的 API 和/或实验性 API 的访问。 - -JSON 和 Protobuf 序列化模式在出现模式变更时均遵循这些准则。以下说明同时适用于这两种格式。 - - - -{{< note >}} -API 版本和软件版本是间接相关的。[API 和发布版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了 API 版本和软件版本之间的关系。 -{{< /note >}} - - -不同的 API 版本表示不同级别的稳定性和支持级别。您可以在 [API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable) 中找到有关每个级别的条件的更多信息。 - -以下是每个级别的摘要： - -- Alpha： - - 版本名称包含 `alpha`（例如，`v1alpha1`）。 - - 该软件可能包含错误。启用功能可能会暴露错误。默认情况下，功能可能被禁用。 - - 对功能的支持随时可能被删除，但不另行通知。 - - 在以后的软件版本中，API 可能会以不兼容的方式更改，亦不另行通知。 - - 由于存在更高的错误风险和缺乏长期支持，建议仅在短期测试集群中使用该软件。 - -- Beta： - - 版本名称包含`beta`（例如，`v2beta3`）。 - - 该软件已经过充分测试。启用功能被认为是安全的。默认情况下启用功能。 - - 尽管细节可能会发生变更，对应功能不会被废弃。 - - 在随后的 Beta 或稳定版本中，对象的模式和/或语义可能会以不兼容的方式更改。发生这种情况时，将提供迁移说明。迁移时可能需要删除、编辑和重新创建 API 对象。编辑过程可能需要一些思考。对于依赖该功能的应用程序，可能需要停机。 - - 该软件仅建议用于非关键业务用途，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的群集，则可以放宽此限制。 - - {{< note >}} - - - -请试用 Beta 版功能并提供反馈。功能结束 Beta 版之后，再进行变更可能是不切实际的。 - - {{< /note >}} - - - -- 稳定版： - - 版本名称为 `vX`，其中`X`为整数。 - - 功能特性的稳定版本会持续出现在许多后续版本的发行软件中。 - - - -## API 组 - -[ *API 组*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) 使扩展 Kubernetes API 更容易。API 组在 REST 路径和序列化对象的 apiVersion 字段中指定。 - -当前，有几个正在使用的 API 组： - -* *core*（也称为 *legacy*）组，它位于 REST 路径`/api/v1`上，未指定为 apiVersion 字段的一部分，例如`apiVersion: v1`。 -* 特定名称的组位于 REST 路径`/apis/$GROUP_NAME/$VERSION`下，并使用`apiVersion:$GROUP_NAME/$VERSION`（例如，`apiVersion:batch/v1`）。您可以在 [Kubernetes API 参考](/docs/reference/) 中找到受支持的 API Group 的完整列表。 - -有两种途径来使用 [自定义资源](/docs/concepts/api-extension/custom-resources/) 扩展 API，分别是： - - - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) 提供基本的 CRUD 需求。 - - [聚合器（Aggregator）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)具有完整的 Kubernetes API 语义，用以实现用户自己的 apiserver。 - - -## 启用 API 组 - -默认情况下，某些资源和 API 组处于启用状态。您可以通过设置`--runtime-config`来启用或禁用它们。 -`--runtime-config` 接受逗号分隔的值。例如： - - 要禁用 `batch/v1`，请配置`--runtime-config=batch/v1=false` - - 要启用 `batch/2alpha1`，请配置`--runtime-config=batch/v2alpha1` -该标志接受描述 apiserver 的运行时配置的以逗号分隔的`key=value` 对集合。 - -{{< note >}} - - -启用或禁用组或资源时，需要重新启动 apiserver 和控制器管理器以刷新 `--runtime-config` 的更改。 - -{{< /note >}} - - - -## 启用 extensions/v1beta1 组中具体资源 - -在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。 -例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。 - -{{< note >}} - - -出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。 - -{{< /note >}} - -