From bab256b78897771405d5c2a9d4afb79208605035 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 28 Nov 2020 17:07:36 +0800 Subject: [PATCH] [zh] Sync changes from English (auth references) --- .../reference/access-authn-authz/_index.md | 52 + .../admission-controllers.md | 536 ++-- .../certificate-signing-requests.md | 426 +-- .../docs/reference/access-authn-authz/rbac.md | 2471 ++++++++--------- 4 files changed, 1732 insertions(+), 1753 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/_index.md b/content/zh/docs/reference/access-authn-authz/_index.md index 7c1caa8f24..4a67bd9440 100644 --- a/content/zh/docs/reference/access-authn-authz/_index.md +++ b/content/zh/docs/reference/access-authn-authz/_index.md @@ -1,4 +1,56 @@ --- title: 访问 API weight: 20 +no_list: true --- + + + + +关于 Kubernetes 如何实现和控制 API 访问的介绍性材料，可阅读 +[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)。 + +参考文档： + + +- [身份认证](/zh/docs/reference/access-authn-authz/authentication/) + - [使用启动引导令牌来执行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权与授权](/zh/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包含 [CSR 的批复](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- 服务账号 + - [开发者指南](/zh/docs/tasks/configure-pod-container/configure-service-account/) + - [管理文档](/zh/docs/reference/access-authn-authz/service-accounts-admin/) + diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index 893d1891d5..d5c847ab5f 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -32,7 +32,6 @@ This page provides an overview of Admission Controllers. - ## 什么是准入控制插件？ - -准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 - +准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API +服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成， +并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。 +在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 +它们根据 API 中的配置，分别执行变更和验证 +[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 - -准入控制器可以执行 “验证” 和/或 “变更” 操作。变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。 +准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 +变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 @@ -80,7 +82,6 @@ corresponding reclamation or reconciliation process, as a given admission controller does not know for sure that a given request will pass all of the other admission controllers. --> - 最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 增加使用配额就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。 @@ -96,7 +97,8 @@ to properly support the feature. As a result, a Kubernetes API server that is n configured with the right set of admission controllers is an incomplete server and will not support all the features you expect. --> -Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持您期望的所有特性。 +Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 +因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你期望的所有特性。 -Kubernetes API 服务器的 `enable-admission-plugins` 标志，它指定了一个用于在集群修改对象之前调用的（以逗号分隔的）准入控制插件顺序列表。 +Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个用于在集群修改对象之前 +调用的（以逗号分隔的）准入控制插件顺序列表。 例如，下面的命令就启用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： @@ -125,7 +128,7 @@ have to modify the systemd unit file if the API server is deployed as a systemd service, you may modify the manifest file for the API server if Kubernetes is deployed in a self-hosted way. --> -根据您 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，您可能需要以不同的方式应用设置。 +根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，你可能需要以不同的方式应用设置。 例如，如果将 API 服务器部署为 systemd 服务，你可能需要修改 systemd 单元文件； 如果以自托管方式部署 Kubernetes，你可能需要修改 API 服务器的清单文件。 {{< /note >}} @@ -135,10 +138,10 @@ in a self-hosted way. The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default. --> - ## 怎么关闭准入控制器？ -Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的）准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 +Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的） +准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 ```shell kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... @@ -149,7 +152,6 @@ kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... To see which admission plugins are enabled: --> - ## 哪些插件是默认启用的？ 下面的命令可以查看哪些插件是默认启用的： @@ -159,13 +161,13 @@ kube-apiserver -h | grep enable-admission-plugins ``` -在 1.16 中，它们是： +在目前版本中，它们是： ```shell -NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota +NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota ``` - ## 每个准入控制器的作用是什么？ ### AlwaysAdmit {#alwaysadmit} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} 该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。 @@ -196,10 +198,12 @@ required. --> 该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 -如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 pod 都可以通过已了解到的镜像的名称（假设 pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 +如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像 +的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。 ### AlwaysDeny {#alwaysdeny} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - 此准入控制器获取 CertificateSigningRequest 资源的 `status.certificate` 字段更新请求并执行额外的授权检查， 以确保签发证书的用户有权限为 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求`签发`证书。 @@ -241,9 +244,8 @@ to sign certificate requests with the spec.signerName requested on the Certifica See Certificate Signing Requests for more information on the permissions required to perform different actions on CertificateSigningRequest resources. --> - 有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/) +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) ### CertificateSubjectRestrictions @@ -252,8 +254,8 @@ This admission controller observes creation of CertificateSigningRequest resourc that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request that specifies a 'group' (or 'organization attribute') of system:masters. --> - -此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 CertificateSigningRequest 资源创建请求， +此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 +CertificateSigningRequest 资源创建请求， 它拒绝任何包含了 `system:masters` 一个“组”（或者“组织”）的请求。 ### DefaultStorageClass {#defaultstorageclass} @@ -264,8 +266,8 @@ and automatically adds a default storage class to them. This way, users that do not request any special storage class do not need to care about them at all and they will get the default one. --> - -该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建，并自动向其添加默认存储类。 +该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建， +并自动向其添加默认存储类。 这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将获得默认存储类。 - -当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类，它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。此时准入控制器会忽略任何 `PersistentVolumeClaim` 更新操作，仅响应创建操作。要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 +当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类， +它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。 +此时准入控制器会忽略任何 `PersistentVolumeClaim` 更新操作，仅响应创建操作。 +要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 - -关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 +关于持久化卷和存储类，以及如何将存储类标记为默认，请参见 +[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 ### DefaultTolerationSeconds {#defaulttolerationseconds} @@ -293,10 +297,13 @@ if the pods don't already have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.kubernetes.io/unreachable:NoExecute`. --> - -该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 污点。（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 `node.kubernetes.io/unreachable：NoExecute` 污点的话） +该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 +`unreachable:NoExecute` 污点。 +（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 +`node.kubernetes.io/unreachable：NoExecute` 污点的话） ### DenyExecOnPrivileged {#denyexeconprivileged} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - 此功能已合并至 [DenyEscalatingExec](#denyescalatingexec)。 而 DenyExecOnPrivileged 准入插件已被废弃，并将在 v1.18 被移除。 @@ -317,11 +323,11 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. --> - 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。 +该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### DenyEscalatingExec {#denyescalatingexec} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - -该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 pod 中执行 exec 和 attach 命令。这包括在特权模式运行的 pod ，可以访问主机 IPC 命名空间的 pod ，和访问主机 PID 命名空间的 pod 。 +该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 Pod 中执行 exec 和 +attach 命令。这包括在特权模式运行的 Pod，可以访问主机 IPC 名字空间的 Pod， +和访问主机 PID 名字空间的 Pod 。 - DenyExecOnPrivileged 准入插件已被废弃，并将在 v1.18 被移除。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。 +该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### EventRateLimit {#eventratelimit} + {{< feature-state for_k8s_version="v1.13" state="alpha" >}} - 该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： - - * 确保 API 服务器的 `--runtime-config` 标志中包含了 `eventratelimit.admission.k8s.io/v1alpha1=true`； - * 启用 `EventRateLimit` 准入控制器； - * 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 `--admission-control-config-file` 标志： +* 启用 `EventRateLimit` 准入控制器； +* 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 + `--admission-control-config-file` 标志： {{< tabs name="eventratelimit_example" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -394,7 +397,6 @@ plugins: - 可以在配置中指定四种类型的限制： - - * `Server`: API 服务器收到的所有事件请求共享一个桶。 - * `Namespace`: 每个命名空间都有一个专用的桶。 - * `User`: 给每个用户都分配一个桶。 - * `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 +* `Server`: API 服务器收到的所有事件请求共享一个桶。 +* `Namespace`: 每个名字空间都有一个专用的桶。 +* `User`: 给每个用户都分配一个桶。 +* `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 - 下面是一个配置示例 `eventconfig.yaml`： ```yaml @@ -433,8 +433,8 @@ limits: See the [EventRateLimit proposal](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md) for more details. --> - -详情请参见[事件速率限制提案](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)。 +详情请参见 +[事件速率限制提案](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)。 ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -446,50 +446,50 @@ name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to pods requesting extended resources, so users don't have to manually add these tolerations. --> - 该插件有助于创建可扩展资源的专用节点。 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， -那他们应该以扩展资源名称作为键名，[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 -如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中，用户不必再手动添加这些容忍。 +那他们应该以扩展资源名称作为键名， +[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中， +用户不必再手动添加这些容忍。 ### ImagePolicyWebhook {#imagepolicywebhook} - ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。 - #### 配置文件格式 - -ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 json 或 yaml ，并具有以下格式: +ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML， +并具有以下格式: ```yaml imagePolicy: kubeConfigFile: /path/to/kubeconfig/for/backend - # time in s to cache approval + # 以秒计的时长，控制批准请求的缓存时间 allowTTL: 50 - # time in s to cache denial + # 以秒计的时长，控制批准请求的缓存时间 denyTTL: 50 - # time in ms to wait between retries + # 以毫秒计的时长，控制重试间隔 retryBackoff: 500 - # determines behavior if the webhook backend fails + # 确定 Webhook 后端失效时的行为 defaultAllow: true ``` -从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令 `--admission-control-config-file` 标志： +从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令标志 +`--admission-control-config-file`： {{< tabs name="imagepolicywebhook_example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -504,7 +504,7 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: @@ -518,8 +518,7 @@ plugins: - -或者，您也可以直接将配置嵌入到文件中： +或者，你也可以直接将配置嵌入到文件中： {{< tabs name="imagepolicywebhook_example2" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -530,7 +529,7 @@ plugins: - name: ImagePolicyWebhook configuration: imagePolicy: - kubeConfigFile: + kubeConfigFile: allowTTL: 50 denyTTL: 50 retryBackoff: 500 @@ -539,14 +538,14 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: ImagePolicyWebhook configuration: imagePolicy: - kubeConfigFile: + kubeConfigFile: allowTTL: 50 denyTTL: 50 retryBackoff: 500 @@ -556,10 +555,15 @@ plugins: {{< /tabs >}} - -ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。 +ImagePolicyWebhook 的配置文件必须引用 +[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +格式的文件；该文件设置了到后端的连接参数。 +要求后端使用 TLS 进行通信。 - -HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。 +关于 HTTP 配置的更多信息，请参阅 +[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档。 -当面对一个准入决策时，API server 发送一个描述操作的 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 pod 注释。 +当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 +`imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。 +该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 +Pod 注解。 -注意，webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段，以确保正确的反序列化。此外，API server 必须启用 imagepolicy.k8s.io/v1alpha1 API 扩展组 (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`)。 +注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。 +实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段， +以确保正确的反序列化。 +此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组 +（`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。 -远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。响应体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回： +远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。 +响应体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回： ```json { @@ -665,7 +679,7 @@ The remote service is expected to fill the `ImageReviewStatus` field of the requ -不允许访问，服务将返回： +若不允许访问，服务将返回： ```json { @@ -681,7 +695,8 @@ To disallow access, the service would return: -更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象 和 `plugin/pkg/admission/imagepolicy/admission.go`。 +更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象和 +`plugin/pkg/admission/imagepolicy/admission.go`。 -一个 pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 webhook。这允许了解后端镜像策略的用户向它发送额外的信息，并为不同的后端实现接收不同的信息。 +一个 Pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 Webhook。 +这样做使得了解后端镜像策略的用户可以向它发送额外的信息，并为不同的后端实现 +接收不同的信息。 -您可以在这里输入的信息有： +你可以在这里输入的信息有： - - * 在紧急情况下，请求 "break glass" 覆盖一个策略。 - * 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号号码。 - * 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 +* 在紧急情况下，请求 "break glass" 覆盖一个策略。 +* 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。 +* 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 -在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。 +在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。 +在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。 ### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} @@ -719,7 +736,9 @@ In any case, the annotations are provided by the user and are not validated by K This admission controller denies any pod that defines `AntiAffinity` topology key other than `kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`. --> -该准入控制器拒绝（定义了 `Anti Affinity` 拓扑键的）任何 Pod（`requiredDuringSchedulingRequiredDuringExecution` 中的 `kubernetes.io/hostname` 除外） +该准入控制器拒绝（定义了 `AntiAffinity` 拓扑键的）任何 Pod +（`requiredDuringSchedulingRequiredDuringExecution` 中的 +`kubernetes.io/hostname` 除外）。 ### LimitRanger {#limitranger} @@ -730,16 +749,25 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all Pods in the `default` namespace. --> - -该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` 对象枚举的任何约束。如果您在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来执行这些约束。LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod；当前，默认的 LimitRanger 对 `default` 命名空间中的所有 pod 都应用了 0.1 CPU 的需求。 +该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` +对象枚举的任何约束。 +如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来 +执行这些约束。 +LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod； +当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都应用了 +0.1 CPU 的需求。 - -请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)了解更多细节。 +请查看 +[limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) +和 [LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) +以了解更多细节。 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} + {{< feature-state for_k8s_version="v1.13" state="beta" >}} -该准入控制器调用任何与请求匹配的变更 webhook。匹配的 webhook 将被串行调用。每一个 webhook 都可以根据需要修改对象。 +该准入控制器调用任何与请求匹配的变更 Webhook。匹配的 Webhook 将被串行调用。 +每一个 Webhook 都可以根据需要修改对象。 -`MutatingAdmissionWebhook` ，顾名思义，仅在变更阶段运行。 +`MutatingAdmissionWebhook`，顾名思义，仅在变更阶段运行。 -如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 `admissionregistration.k8s.io/v1beta1` 组/版本中的 `MutatingWebhookConfiguration` 对象（版本 >=1.9 时，这两个对象都是默认启用的）。 +如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 +`admissionregistration.k8s.io/v1beta1` 组/版本中的 `MutatingWebhookConfiguration` +对象（版本 >=1.9 时，这两个对象都是默认启用的）。 - - * 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 - * 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 - * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。应尽量避免前面那种方式。 - * 这是一个 beta 特性。Kubernetes 未来的版本可能会限制这些 webhook 可以进行的变更类型。 - * 内建资源和第三方资源的控制环，未来可能会受到破坏性的更改，使现在运行良好的 Webhook 无法再正常运行。即使完成了 webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 +* 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 +* 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 + * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。 + 应尽量避免前面那种方式。 +* 这是一个 beta 特性。Kubernetes 未来的版本可能会限制这些 Webhook 可以进行的变更类型。 +* 内建资源和第三方资源的控制回路未来可能会受到破坏性的更改，使现在运行良好的 Webhook + 无法再正常运行。即使完成了 Webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 ### NamespaceAutoProvision {#namespaceautoprovision} @@ -803,8 +835,9 @@ It creates a namespace if it cannot be found. This admission controller is useful in deployments that do not want to restrict creation of a namespace prior to its usage. --> -该准入控制器会检查命名空间资源上的所有传入请求，并检查所引用的命名空间是否确实存在。如果找不到，它将创建一个命名空间。 -此准入控制器对于不想要求命名空间必须先创建后使用的集群部署中很有用。 +该准入控制器会检查名字空间资源上的所有传入请求，并检查所引用的名字空间是否确实存在。 +如果找不到，它将创建一个名字空间。 +此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。 ### NamespaceExists {#namespaceexists} @@ -812,7 +845,8 @@ a namespace prior to its usage. This admission controller checks all requests on namespaced resources other than `Namespace` itself. If the namespace referenced from a request doesn't exist, the request is rejected. --> -该准入控制器检查除自身 `Namespace` 以外的命名空间资源上的所有请求。如果请求引用的命名空间不存在，则拒绝该请求。 +该准入控制器检查除 `Namespace` 以外的名字空间作用域资源上的所有请求。 +如果请求引用的名字空间不存在，则拒绝该请求。 ### NamespaceLifecycle {#namespacelifecycle} @@ -821,14 +855,17 @@ This admission controller enforces that a `Namespace` that is undergoing termina and ensures that requests in a non-existent `Namespace` are rejected. This admission controller also prevents deletion of three system reserved namespaces `default`, `kube-system`, `kube-public`. --> -该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保使用不存在的 `Namespace` 的请求被拒绝。 -该准入控制器还会禁止删除三个系统保留的命名空间，即 `default`、`kube-system` 和 `kube-public`。 +该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保 +使用不存在的 `Namespace` 的请求被拒绝。 +该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、 +`kube-system` 和 `kube-public`。 -删除 `Namespace` 会触发删除该命名空间中所有对象（pod、services 等）的一系列操作。为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 +删除 `Namespace` 会触发删除该名字空间中所有对象（Pod、Service 等）的一系列操作。 +为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 ### NodeRestriction {#noderestriction} @@ -837,7 +874,10 @@ This admission controller limits the `Node` and `Pod` objects a kubelet can modi kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:`. Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node. --> -该准入控制器限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个准入控制器的限制，kubelet 必须使用在 `system:nodes` 组中的凭证，并使用 `system:node:` 形式的用户名。这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 `Pod` 对象。 +该准入控制器限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 +为了受到这个准入控制器的限制，kubelet 必须使用在 `system:nodes` 组中的凭证， +并使用 `system:node:` 形式的用户名。 +这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 Pod 对象。 在 Kubernetes 1.11+ 的版本中，不允许 kubelet 从 `Node` API 对象中更新或删除污点。 -在 Kubernetes 1.13+ 的版本中，`NodeRestriction` 准入插件可防止 kubelet 删除 `Node` API 对象，并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet 强制进行如下修改： +在 Kubernetes 1.13+ 的版本中，`NodeRestriction` 准入插件可防止 kubelet 删除 +`Node` API 对象，并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet +强制进行如下修改： - -* **防止** kubelets 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。保留此前缀的标签，供管理员用来标记 `Node` 对象以隔离工作负载，并且不允许 kubelet 修改带有该前缀的标签。 +* **防止** kubelet 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。 + 保留此前缀的标签，供管理员用来标记 Node 对象以隔离工作负载，并且不允许 kubelet + 修改带有该前缀的标签。 * **允许** kubelet 添加/删除/更新这些和这些前缀的标签： * `kubernetes.io/hostname` * `kubernetes.io/arch` * `kubernetes.io/os` * `beta.kubernetes.io/instance-type` * `node.kubernetes.io/instance-type` - * `failure-domain.beta.kubernetes.io/region` - * `failure-domain.beta.kubernetes.io/zone` + * `failure-domain.beta.kubernetes.io/region` （已弃用） + * `failure-domain.beta.kubernetes.io/zone` (已弃用） * `topology.kubernetes.io/region` * `topology.kubernetes.io/zone` * `kubelet.kubernetes.io/`-prefixed labels @@ -875,7 +918,8 @@ Use of any other labels under the `kubernetes.io` or `k8s.io` prefixes by kubele Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly. --> -kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 `NodeRestriction` 准入插件允许或禁止。 +kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 +`NodeRestriction` 准入插件允许或禁止。 将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。 @@ -888,10 +932,14 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. --> - -该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 “删除” 权限的用户才能对其进行更改。该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问，以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” 权限的用户才能对其进行更改。 +该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 +“删除” 权限的用户才能对其进行更改。 +该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问， +以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” +权限的用户才能对其进行更改。 ### PersistentVolumeLabel {#persistentvolumelabel} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS）定义的 PersistentVolumes 中。 -这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 -如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 +该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS） +定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 +如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， +以防止 Pod 挂载其他区域的卷。 +PersistentVolumeLabel 已被废弃，标记持久卷已由 +[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 从 1.11 开始，默认情况下禁用此准入控制器。 ### PodNodeSelector {#podnodeselector} @@ -916,7 +966,8 @@ PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/ -该准入控制器通过读取命名空间注解和全局配置，来为命名空间中可以可以使用的节点选择器设置默认值并实施限制。 +该准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以可以使用的节点选择器 +设置默认值并实施限制。 - #### 配置文件格式 `PodNodeSelector` 使用配置文件来设置后端行为的选项。 -请注意，配置文件格式将在将来某个版本中迁移为版本化文件。 -该文件可以是 json 或 yaml，格式如下： +请注意，配置文件格式将在将来某个版本中改为版本化文件。 +该文件可以是 JSON 或 YAML，格式如下： ```yaml podNodeSelectorPluginConfig: @@ -942,7 +992,8 @@ podNodeSelectorPluginConfig: -从文件中引用 `PodNodeSelector` 配置文件，提供给 API 服务器命令行标志 `--admission-control-config-file`： +基于提供给 API 服务器命令行标志 `--admission-control-config-file` 的文件名， +从文件中引用 `PodNodeSelector` 配置文件： {{< tabs name="podnodeselector_example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -957,7 +1008,7 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# 在 v1.17 中废弃，以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: @@ -975,7 +1026,8 @@ plugins: --> #### 配置注解格式 -`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解将节点选择器分配给命名空间。 +`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解 +为名字空间设置节点选择算符。 ```yaml apiVersion: v1 @@ -990,7 +1042,6 @@ metadata: #### Internal Behavior This admission controller has the following behavior: --> - #### 内部行为 该准入控制器行为如下： @@ -1004,17 +1055,21 @@ plugin configuration file as the node selector. 4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file. Conflicts result in rejection. --> -1. 如果 `Namespace` 的注解带有键 `scheduler.alpha.kubernetes.io/node-selector` ，则将其值用作节点选择器。 -2. 如果命名空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 `clusterDefaultNodeSelector` 作为节点选择器。 -3. 评估 pod 节点选择器和命名空间节点选择器是否存在冲突。存在冲突将导致拒绝。 -4. 评估 pod 节点选择器和命名空间的白名单定义的插件配置文件是否存在冲突。存在冲突将导致拒绝。 +1. 如果 `Namespace` 的注解带有键 `scheduler.alpha.kubernetes.io/node-selector`， + 则将其值用作节点选择算符。 +2. 如果名字空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 + `clusterDefaultNodeSelector` 作为节点选择算符。 +3. 评估 Pod 节点选择算符和名字空间节点选择算符是否存在冲突。存在冲突将导致拒绝。 +4. 评估 pod 节点选择算符和名字空间的白名单定义的插件配置文件是否存在冲突。 + 存在冲突将导致拒绝。 {{< note >}} -PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。另请参阅 PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。 +PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。 +另请参阅 PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。 {{< /note >}} ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} @@ -1029,7 +1084,8 @@ This admission controller implements additional validations for checking incomin Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes` to `true` to enable resizing. --> -对调整卷大小的支持是一种 Alpha 特性。管理员必须将特性门控 `ExpandPersistentVolumes` 设置为 `true` 才能启用调整大小。 +对调整卷大小的支持是一种 Alpha 特性。管理员必须将特性门控 `ExpandPersistentVolumes` +设置为 `true` 才能启用调整大小。 {{< /note >}} -启用 `ExpandPersistentVolumes` 特性门控之后，建议将 `PersistentVolumeClaimResize` 准入控制器也启用。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 `true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 +启用 `ExpandPersistentVolumes` 特性门控之后，建议将 `PersistentVolumeClaimResize` +准入控制器也启用。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 +`true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 例如：由以下 `StorageClass` 创建的所有 `PersistentVolumeClaim` 都支持卷容量扩充： @@ -1060,8 +1118,8 @@ allowVolumeExpansion: true - -关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +关于持久化卷申领的更多信息，请参见 +[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PodPreset {#podpreset} @@ -1071,9 +1129,10 @@ See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and [Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset) for more information. --> - -该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 pod。 -另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) 获取详情。 +该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 Pod。 +另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和 +[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) +了解更多信息。 ### PodSecurityPolicy {#podsecuritypolicy} @@ -1081,61 +1140,70 @@ for more information. This admission controller acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the available Pod Security Policies. --> -此准入控制器负责在创建和修改 pod 时根据请求的安全上下文和可用的 pod 安全策略确定是否可以执行请求。 - - -对于 Kubernetes < 1.6.0 的版本，API Server 必须启用 extensions/v1beta1/podsecuritypolicy API 扩展组 (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`)。 +此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和可用的 Pod +安全策略确定是否可以执行请求。 -查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/)了解更多细节。 +查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/) +了解更多细节。 ### PodTolerationRestriction {#podtolerationrestriction} - -该准入控制器首先验证 Pod 的容忍度与其命名空间的容忍度之间的冲突。如果存在冲突，则拒绝 Pod 请求。 -然后，它将命名空间的容忍度合并到 pod 的容忍度中，之后根据命名空间的容忍度白名单检查所得到的容忍度结果。 -如果检查成功，则将接受 pod 请求，否则拒绝该请求。 +准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间 +是否存在冲突。如果存在冲突，则拒绝 Pod 请求。 +然后，它将名字空间的容忍度合并到 Pod 的容忍度中，之后根据名字空间的容忍度 +白名单检查所得到的容忍度结果。如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 - -如果 pod 的命名空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的默认容忍度或容忍度白名单（如果有的话）。 +如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的 +默认容忍度或容忍度白名单（如果有的话）。 -命名空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` 和 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 设置。 +Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key. +The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key. +Example for namespace annotations: +--> +名字空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` +来设置。可接受的容忍度可以通过 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` +注解键来添加。 + +名字空间注解的示例： + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: apps-that-need-nodes-exclusively + annotations: + scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' + scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' +``` - ### 优先级 {#priority} -优先级准入控制器使用 `priorityClassName` 字段并用整型值填充优先级。如果找不到优先级，则拒绝 Pod。 +优先级准入控制器使用 `priorityClassName` 字段并用整型值填充优先级。 +如果找不到优先级，则拒绝 Pod。 ### ResourceQuota {#resourcequota} @@ -1144,66 +1212,98 @@ This admission controller will observe the incoming request and ensure that it d enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota` objects in your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints. --> -该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` 对象中枚举出来的约束。 -如果您在 Kubernetes 部署中使用了 `ResourceQuota` ，您必须使用这个准入控制器来强制执行配额限制。 +该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` +对象中枚举出来的约束。 +如果你在 Kubernetes 部署中使用了 `ResourceQuota`，你必须使用这个准入控制器来强制 +执行配额限制。 -请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 +请查看 +[resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/) +了解更多细节。 - ### 容器运行时类 {#runtimeclass} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} -[容器运行时类](/zh/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。 +[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 定义描述了与运行 Pod +相关的开销。此准入控制器将相应地设置 `pod.spec.overhead` 字段。 -详情请参见 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/)。 +详情请参见 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)。 ### SecurityContextDeny {#securitycontextdeny} -该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 字段的 pod。 -如果集群没有使用 [pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)来限制安全上下文所能获取的值集，那么应该启用这个功能。 +该准入控制器将拒绝任何试图设置特定提升 +[SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) +字段的 Pod，正如任务 +[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) +中所展示的那样。 +如果集群没有使用 [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) +来限制安全上下文所能获取的值集，那么应该启用这个功能。 ### ServiceAccount {#serviceaccount} -该准入控制器实现了 [serviceAccounts](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。 -如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个准入控制器。 +此准入控制器实现了 +[ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +的自动化。 +如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 ### StorageObjectInUseProtection -`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 +`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 +`kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC） +或持久化卷（PV）中。 +如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 +PVC/PV 不会被删除。 +有关更多详细信息，请参考 +[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 ### TaintNodesByCondition {#taintnodesbycondition} + {{< feature-state for_k8s_version="v1.12" state="beta" >}} -该准入控制器 {{< glossary_tooltip text="污点" term_id="taint" >}} 新创建的 `NotReady` 和 `NoSchedule` 节点。 -避免了可能导致 Pod 在更新其污点以准确反映其所报告状况之前，就安排了在新节点上的竞争条件的情况。 +该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` +{{< glossary_tooltip text="污点" term_id="taint" >}}。 +这些污点能够避免一些竞态条件的发生，这类静态条件可能导致 Pod 在更新节点污点以准确 +反映其所报告状况之前，就被调度到新节点上。 ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} + {{< feature-state for_k8s_version="v1.13" state="beta" >}} -该准入控制器调用与请求匹配的所有验证 webhook。匹配的 webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 -该准入控制器仅在验证阶段运行；与 `MutatingAdmissionWebhook` 准入控制器所调用的 webhook 相反，它调用的 webhook 应该不会使对象出现变更。 +该准入控制器调用与请求匹配的所有验证 Webhook。 +匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 +该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` 准入控制器 +所调用的 Webhook 相反，它调用的 Webhook 应该不会使对象出现变更。 -如果以此方式调用的 webhook 有其它作用（如，配额递减），则它必须具有协调系统，因为不能保证后续的 webhook 或其他有效的准入控制器都允许请求完成。 +如果以此方式调用的 Webhook 有其它作用（如，降低配额），则它必须具有协调机制。 +这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。 - -如果您禁用了 ValidatingAdmissionWebhook，还必须在 `admissionregistration.k8s.io/v1beta1` 组/版本中使用 `--runtime-config` 标志来禁用 `ValidatingWebhookConfiguration` 对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 +如果你禁用了 ValidatingAdmissionWebhook，还必须通过 `--runtime-config` 标志来禁用 +`admissionregistration.k8s.io/v1beta1` 组/版本中的 `ValidatingWebhookConfiguration` +对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 ## 有推荐的准入控制器吗？ -有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 -因此您无需显式指定它们。您可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 +有。对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态 +（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 +因此，你无需显式指定它们。 +你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 {{< note >}} -`--admission-control` 在 1.10 中已废弃，已由 `--enable-admission-plugins` 取代。 +`--admission-control` 在 1.10 中已废弃，由 `--enable-admission-plugins` 取代。 {{< /note >}} - -对于 Kubernetes 1.9 及更早版本，我们建议使用 `--admission-control` 标志（**顺序很重要**）运行下面的一组准入控制器。 +对于 Kubernetes 1.9 及更早版本，我们建议使用 `--admission-control` 标志 +（**顺序很重要**）运行下面的一组准入控制器。 * v1.9 @@ -1260,19 +1367,20 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota ``` - + and a validating phase, and that for example `ResourceQuota` runs in the validating + phase, and therefore is the last admission controller to run. + `MutatingAdmissionWebhook` appears before it in this list, because it runs + in the mutating phase. + --> + * 需要重申的是，在 1.9 中，它们都发生在变更阶段和验证阶段，例如 `ResourceQuota` + 在验证阶段运行，因此是最后一个运行的准入控制器。 + `MutatingAdmissionWebhook` 出现在此列表的前面，因为它在变更阶段运行。 -* 需要重申的是，在 1.9 中，它们都发生在变更阶段和验证阶段，例如 `ResourceQuota` 在验证阶段运行，因此是最后一个运行的准入控制器。 - `MutatingAdmissionWebhook` 出现在此列表的前面，因为它在变更阶段运行。 - - + admission controllers ran in the exact order specified. + --> 对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。 + diff --git a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md index ab0854a207..2663bf357a 100644 --- a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -43,20 +43,19 @@ CertificateSigningRequest（CSR）资源用来向指定的签名者申请证书 ## 请求签名流程 {#request-signing-process} -_CertificateSigningRequest_ 资源类型允许客户使用它申请签名 X.509 证书。 -CertificateSigningRequest 对象 在 `spec.request` 中 包括一个 PEM 编码的 PKCS#10 签名请求。 -CertificateSigningRequest 使用 `spec.signerName` 字段表示 _签名者_（请求的接收方）。 +CertificateSigningRequest 资源类型允许客户使用它申请发放 X.509 证书。 +CertificateSigningRequest 对象 在 `spec.request` 中包含一个 PEM 编码的 PKCS#10 签名请求。 +CertificateSigningRequest 使用 `spec.signerName` 字段标示 _签名者_（请求的接收方）。 注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。 -一般来说，当 CSR 被批准通过，且证书被签名后，`status.certificate` 字段将包含一个 PEM 编码的 X.509 证书。 +一般来说，当 CSR 被批准通过，且证书被签名后，`status.certificate` 字段 +将包含一个 PEM 编码的 X.509 证书。 有些签名者在 `status.certificate` 字段中存储多个证书。 在这种情况下，签名者的说明文档应当指明附加证书的含义。 例如，这是要在 TLS 握手时提供的证书和中继证书。 + +PKCS#10 签名请求格式不允许设置证书的过期时间或者生命期。因此，证书的过期 +时间或者生命期必须通过类似 CSR 对象的注解字段这种形式来设置。 +尽管让签名者使用过期日期从理论上来讲也是可行的，目前还不存在哪个实现这样做了。 +（内置的签名者都是用相同的 `ClusterSigningDuration` 配置选项，而该选项 +中将生命期的默认值设为 1 年，且可通过 kube-controller-manager 的命令行选项 +`--cluster-signing-duration` 来更改。） + - -1. `kubernetes.io/kube-apiserver-client`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 - 1. 信任分发：签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。 - 1. 许可的主体 — 没有主体限制，但审核人和签名者可以选择不批准或不签署。 - 某些主体，比如集群管理员级别的用户或组，因部署和安装方式不同而不同， +1. `kubernetes.io/kube-apiserver-client`：签名的证书将被 API 服务器视为客户证书。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 + 1. 信任分发：签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：没有主体限制，但审核人和签名者可以选择不批准或不签署。 + 某些主体，比如集群管理员级别的用户或组因部署和安装方式不同而不同， 所以批准和签署之前需要进行额外仔细审查。 用来限制 `system:masters` 的 CertificateSubjectRestriction 准入插件默认处于启用状态， - 但它通常不是集群中唯一的 cluster-admin 主体。 - 1. 许可的 x509 扩展 - 允许 subjectAltName 和 key usage 扩展，弃用其他扩展。 - 1. 许可的密钥用途 - 必须包含 `[]string{"client auth"}`，但不能包含 `[]string{"digital signature", "key encipherment", "client auth"}` 之外的键。 - 1. 过期时间/证书有效期 - CSR 签名者和请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 1. 允许/不允许 CA 位 - 不允许。 - - -1. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。 - 1. 信任分发： 签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。 - 2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以 `"system:node:"` 开头 - 3. 许可的 x509 扩展 — 允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。 - 4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}` - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 6. 允许/不允许 CA 位 - 不允许。 - - -2. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 kube-apiserver 视为有效的 kubelet 服务证书，但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 - 1. 信任分发 ：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。 - 2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以`"system:node:"`开头 - 3. 许可的 x509 扩展 — 允许 key usage、DNSName/IPAddress subjectAltName 等扩展， - 禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。 - 至少有一个 DNS 或 IP 的 SubjectAltName 存在。 - 4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}` - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。 - 6. 允许/不允许 CA 位 - 不允许。 - - -3. `kubernetes.io/legacy-unknown`: 根本不能保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。稳定版的 CertificateSigningRequest API（`certificates.k8s.io/v1` 以及之后的版本） 不允许将 `signerName` 设置为 `kubernetes.io/legacy-unknown`。{{< glossary_tooltip term_id="kube-controller-manager" >}} 将不会自动批准它。 - 1. 信任分发：没有。有这个签名者在 Kubernetes 集群中没有标准的信任或分发。 - 2. 许可的主体 - 全部 - 3. 许可的 x509 扩展 — 允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。 - 4. 许可的密钥用途 - 全部 - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 6. 允许/不允许 CA 位 - 不允许。 - + 但它通常不是集群中唯一的集群管理员主体。 + 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 扩展，弃用其他扩展。 + 1. 许可的密钥用途：必须包含 `["client auth"]`，但不能包含 + `["digital signature", "key encipherment", "client auth"]` 之外的键。 + 1. 过期时间/证书有效期：通过 kube-controller-manager 中 `--cluster-signing-duration` + 标志来设置，由其中的签名者实施。 + 1. 允许/不允许 CA 位：不允许。 +2. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。 + 1. 信任分发：签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头 + 1. 许可的 x509 扩展：允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。 + 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` + 1. 过期时间/证书有效期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位：不允许。 + + +3. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 API 服务器视为有效的 kubelet 服务证书， + 但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 + 1. 信任分发：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头 + 1. 许可的 x509 扩展：允许 key usage、DNSName/IPAddress subjectAltName 等扩展， + 禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。 + 至少有一个 DNS 或 IP 的 SubjectAltName 存在。 + 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` + 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位：不允许。 + + +4. `kubernetes.io/legacy-unknown`: 不保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。 + 稳定版的 CertificateSigningRequest API（`certificates.k8s.io/v1` 以及之后的版本）不允许将 + `signerName` 设置为 `kubernetes.io/legacy-unknown`。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准这类请求。 + 1. 信任分发：没有。这个签名者在 Kubernetes 集群中没有标准的信任或分发。 + 1. 许可的主体：全部。 + 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。 + 1. 许可的密钥用途：全部。 + 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位 - 不允许。 + +{{< note >}} + +注意：所有这些故障仅在 kube-controller-manager 日志中报告。 +{{< /note >}} + -{{< note >}} -注意：所有这些故障仅在 kube-controller-manager 日志中报告。 -{{< /note >}} - -对于这些签名者，信任的分发发生在带外（out of band）。 -上述信任之外的任何信任都是完全巧合的。 +对于这些签名者，信任的分发发生在带外（out of band）。上述信任之外的任何信任都是完全巧合的。 例如，一些发行版可能会将 `kubernetes.io/legacy-unknown` 作为 kube-apiserver 的客户端证书， 但这个做法并不标准。 这些用途都没有以任何方式涉及到 ServiceAccount 中的 Secrets `.data[ca.crt]`。 -此 CA 证书包只保证使用默认的服务（`kubernetes.default.svc`）来验证到 kube-apiserver 的连接。 +此 CA 证书包只保证使用默认的服务（`kubernetes.default.svc`）来验证到 API 服务器的连接。 授权批准 CertificateSigningRequest： -* verbs（动词）: `get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests` -* verbs（动词）: `update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/approval` -* verbs（动词）: `approve`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `/` 或 `/*` +* verbs（动词）: `get`、`list`、`watch`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests` +* verbs（动词）: `update`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests/approval` +* verbs（动词）：`approve`， + group（组）：`certificates.k8s.io`， + resources（资源）：`signers`， + resourceName：`/` 或 `/*` 例如： @@ -336,58 +379,66 @@ To allow signing a CertificateSigningRequest: * Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status` * Verbs: `sign`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `/` or `/*` --> -授权签名 CertificateSigningRequest ： +授权签名 CertificateSigningRequest： -* verbs（动词）：`get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests` -* verbs（动词）：`update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/status` -* verbs（动词）：`sign`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `/` or `/*` +* verbs（动词）：`get`、`list`、`watch`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests` +* verbs（动词）：`update`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests/status` +* verbs（动词）：`sign`， + group（组）：`certificates.k8s.io`， + resources（资源）：`signers`， + resourceName：`/` 或 `/*` {{< codenew file="access/certificate-signing-request/clusterrole-sign.yaml" >}} -## 普通用户 {#nornal-user} +## 普通用户 {#normal-user} 为了让普通用户能够通过认证并调用 API，需要执行几个步骤。 -首先，该用户必须拥有 Kubernetes 集群签名的证书， -然后将该证书作为 API 调用的证书头或通过 kubectl 提供出来。 +首先，该用户必须拥有 Kubernetes 集群签发的证书， +然后将该证书作为 API 调用的 Certificate 头或通过 kubectl 提供。 ### 创建私钥 {#create-private-key} 下面的脚本展示了如何生成 PKI 私钥和 CSR。 -设置 CSR 的 CN 和 O 字段很重要。CN 是用户名，O 是该用户归属的组。 -你可以参考 [RBAC](/docs/reference/access-authn-authz/rbac/) 获取标准组的信息。 +设置 CSR 的 CN 和 O 属性很重要。CN 是用户名，O 是该用户归属的组。 +你可以参考 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。 -``` +```shell openssl genrsa -out john.key 2048 openssl req -new -key john.key -out john.csr ``` -### 创建申请证书的 Kubernetes 对象 {#create-certificate-request-kubernetes-object} +### 创建 CertificateSigningRequest {#create-certificatesigningrequest} 创建一个 CertificateSigningRequest，并通过 kubectl 将其提交到 Kubernetes 集群。 下面是生成 CertificateSigningRequest 的脚本。 -``` +```shell cat < 需要注意的几点: -- usage 字段必须是 'client auth' -- request 字段是 CSR 文件内容的 base64 编码值。 - 要得到该值，可以执行命令 ```cat john.csr | base64 | tr -d "\n"``` 。 +- `usage` 字段必须是 '`client auth`' +- `request` 字段是 CSR 文件内容的 base64 编码值。 + 要得到该值，可以执行命令 `cat john.csr | base64 | tr -d "\n"`。 -### 批准证书请求 {#approve-certificate-request} +### 批准证书签名请求 {#approve-certificate-signing-request} 使用 kubectl 创建 CSR 并批准。 -获取 CSR 列表 -``` +获取 CSR 列表： + +```shell kubectl get csr ``` -批准 CRS -``` +批准 CSR： + +```shell kubectl certificate approve john ``` ### 取得证书 {#get-the-certificate} -从 CSR 取得证书。 +从 CSR 取得证书： -``` +```shell kubectl get csr/john -o yaml ``` +证书的内容使用 base64 编码，存放在字段 `status.certificate`。 + -证书的内容使用 base64 编码，存放在字段 status.certificate。 - ### 创建角色和角色绑定 {#create-role-and-role-binding} -你已经拿到证书了。为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 Role 和 Role Binding 了。 +创建了证书之后，为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 +Role 和 RoleBinding 了。 -这是为这个新用户创建角色的示例脚本 +下面是为这个新用户创建 Role 的示例脚本： -``` +```shell kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods ``` -这是为这个新用户创建角色绑定的示例脚本 -``` +下面是为这个新用户创建 RoleBinding 的示例命令： + +```shell kubectl create rolebinding developer-binding-john --role=developer --user=john ``` -### 添加到 KubeConfig +### 添加到 kubeconfig {#add-to-kubeconfig} -最后一步是将这个用户添加到 KubeConfig。 +最后一步是将这个用户添加到 kubeconfig 文件。 我们假设私钥和证书文件存放在 “/home/vagrant/work/” 目录中。 -首先，我们需要添加新的凭据 +首先，我们需要添加新的凭据： -``` +```shell kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true ``` -然后，我们需要添加上下文 -``` +然后，你需要添加上下文： + +```shell kubectl config set-context john --cluster=kubernetes --user=john ``` -来测试一下，把 kubecontext 切换为 john -``` +来测试一下，把上下文切换为 `john`： + +```shell kubectl config use-context john ``` -### 使用 `kubectl` 批准和驳回 +### 使用 `kubectl` 批准或驳回 {#approval-rejection-kubectl} Kubernetes 管理员（拥有足够的权限）可以手工批准（或驳回）CertificateSigningRequests， 此操作使用 `kubectl certificate approve` 和 `kubectl certificate deny` 命令实现。 使用 kubectl 批准一个 CSR： -```bash +```shell kubectl certificate approve ``` + 同样地，驳回一个 CSR： -```bash +```shell kubectl certificate deny ``` -### 使用 Kubernetes API 批准和驳回 {#approval-rejection-api-client} +### 使用 Kubernetes API 批准或驳回 {#approval-rejection-api-client} REST API 的用户可以通过向待批准的 CSR 的 `approval` 子资源提交更新请求来批准 CSR。 例如，你可以编写一个 @@ -638,15 +696,16 @@ you like. If you want to add a note just for human consumption, use the ### Control plane signer {#signer-control-plane} -The Kubernetes control plane implements each of the [Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers), +The Kubernetes control plane implements each of the +[Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers), as part of the kube-controller-manager. Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that were marked as approved. --> -## 签名 +## 签名 {#signing} -### 控制平面签名者 +### 控制平面签名者 {#signer-control-plane} Kubernetes 控制平面实现了每一个 [Kubernetes 签名者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)， @@ -672,7 +731,7 @@ as described in [section 4 of RFC5280](https://tools.ietf.org/html/rfc5280#secti Example certificate content: --> -### 基于 API 的签名者 +### 基于 API 的签名者 {#signer-api} REST API 的用户可以通过向待签名的 CSR 的 `status` 子资源提交更新请求来对 CSR 进行签名。 @@ -728,11 +787,8 @@ status: certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..." ``` - - ## {{% heading "whatsnext" %}} - -基于角色（Role）的访问控制（RBAC）是一种基于企业中用户的角色来调节控制对计算机或网络资源的访问方法。 - +基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对 +计算机或网络资源的访问的方法。 -`RBAC` 使用 `rbac.authorization.k8s.io` {{< glossary_tooltip text="API 组" term_id="api-group" >}} -来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。 - -在 1.8 版本中，RBAC 模式是稳定的并通过 rbac.authorization.k8s.io/v1 API 提供支持。 - -要启用 RBAC，在启动 API 服务器时添加 `--authorization-mode=RBAC` 参数。 +RBAC 鉴权机制使用 `rbac.authorization.k8s.io` +{{< glossary_tooltip text="API 组" term_id="api-group" >}} +来驱动鉴权决定，允许你通过 Kubernetes API 动态配置策略。 +要启用 RBAC，在启动 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} +时将 `--authorization-mode` 参数设置为一个逗号分隔的列表并确保其中包含 `RBAC`。 -## API 概述 +```shell +kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项> +``` -本节介绍 RBAC API 所声明的四种顶级类型。用户可以像与其他 API 资源交互一样， -（通过 `kubectl`、API 调用等方式）与这些资源交互。例如， -命令 `kubectl apply -f (resource).yml` 可以用在这里的任何一个例子之上。 -尽管如此，建议读者循序渐进阅读下面的章节，由浅入深。 + +## API 对象 {#api-overview} + +RBAC API 声明了四种 Kubernetes 对象：_Role_、_ClusterRole_、_RoleBinding_ 和 +_ClusterRoleBinding_。你可以像使用其他 Kubernetes 对象一样， +通过类似 `kubectl` 这类工具 +[描述对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), +或修补对象。 + +{{< caution >}} + +这些对象在设计时即实施了一些访问限制。如果你在学习过程中对集群做了更改，请参考 +[避免特权提升和引导](#privilege-escalation-prevention-and-bootstrapping) +一节，以了解这些限制会以怎样的方式阻止你做出修改。 +{{< /caution >}} -### Role 和 ClusterRole +### Role 和 ClusterRole {#role-and-clusterole} -在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则）。 -角色可以用 `Role` 来定义到某个命名空间上， -或者用 `ClusterRole` 来定义到整个集群作用域。 +RBAC 的 _Role_ 或 _ClusterRole_ 中包含一组代表相关权限的规则。 +这些权限是纯粹累加的（不存在拒绝某操作的规则）。 -一个 `Role` 只可以用来对某一命名空间中的资源赋予访问权限。 -下面的 `Role` 示例定义到名称为 "default" 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限： +Role 总是用来在某个{{< glossary_tooltip text="名字空间" term_id="namespace" >}} +内设置访问权限；在你创建 Role 时，你必须指定该 Role 所属的名字空间。 + +与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 +ClusterRole）是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的， +不可两者兼具。 + + +ClusterRole 有若干用法。你可以用它来： + +1. 定义对某名字空间域对象的访问权限，并将在各个名字空间内完成授权； +1. 为名字空间作用域的对象设置访问权限，并跨所有名字空间执行授权； +1. 为集群作用域的资源定义访问权限。 + +如果你希望在名字空间内定义角色，应该使用 Role； +如果你希望定义集群范围的角色，应该使用 ClusterRole。 + + +#### Role 示例 + +下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 +{{< glossary_tooltip text="pods" term_id="pod" >}} 的读访问权限： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -117,141 +135,155 @@ metadata: namespace: default name: pod-reader rules: -- apiGroups: [""] # "" 指定核心 API 组 +- apiGroups: [""] # "" 标明 core API 组 resources: ["pods"] verbs: ["get", "watch", "list"] ``` -`ClusterRole` 可以授予的权限和 `Role` 相同， -但是因为 `ClusterRole` 属于集群范围，所以它也可以授予以下访问权限： + +### ClusterRole 示例 + +ClusterRole 可以和 Role 相同完成授权。 +因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限： + +* 集群范围资源（比如 {{< glossary_tooltip text="节点（Node）" term_id="node" >}}） +* 非资源端点（比如 `/healthz`） +* 跨名字空间访问的名字空间作用域的资源（如 Pods），比如，你可以使用 + ClusterRole 来允许某特定用户执行 `kubectl get pods --all-namespaces` + + +下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 +{{< glossary_tooltip text="Secret" term_id="secret" >}} 授予读访问权限， +或者跨名字空间的访问权限（取决于该角色是如何[绑定](#rolebinding-and-clusterrolebinding)的）： ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: - # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。 + # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制 name: secret-reader rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"] ``` + +Role 或 ClusterRole 对象的名称必须是合法的 +[路径区段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。 + +### RoleBinding 和 ClusterRoleBinding {#rolebinding-and-clusterrolebinding} + +角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 +它包含若干 **主体**（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 +RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。 + +一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 +或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 +RoleBinding 所在的名字空间。 +如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。 + +RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的 +[路径区段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。 + + -### RoleBinding 和 ClusterRoleBinding +#### RoleBinding 示例 {#rolebinding-example} -角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户。 -它包含若干主体（用户，组和服务账户）的列表和对这些主体所获得的角色的引用。 -可以使用 `RoleBinding` 在指定的命名空间中执行授权， -或者在集群范围的命名空间使用 `ClusterRoleBinding` 来执行授权。 - -一个 `RoleBinding` 可以引用同一的命名空间中的 `Role` 。 -下面的例子 `RoleBinding` 将 "pod-reader" 角色授予在 "default" 命名空间中的用户 "jane"； -这样，用户 "jane" 就具有了读取 "default" 命名空间中 pods 的权限。 - -`roleRef` 里的内容决定了实际创建绑定的方法。`kind` 可以是 `Role` 或 `ClusterRole`， -`name` 将引用你要指定的 `Role` 或 `ClusterRole` 的名称。在下面的例子中，角色绑定使用 -`roleRef` 将用户 "jane" 绑定到前文创建的角色 `Role`，其名称是 `pod-reader`。 +下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 +这样，用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# 此角色绑定使得用户 "jane" 能够读取 "default" 命名空间中的 Pods +# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods kind: RoleBinding metadata: name: read-pods namespace: default subjects: +# 你可以指定不止一个“subject（主体）” - kind: User - name: jane # Name is case sensitive + name: jane # "name" 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: - kind: Role #this must be Role or ClusterRole - name: pod-reader # 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致 + # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 + kind: Role # 此字段必须是 Role 或 ClusterRole + name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io ``` -`RoleBinding` 也可以引用 `ClusterRole`，对 `ClusterRole` 所定义的、位于 `RoleBinding` 命名空间内的资源授权。 -这可以允许管理者在 -整个集群中定义一组通用的角色，然后在多个命名空间中重用它们。 - -例如下面的例子，`RoleBinding` 指定的是 `ClusterRole`， -"dave" （主体，区分大小写）将只可以读取在"development" -命名空间（ `RoleBinding` 的命名空间）中的"secrets"。 +RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 +RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， +之后在多个名字空间中复用。 +例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，"dave"（这里的主体， +不区分大小写）只能访问 "development" 名字空间中的 Secrets 对象，因为 RoleBinding +所在的名字空间（由其 metadata 决定）是 "development"。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 +# 此角色绑定使得用户 "dave" 能够读取 "default" 名字空间中的 Secrets +# 你需要一个名为 "secret-reader" 的 ClusterRole kind: RoleBinding metadata: name: read-secrets - namespace: development # 这里只授予 "development" 命名空间的权限。 + # RoleBinding 的名字空间决定了访问权限的授予范围。 + # 这里仅授权在 "development" 名字空间内的访问权限。 + namespace: development subjects: - kind: User - name: dave # 名称区分大小写 + name: dave # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole @@ -260,19 +292,27 @@ roleRef: ``` +#### ClusterRoleBinding 示例 {#clusterrolebinding-example} + +要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 +下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 +Secrets。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. +# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group - name: manager # Name is case sensitive + name: manager # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole @@ -280,11 +320,21 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -You cannot modify which `Role` or `ClusterRole` a binding object refers to. -Attempts to change the `roleRef` field of a binding object will result in a validation error. -To change the `roleRef` field on an existing binding object, the binding object must be deleted and recreated. -There are two primary reasons for this restriction: + +创建了绑定之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。 +试图改变绑定对象的 `roleRef` 将导致合法性检查错误。 +如果你想要改变现有绑定对象中 `roleRef` 字段的内容，必须删除重新创建绑定对象。 + +这种限制有两个主要原因： + + +1. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`, + 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许修改 + `roleRef` 的情况下导致所有现有主体胃镜验证即被授予新角色对应的权限）。 +1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限， + 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。 + - -最后，`ClusterRoleBinding` 可用来在集群级别或对所有命名空间执行授权。 -下面的例子允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -# 这个集群角色绑定允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 -kind: ClusterRoleBinding -metadata: - name: read-secrets-global -subjects: -- kind: Group - name: manager # 名称区分大小写 - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: secret-reader - apiGroup: rbac.authorization.k8s.io -``` - -你不能修改绑定对象所引用的 `Role` 或 `ClusterRole` 。 -试图改变绑定对象的 `roleRef` 将导致验证错误。想要 -改变现有绑定对象中 `roleRef` 字段的内容，必须删除并 -重新创建绑定对象。这种限制有两个主要原因： - -1.关于不同角色的绑定是完全不一样的。更改 `roleRef` - 需要删除/重建绑定，确保要赋予绑定的完整主体列表是新 -的角色（而不是只是启用修改 `roleRef` 在不验证所有现有 -主体的情况下的，应该授予新角色对应的权限）。 - -2.使得 `roleRef` 不可以改变现有绑定主体用户的 `update` 权限， -这样可以让它们能够管理主体列表，而不能更改授予这些主体相关 -的角色。 - 命令 `kubectl auth reconcile` 可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。 更多相关信息请参照[命令用法和示例](#kubectl-auth-reconcile) @@ -339,42 +362,33 @@ roleRef: -### 对资源的引用 +### 对资源的引用 {#referring-to-resources} -大多数资源都是使用名称的字符串表示，例如在相关的 API 端点的 URL 之中出现的 "pods" 。 -然而有一些 Kubernetes API 涉及 "子资源（subresources）"，例如 pod 的日志。Pod 日志相关的端点 URL 如下： +在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。 +例如，对于 Pod 应使用 "pods"。 +RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 +有一些 Kubernetes API 涉及 **子资源（subresource）**，例如 Pod 的日志。 +对 Pod 日志的请求看起来像这样： ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -在这种情况下，"pods" 是有命名空间的资源，而 "log" 是 pods 的子资源。在 RBAC 角色中， -使用"/"分隔资源和子资源。允许一个主体要同时读取 pods 和 pod logs，你可以这么写： - + +在这里，`pods` 对应名字空间作用域的 Pod 资源，而 `log` 是 `pods` 的子资源。 +在 RBAC 角色表达子资源时，使用斜线（`/`）来分隔资源和子资源。 +要允许某主体读取 `pods` 同时访问这些 Pod 的 `log` 子资源，你可以这么写： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -389,29 +403,15 @@ rules: ``` 对于某些请求，也可以通过 `resourceNames` 列表按名称引用资源。 -在指定时，可以将请求类型限制资源的单个实例。限制只可以 "get" 和 "update" -的单一configmap，你可以这么写： +在指定时，可以将请求限定为资源的单个实例。 +下面的例子中限制可以 "get" 和 "update" 一个名为 `my-configmap` 的 +{{< glossary_tooltip term_id="ConfigMap" >}}： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -421,56 +421,42 @@ metadata: name: configmap-updater rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 ConfigMap 的资源的名称为 "configmaps" resources: ["configmaps"] resourceNames: ["my-configmap"] verbs: ["update", "get"] ``` -需要注意的是，`create` 请求不能被 resourceName 限制，因为在鉴权时还不知道对象名称。 -另一个例外是 `deletecollection`。 - +{{< note >}} +你不能针对 `create` 或者 `deletecollection` 请求来实施 resourceName 限制。 +对于 `create` 操作而言，这是因为在鉴权时还不知道对象名称。 +{{< /note >}} + + +### 聚合的 ClusterRole {#aggregated-clusterroles} + +你可以将若干 ClusterRole **聚合（Aggregate）** 起来，形成一个复合的 ClusterRole。 +某个控制器作为集群控制面的一部分会监视带有 `aggregationRule` 的 ClusterRole +对象集合。`aggregationRule` 为控制器定义一个标签 +{{< glossary_tooltip text="选择算符" term_id="selector" >}}供后者匹配 +应该组合到当前 ClusterRole 的 `roles` 字段中的 ClusterRole 对象。 + +下面是一个聚合 ClusterRole 的示例： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -481,12 +467,19 @@ aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true" -rules: [] # 具体规则由控制器管理器自动填写。 +rules: [] # 控制面自动填充这里的规则 ``` -创建一个与标签选择器匹配的 ClusterRole 之后，其上定义的规则将成为聚合集群角色的一部分。在下面的例子中， -通过创建一个新的、标签同样为 `rbac.example.com/aggregate-to-monitoring: true` 的 -ClusterRole，新的规则可被添加到 "monitoring" 集群角色中。 + +如果你创建一个与某现有聚合 ClusterRole 的标签选择算符匹配的 ClusterRole， +这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。 +下面的例子中，通过创建一个标签同样为 `rbac.example.com/aggregate-to-monitoring: true` +的 ClusterRole，新的规则可被添加到 "monitoring" ClusterRole 中。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -495,7 +488,8 @@ metadata: name: monitoring-endpoints labels: rbac.example.com/aggregate-to-monitoring: "true" -# 这些规则将被添加到 "monitoring" 角色中。 +# 当你创建 "monitoring-endpoints" ClusterRole 时， +# 下面的规则会被添加到 "monitoring" ClusterRole 中 rules: - apiGroups: [""] resources: ["services", "endpoints", "pods"] @@ -503,12 +497,22 @@ rules: ``` +默认的[面向用户的角色](#default-roles-and-role-bindings) 使用 ClusterRole 聚合。 +这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则， +比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。 + +例如，下面的 ClusterRoles 让默认角色 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， + "view" 角色对 CronTab 资源拥有读操作权限。 +你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 `"crontabs"`。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -516,7 +520,7 @@ kind: ClusterRole metadata: name: aggregate-cron-tabs-edit labels: - # Add these permissions to the "admin" and "edit" default roles. + # 添加以下权限到默认角色 "admin" 和 "edit" 中 rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: @@ -529,41 +533,7 @@ apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: - # Add these permissions to the "view" default role. - rbac.authorization.k8s.io/aggregate-to-view: "true" -rules: -- apiGroups: ["stable.example.com"] - resources: ["crontabs"] - verbs: ["get", "list", "watch"] -``` ---> - -默认的面向用户的角色（如下所述）使用 ClusterRole 聚合。这使得管理者可以为自定义资源设置使用规则属性， -比如通过 CustomResourceDefinitions 或聚合 API 服务器为默认角色提供的服务。 - -例如，在以下 ClusterRoles 中让 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， - "view" 角色对资源有只读操作权限。 - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: aggregate-cron-tabs-edit - labels: - # 将这些权限添加到默认角色 "admin" 和 "edit" 中。 - rbac.authorization.k8s.io/aggregate-to-admin: "true" - rbac.authorization.k8s.io/aggregate-to-edit: "true" -rules: -- apiGroups: ["stable.example.com"] - resources: ["crontabs"] - verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ---- -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: aggregate-cron-tabs-view - labels: - # 将这些权限添加到默认角色 "view" 中。 + # 添加以下权限到 "view" 默认角色中 rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["stable.example.com"] @@ -574,50 +544,33 @@ rules: -#### 角色示例 +#### Role 示例 {#role-examples} -在以下示例中，我们仅截取展示了 `rules` 对应部分， -允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的 Pods: +以下示例均为从 Role 或 CLusterRole 对象中截取出来，我们仅展示其 `rules` 部分。 + +允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的 +`"Pods"`： ```yaml rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 Pod 的资源的名称为 "pods" resources: ["pods"] verbs: ["get", "list", "watch"] ``` -允许读/写在 "extensions" 和 "apps" API 组中的 "deployments" 资源： + +允许读/写在 "extensions" 和 "apps" API 组中的 Deployment（在 HTTP 层面，对应 +URL 中资源部分为 "deployments"）： ```yaml rules: @@ -626,7 +579,12 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -允许读取 "pods" 和读/写 "jobs" : + +允许读取核心 API 组中的 "pods" 和读/写 `"batch"` 或 `"extensions"` API 组中的 +"jobs"： ```yaml rules: @@ -639,34 +597,11 @@ rules: ``` -允许读取名称为 "my-config"的 `ConfigMap` （需要通过 `RoleBinding` 绑定带某名字空间中特定的 `ConfigMap`）： +允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以 +限制为某名字空间中特定的 ConfigMap）： ```yaml rules: @@ -676,7 +611,13 @@ rules: verbs: ["get"] ``` -允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群范围的，所以需要 `ClusterRole` 绑定到 `ClusterRoleBinding` 才生效） + +允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群作用域的，所以需要 +ClusterRole 绑定到 ClusterRoleBinding 才生效）： ```yaml rules: @@ -685,89 +626,98 @@ rules: verbs: ["get", "list", "watch"] ``` -允许在非资源端点 "/healthz" 和其子路径上发起 "GET" 和 "POST" 请求（必须在 `ClusterRole` 绑定 `ClusterRoleBinding` 才生效） + +允许针对非资源端点 `/healthz` 和其子路径上发起 GET 和 POST 请求 +（必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）： ```yaml rules: -- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' 在 nonResourceURL 中的意思是后缀全局匹配。 - verbs: ["get", "post"] + - nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符 + verbs: ["get", "post"] ``` +### 对主体的引用 {#referring-to-subjects} -Group information in Kubernetes is currently provided by the Authenticator -modules. Groups, like users, are represented as strings, and that string -has no format requirements, other than that the prefix `system:` is reserved. +RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 *主体（Subject）*上。 +主体可以是组，用户或者 +{{< glossary_tooltip text="服务账号" term_id="service-account" >}}。 + +Kubernetes 用字符串来表示用户名。 +用户名可以是普通的用户名，像 "alice"；或者是邮件风格的名称，如 "bob@example.com"， +或者是以字符串形式表达的数字 ID。 +你作为 Kubernetes 管理员负责配置 +[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/) +以便后者能够生成你所期望的格式的用户名。 + + +{{< caution >}} + +前缀 `system:` 是 Kubernetes 系统保留的，所以你要确保 +所配置的用户名或者组名不能出现上述 `system:` 前缀。 +除了对前缀的限制之外，RBAC 鉴权系统不对用户名格式作任何要求。 +{{< /caution >}} + + -### 对主体的引用 +在 Kubernetes 中，鉴权模块提供用户组信息。 +与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， +只是不能使用保留的前缀 `system:`。 -`RoleBinding` 或者 `ClusterRoleBinding` 需要绑定角色到 *主体*。 -主体可以是组，用户或者服务账户。 +[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +的用户名前缀为 `system:serviceaccount:`，属于前缀为 `system:serviceaccounts:` +的用户组。 -用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是 -邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/) -需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的， -所以管理员要确保配置的用户名不能出现上述前缀格式。 - -用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求， -只是不能使用保留的前缀 `system:` 。 - -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`， -属于前缀为 `system:serviceaccounts:` 的用户组。 +{{< note >}} + +- `system:serviceaccount:` （单数）是用于服务账号用户名的前缀； +- `system:serviceaccounts:` （复数）是用于服务账号组名的前缀。 +{{< /note >}} -#### RoleBinding的示例 +#### RoleBinding 示例 {#role-binding-examples} -下面的示例只是展示 `RoleBinding` 中 `subjects` 的部分。 +下面示例是 `RoleBinding` 中的片段，仅展示其 `subjects` 的部分。 -用户的名称为 "alice@example.com": +对于名称为 `alice@example.com` 的用户： ```yaml subjects: @@ -776,7 +726,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -组的名称为 "frontend-admins": + +对于名称为 `frontend-admins` 的用户组： ```yaml subjects: @@ -785,7 +738,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -服务账号在 kube-system 命名空间中: + +对于 `kube-system` 名字空间中的默认服务账号： ```yaml subjects: @@ -794,17 +750,10 @@ subjects: namespace: kube-system ``` -在名称为 "qa" 命名空间中所有的服务账号: - -```yaml -subjects: -- kind: Group - name: system:serviceaccounts:qa - apiGroup: rbac.authorization.k8s.io -``` - +对于 "qa" 名字空间中所有的服务账号： ```yaml subjects: @@ -813,47 +762,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all service accounts everywhere: - -```yaml -subjects: -- kind: Group - name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io -``` - -For all authenticated users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:authenticated - apiGroup: rbac.authorization.k8s.io -``` - -For all unauthenticated users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:unauthenticated - apiGroup: rbac.authorization.k8s.io -``` - -For all users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:authenticated - apiGroup: rbac.authorization.k8s.io -- kind: Group - name: system:unauthenticated - apiGroup: rbac.authorization.k8s.io -``` + - -所有的服务账号: +对于在任何名字空间中的服务账号： ```yaml subjects: @@ -862,7 +774,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有认证过的用户 （版本 1.5+）: + +对于所有已经过认证的用户： ```yaml subjects: @@ -871,7 +786,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有未认证的用户 （版本 1.5+）: + +对于所有未通过认证的用户： ```yaml subjects: @@ -880,7 +798,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有用户 （版本 1.5+）: + +对于所有用户： ```yaml subjects: @@ -893,64 +814,95 @@ subjects: ``` ## 默认 Roles 和 Role Bindings -API servers创建一组默认为 `ClusterRole` 和 `ClusterRoleBinding` 的对象。 -其中许多是以 `system:` 为前缀的，它表示资源是基础设施 "owned" 的。对于这些资源的修改可能导致集群功能失效。 -例如，`system:node` 是集群角色，它是定义 kubelets 相关的权限，如果这个角色被修改，它将导致 kubelets 无法正常工作。 +API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 +这其中许多是以 `system:` 为前缀的，用以标识对应资源是直接由集群控制面管理的。 +所有的默认 ClusterRole 和 ClusterRoleBinding 都有 +`kubernetes.io/bootstrapping=rbac-defaults` +标签。 -所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 `kubernetes.io/bootstrapping=rbac-defaults`。 +{{< caution >}} + +在修改名称包含 `system:` 前缀的 ClusterRole 和 ClusterRoleBinding +时要格外小心。 +对这些资源的更改可能导致集群无法继续工作。 +{{< /caution >}} -### 自动更新 +### 自动协商 {#auto-reconciliation} -在每次启动时，API Server 都会更新默认 ClusterRole 所缺少的各种权限，并更新默认 ClusterRoleBinding 所缺少的各个角色绑定主体。 -这种自动更新机制允许集群去修复一些特殊的修改。 -由于权限和角色绑定主体在新的 Kubernetes 版本中可能发生变化，所以这样的话也能够保证角色和角色绑定始终保持是最新的。 +在每次启动时，API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限，并更新 +默认的 ClusterRoleBinding 以增加缺失的的各类主体。 +这种自动协商机制允许集群去修复一些不小心发生的修改，并且有助于保证角色和角色绑定 +在新的发行版本中有权限或主体变更时仍然保持最新。 -如果要禁止此功能,请将默认ClusterRole以及ClusterRoleBinding的`rbac.authorization.kubernetes.io/autoupdate`设置成`false`。 +如果要禁止此功能，请将默认 ClusterRole 以及 ClusterRoleBinding 的 +`rbac.authorization.kubernetes.io/autoupdate` 注解设置成 `false`。 +注意，缺少默认权限和角色绑定主体可能会导致集群无法正常工作。 -注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。 - -自动更新功能在 Kubernetes 版本1.6+ 的 RBAC 认证是默认开启的。 +如果基于 RBAC 的鉴权机制被启用，则自动协商功能默认是被启用的。 +### API 发现角色 {#discovery-roles} -``` +无论是经过身份验证的还是未经过身份验证的用户，默认的角色绑定都授权他们读取被认为 +是可安全地公开访问的 API（ 包括 CustomResourceDefinitions）。 +如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中中添加 +`--anonymous-auth=false` 的配置选项。 + +通过运行命令 `kubectl` 可以查看这些角色的配置信息: + +```shell kubectl get clusterroles system:discovery -o yaml ``` -NOTE: editing the role is not recommended as changes will be overwritten on API server restart via auto-reconciliation (see above). +{{< note >}} + +如果你编辑该 ClusterRole，你所作的变更会被 API 服务器在重启时自动覆盖，这是通过 +[自动协商](#auto-reconciliation)机制完成的。要避免这类覆盖操作， +要么不要手动编辑这些角色，要么禁止自动协商机制。 +{{< /note >}} + + + -### Discovery Roles - -无论是经过身份验证的还是未经过身份验证的用户，默认角色的用户读取API被认为是安全的，可以公开访问（包括CustomResourceDefinitions）， -如果要禁用匿名未经过身份验证的用户访问，请在 API server 中添加 `--anonymous-auth=false` 的配置选项。 - -通过运行命令 `kubectl` 可以查看这些角色的配置信息: - -``` -kubectl get clusterroles system:discovery -o yaml -``` - -注意：不建议编辑这个角色，因为更改将在 API server 重启时自动更新时覆盖（见上文） - -
Kubernetes RBAC API 发现角色
- - @@ -996,31 +930,44 @@ kubectl get clusterroles system:discovery -o yaml - + - + - +
默认 ClusterRole 默认 ClusterRoleBinding 描述
system:basic-user system:authenticated 组允许用户以只读的方式去访问他们自己的基本信息。在1.14版本之前，这个角色在默认情况下也绑定在 `system:unauthenticated` 上。允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前，这个角色在 +默认情况下也绑定在 system:unauthenticated 上。
system:discovery system:authenticated 组允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。在1.14版本之前，这个角色在默认情况下绑定在 `system:unauthenticated` 上。允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。 +在 1.14 版本之前，这个角色在默认情况下绑定在 system:unauthenticated 上。
system:public-info-viewer system:authenticated 和 system:unauthenticated 组允许对集群的非敏感信息进行只读访问，它是在1.14版本中引入的。允许对集群的非敏感信息进行只读访问，它是在 1.14 版本中引入的。
+### 面向用户的角色 {#user-facing-roles} + +一些默认的 ClusterRole 不是以前缀 `system:` 开头的。这些是面向用户的角色。 +它们包括超级用户（Super-User）角色（`cluster-admin`）、 +使用 ClusterRoleBinding 在集群范围内完成授权的角色（`cluster-status`）、 +以及使用 RoleBinding 在特定名字空间中授予的角色（`admin`、`edit`、`view`）。 + +面向用户的 ClusterRole 使用 [ClusterRole 聚合](#aggregated-clusterroles)以允许管理员在 +这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 `admin`、`edit` 或者 `view`， +可以创建带有以下一个或多个标签的 ClusterRole： ```yaml metadata: @@ -1033,425 +980,352 @@ metadata: + -### 面向用户的角色 - -一些默认的角色不是前缀 `system:` 开头的。这些是面向用户的角色。它们包括 super-user 角色（`cluster-admin`）， -使用 ClusterRoleBindings （`cluster-status`）在集群范围内授予角色， -以及使用 RoleBindings （`admin`, `edit`, `view`）在特定命名空间中授予的角色。 - -在 1.9 开始，面向用户的角色使用[ClusterRole Aggregation](#aggregated-clusterroles)允许管理员在包含这些角色上的 -自定义资源上添加规则。如果想要添加 "admin" "edit" 或者 "view" ，需要先创建使用以下一个或多个的 ClusterRole 的标签： - -```yaml -metadata: - labels: - rbac.authorization.k8s.io/aggregate-to-admin: "true" - rbac.authorization.k8s.io/aggregate-to-edit: "true" - rbac.authorization.k8s.io/aggregate-to-view: "true" -``` - -
- - - + - + + + - + + + - + + + + - + +
默认 ClusterRole 默认 ClusterRoleBinding 描述
cluster-admin system:masters 组允许超级用户在平台上的任何资源的所有操作。 -当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有命名空间中的全部资源进行完全控制。 -当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在命名空间中的所有资源，包括命名空间本身。允许超级用户在平台上的任何资源上执行所有操作。 +当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有名字空间中的全部资源进行完全控制。 +当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在名字空间中的所有资源，包括名字空间本身。
admin 无允许管理员访问权限，旨在使用 RoleBinding 在命名空间内执行授权。 -如果在 RoleBinding 中使用，则可授予对命名空间中的大多数资源的读/写权限， -包括创建角色和绑定角色（RoleBinding）的能力。 -但是它不允许对资源配额或者命名空间本身进行写操作。允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。 +如果在 RoleBinding 中使用，则可授予对名字空间中的大多数资源的读/写权限， +包括创建角色和角色绑定的能力。 +但是它不允许对资源配额或者名字空间本身进行写操作。
edit 无允许对命名空间的大多数对象进行读/写操作。 -它不允许查看或者修改角色（Roles）或者角色绑定（RoleBindings）。允许对名字空间的大多数对象进行读/写操作。 +它不允许查看或者修改角色或者角色绑定。 +不过，此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pods， +所以可以用来了解名字空间内所有服务账号的 API 访问级别。 +
view 无允许对命名空间的大多数对象有只读权限。 -它不允许查看角色（Roles）或角色绑定（RoleBindings）。 -它不允许查看 Secrets，因为这类操作属于越权。允许对名字空间的大多数对象有只读权限。 +它不允许查看角色或角色绑定。 + +此角色不允许查看 Secrets，因为读取 Secret 的内容意味着可以访问名字空间中 +ServiceAccount 的凭据信息，进而允许利用名字空间中任何 ServiceAccount 的 +身份访问 API（这是一种特权提升）。
+### 核心组件角色 {#core-component-roles} + - + + - + + - + + - - -As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. -Prior to 1.7, this role was automatically bound to the `system:nodes` group. -In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled. -In 1.8+, no binding is automatically created. + + - - -
system:kube-scheduler system:kube-scheduler userAllows access to the resources required by the kube-scheduler component.允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} +组件所需要的资源。
system:volume-scheduler system:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.允许访问 kube-scheduler 组件所需要的卷资源。
system:kube-controller-manager system:kube-controller-manager userAllows access to the resources required by the kube-controller-manager component. -The permissions required by individual control loops are contained in the controller roles.允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} +组件所需要的资源。 +各个控制回路所需要的权限在控制器角色 详述。
system:nodeNone in 1.8+Allows access to resources required by the kubelet component, including read access to all secrets, and write access to all pod status objects. + +无允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。 + +你应该使用 Node 鉴权组件 和 +NodeRestriction 准入插件 +而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 +kubelet 对 API 的访问。 +system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
system:node-proxier system:kube-proxy userAllows access to the resources required by the kube-proxy component.
---> -### 核心组件角色 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
默认 ClusterRole默认 ClusterRoleBinding描述
system:kube-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的资源。
system:volume-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的的卷资源。
system:kube-controller-managersystem:kube-controller-manager 用户允许访问 kube-controller-manager 组件所需要的资源。 -各个控制环所需要的权限包含在 controller roles 之中。
system:node在版本1.8之后无允许访问 kubelet 组件所需要的资源，它包括读取所有的 Secrets 和对所有 Pod 状态对象的写操作。 - -从版本 1.7 开始，推荐使用 Node authorizer 和 NodeRestriction 准入插件 来代替这个角色，它允许基于 kubelet 上调度执行的 Pods 来授权对 kubelet API 的访问。 -在版本 1.7 之前，这个角色会自动绑定到 `system:nodes` 组。 -在版本 1.7中，如果未启用`Node` 鉴权模式，这个角色将自动绑定到 `system:nodes` 组 -在版本 1.8+ 之后，不再自动创建绑定。 -
system:node-proxiersystem:kube-proxy 用户允许访问 kube-proxy 组件所需要的资源。允许访问 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +组件所需要的资源。
-### 其他组件角色 +### 其他组件角色 {#other-component-roles} + + - + + + - + + + + - + + + + - + + + + +kubelet TLS 启动引导 +所需要的资源。 + + + - + +
默认 ClusterRole 默认 ClusterRoleBinding 描述
system:auth-delegator 无允许代理身份认证和鉴权， -它通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。允许将身份认证和鉴权检查操作外包出去。 +这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
system:heapster 无为 Heapster 组件定义的角色。为 Heapster 组件（已弃用）定义的角色。
system:kube-aggregator 无 为 kube-aggregator 组件定义的角色。
system:kube-dns在kube-system命名空间中的kube-dns服务账号在 kube-system 名字空间中的 kube-dns 服务账号 为 kube-dns 组件定义的角色。
system:kubelet-api-admin 无允许完全访问 kubelet API 。允许 kubelet API 的完全访问权限。
system:node-bootstrapper 无 允许访问执行 -Kubelet TLS 启动引导 所需要的资源。
system:node-problem-detector 无 为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner 无允许访问大部分的 动态卷驱动 所需要的资源。允许访问大部分 +动态卷驱动 +所需要的资源。
-### 控制器角色 {#controller-roles} +### 内置控制器的角色 {#controller-roles} -[Kubernetes 控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 运行核心控制环。 -当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。 -每个控制环都有相应的、前缀为 `system:controller:` 的角色。 +Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} +运行内建于 Kubernetes 控制面的{{< glossary_tooltip term_id="controller" text="控制器" >}}。 +当使用 `--use-service-account-credentials` 参数启动时, kube-controller-manager +使用单独的服务账号来启动每个控制器。 +每个内置控制器都有相应的、前缀为 `system:controller:` 的角色。 如果控制管理器启动时未设置 `--use-service-account-credentials`， -它使用自己的身份信息来运行所有的控制环，该身份必须被授予所有相关的角色。 +它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 这些角色包括: -* system:controller:attachdetach-controller -* system:controller:certificate-controller -* system:controller:clusterrole-aggregation-controller -* system:controller:cronjob-controller -* system:controller:daemon-set-controller -* system:controller:deployment-controller -* system:controller:disruption-controller -* system:controller:endpoint-controller -* system:controller:expand-controller -* system:controller:generic-garbage-collector -* system:controller:horizontal-pod-autoscaler -* system:controller:job-controller -* system:controller:namespace-controller -* system:controller:node-controller -* system:controller:persistent-volume-binder -* system:controller:pod-garbage-collector -* system:controller:pv-protection-controller -* system:controller:pvc-protection-controller -* system:controller:replicaset-controller -* system:controller:replication-controller -* system:controller:resourcequota-controller -* system:controller:root-ca-cert-publisher -* system:controller:route-controller -* system:controller:service-account-controller -* system:controller:service-controller -* system:controller:statefulset-controller -* system:controller:ttl-controller +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` -## 初始化与预防权限升级 +## 初始化与预防权限提升 -RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 -由于这一点是在 API 级别实现的，所以在 RBAC 鉴权器（RBAC authorizer）未启用的状态下依然可以正常工作。 - -用户只有在符合下列条件之一的情况下，才能创建/更新角色: - - -1. 他们已经拥有角色中包含的所有权限，且其作用域与正被修改的对象相同。 -（对 `ClusterRole` 而言意味着集群范围，对 `Role` 而言意味着相同命名空间或者集群范围） -2. 他们被明确允许在 `rbac.authorization.k8s.io` API 组中的 `roles` 或者 `clusterroles` 资源上使用 `escalate` 动词（Kubernetes 版本 1.12 及以上） - -例如，如果 "user-1" 没有列举集群范围所有 Secrets 的权限，他将不能创建包含对应权限的 `ClusterRole`。 -若要允许用户创建/更新角色： - -根据需要授予他们一个角色，允许他们根据需要创建/更新 `Role` 或者 `ClusterRole` 对象。 -2. 授予他们在所创建/更新角色中包含特殊权限的权限: - * 隐式的，通过给他们权限（如果它们试图创建或者更改 `Role` 或 `ClusterRole` 的权限，但自身没有被授权，API 请求将被禁止） - * 或通过允许他们在 `Role` 或 `ClusterRole` 资源上执行 `escalate` 动作的权限，它包含在 `rbac.authorization.k8s.io` API 组中 （Kubernetes 1.12 及以上版本） - -如果用户已经拥有引用角色中包含的权限，那他则只能创建/更新角色绑定。 -（在角色绑定相同的作用域内）*或* 如果他们被授予对所引用角色执行 `bind` 操作的显式权限。 -例如，如果 "user-1" 没有集群范围内 Secret 的列表权限，他就不能创建可以授予角色权限的 `ClusterRoleBinding`。 -通过以下方法可以允许用户创建/更新角色绑定： - -授予他们一个角色，允许他们根据需要创建/更新 `RoleBinding` 或者`ClusterRoleBinding` 对象。 -2. 授予他们绑定特定角色所需的权限: - * 隐式地，通过给他们授予角色中包含的权限。 - * 显式地，通过允许他们对特定角色（或集群角色）执行`bind` 操作的权限。 +RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 +由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。 +### 对角色创建或更新的限制 + +只有在符合下列条件之一的情况下，你才能创建/更新角色: + +1. 你已经拥有角色中包含的所有权限，且其作用域与正被修改的对象作用域相同。 + （对 ClusterRole 而言意味着集群范围，对 Role 而言意味着相同名字空间或者集群范围）。 +2. 你被显式授权在 `rbac.authorization.k8s.io` API 组中的 `roles` 或 `clusterroles` 资源 + 使用 `escalate` 动词。 + + +例如，如果 `user-1` 没有列举集群范围所有 Secret 的权限，他将不能创建包含该权限的 ClusterRole。 +若要允许用户创建/更新角色： + +1. 根据需要赋予他们一个角色，允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。 +2. 授予他们在所创建/更新角色中包含特殊权限的权限: + * 隐式地为他们授权（如果它们试图创建或者更改 Role 或 ClusterRole 的权限， + 但自身没有被授予相应权限，API 请求将被禁止）。 + * 通过允许他们在 Role 或 ClusterRole 资源上执行 `escalate` 动作显式完成授权。 + 这里的 `roles` 和 `clusterroles` 资源包含在 `rbac.authorization.k8s.io` API 组中。 + + +### 对角色绑定创建或更新的限制 + +只有你已经具有了所引用的角色中包含的全部权限时，或者你被授权在所引用的角色上执行 `bind` +动词时，你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。 +例如，如果用户 `user-1` 没有列举集群范围所有 Secret 的能力，则他不可以创建 +ClusterRoleBinding 引用授予该许可权限的角色。 +如要允许用户创建或更新角色绑定： + + +1. 赋予他们一个角色，使得他们能够根据需要创建或更新 RoleBinding 或 ClusterRoleBinding + 对象。 +2. 授予他们绑定某特定角色所需要的许可权限： + * 隐式授权下，可以将角色中包含的许可权限授予他们； + * 显式授权下，可以授权他们在特定 Role （或 ClusterRole）上执行 `bind` 动词的权限。 + +例如，下面的 ClusterRole 和 RoleBinding 将允许用户 `user-1` 把名字空间 `user-1-namespace` +中的 `admin`、`edit` 和 `view` 角色赋予其他用户： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -1465,7 +1339,7 @@ rules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["bind"] - # omit resourceNames to allow binding any ClusterRole + # 忽略 resourceNames 意味着允许绑定任何 ClusterRole resourceNames: ["admin","edit","view"] --- apiVersion: rbac.authorization.k8s.io/v1 @@ -1483,48 +1357,20 @@ subjects: name: user-1 ``` + -例如，这个集群角色和角色绑定将允许 "user-1" 有对"user-1-namespace" 命名空间中的角色执行 `admin`、`edit` 和 `view` 操作权限： +当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 +对初始角色和角色绑定进行初始化时需要： -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: role-grantor -rules: -- apiGroups: ["rbac.authorization.k8s.io"] - resources: ["rolebindings"] - verbs: ["create"] -- apiGroups: ["rbac.authorization.k8s.io"] - resources: ["clusterroles"] - verbs: ["bind"] - # 省略 resourceNames 则允许绑定任何 ClusterRole - resourceNames: ["admin","edit","view"] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: role-grantor-binding - namespace: user-1-namespace -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: role-grantor -subjects: -- apiGroup: rbac.authorization.k8s.io - kind: User - name: user-1 -``` - -当初始化第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要： - -* 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` 这个超级用户角色。 -* 如果你的 API server 启动时启用了不安全端口（使用`--insecure-port`）, 你也可以通过该端口调用 API ，这样操作会绕过身份验证或鉴权。 +* 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` + 这个超级用户角色。 +* 如果你的 API 服务器启动时启用了不安全端口（使用 `--insecure-port`）, 你也可以通过 + 该端口调用 API ，这样的操作会绕过身份验证或鉴权。 ## 一些命令行工具 ### `kubectl create role` -创建 `Role` 对象，定义在某命名空间中的权限。例如: +创建 Role 对象，定义在某一名字空间中的权限。例如: -* 创建名称为 "pod-reader" 的 `Role` 对象，允许用户对 pods 执行 "get"、"watch" 和 "list" 操作： +* 创建名称为 "pod-reader" 的 Role 对象，允许用户对 Pods 执行 `get`、`watch` 和 `list` 操作： - ``` - kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods - ``` - -* 创建名称为 "pod-reader" 的 `Role` 对象并指定 resourceNames： - - ``` - kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod - ``` - -* 创建名为 "foo" 的 `Role` 对象并指定 apiGroups: - - ``` - kubectl create role foo --verb=get,list,watch --resource=replicasets.apps - ``` - -* 创建名为 "foo" 的 `Role` 对象并指定子资源权限: - - ``` - kubectl create role foo --verb=get,list,watch --resource=pods,pods/status - ``` - -* 创建名为 "my-component-lease-holder" 的 `Role` 对象，使其具有对特定名称资源执行 get/update 的权限： - - ``` - kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component - ``` + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` +* 创建名称为 "pod-reader" 的 Role 对象并指定 `resourceNames`： + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + + +* 创建名为 "foo" 的 Role 对象并指定 `apiGroups`： + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + + +* 创建名为 "foo" 的 Role 对象并指定子资源权限: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + + +* 创建名为 "my-component-lease-holder" 的 Role 对象，使其具有对特定名称的 + 资源执行 get/update 的权限： + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + ### `kubectl create clusterrole` -Creates a `ClusterRole` object. Examples: + -### `kubectl create clusterrole` +创建 ClusterRole 对象。例如： -创建 `ClusterRole` 对象。例如： +* 创建名称为 "pod-reader" 的 ClusterRole`对象，允许用户对 Pods 对象执行 `get`、 + `watch` 和 `list` 操作： -* 创建名称为 "pod-reader" 的 `ClusterRole` 对象，允许用户对 pods 对象执行 "get"、"watch" 和 "list" 操作： - - ``` - kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods - ``` - -* 创建名为 "pod-reader" 的 `ClusterRole` 对象并指定资源名称： - - ``` - kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod - ``` - -* 创建名为 "foo" 的 `ClusterRole` 对象并指定 apiGroups： - - ``` - kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps - ``` - -* 创建名为 "foo" 的`ClusterRole` 对象并指定子资源: - - ``` - kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status - ``` - -* 创建名为 "foo" 的 `ClusterRole` 对象并指定非资源路径： - - ``` - kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* - ``` - -* 创建名为 "monitoring" 的 `ClusterRole` 对象并指定聚合规则： - - ``` - kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" - ``` + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` +* 创建名为 "pod-reader" 的 ClusterRole 对象并指定 `resourceNames`： + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定 `apiGroups`： + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定子资源: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定 `nonResourceURL`： + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + + +* 创建名为 "monitoring" 的 ClusterRole 对象并指定 `aggregationRule`： + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + ### `kubectl create rolebinding` -Grants a `Role` or `ClusterRole` within a specific namespace. Examples: + -### `kubectl create rolebinding` +在特定的名字空间中对 `Role` 或 `ClusterRole` 授权。例如： -在特定的命名空间中对 `Role` 或 `ClusterRole` 授权。例如： +* 在名字空间 "acme" 中，将名为 `admin` 的 ClusterRole 中的权限授予名称 "bob" 的用户: -* 在命名空间 "acme" 中，将名为 `admin` 的 `ClusterRole` 中的权限授予名称 "bob" 的用户: - - ``` - kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme - ``` - -* 在命名空间 "acme"中，将名为 `view` 的 `ClusterRole` 中的权限授予该命名空间 "acme" 中名为 "myapp" 的服务账号： - - ``` - kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme - ``` - -* 在命名空间 "acme" 中，将名为 `view` 的 `ClusterRole` 对象中的权限授予命名空间 "myappnamespace" 中名称为 "myapp" 的服务账号： - - ``` - kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme - ``` + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` -### `kubectl create clusterrolebinding` +* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 中的权限授予名字空间 "acme" + 中名为 `myapp` 的服务账号： -在整个集群、包括所有的命名空间中对 `ClusterRole` 授权。例如： - -* 在整个集群范围，将名为 `cluster-admin` 的 `ClusterRole` 中定义的权限授予名为 "root" 用户： - - ``` - kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root - ``` - -* 在整个集群范围，将名为 `system:node-proxier` 的 `ClusterRole` 的权限授予名为 "system:kube-proxy" 的用户： - - ``` - kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy - ``` - -* 在整个集群范围，将名为 `view` 的 `ClusterRole` 对象中定义的权限授予 "acme" 命名空间中名为 "myapp" 的服务账号： - - ``` - kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp - ``` + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` +* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 对象中的权限授予名字空间 + "myappnamespace" 中名称为 `myapp` 的服务账号： + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + + +在整个集群（所有名字空间）中用 ClusterRole 授权。例如： + +* 在整个集群范围，将名为 `cluster-admin` 的 ClusterRole 中定义的权限授予名为 + "root" 用户： + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + + +* 在整个集群范围内，将名为 `system:node-proxier` 的 ClusterRole 的权限授予名为 + "system:kube-proxy" 的用户： + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + + +* 在整个集群范围内，将名为 `view` 的 ClusterRole 中定义的权限授予 "acme" 名字空间中 + 名为 "myapp" 的服务账号： + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + ### `kubectl auth reconcile` {#kubectl-auth-reconcile} + -### `kubectl auth reconcile` {#kubectl-auth-reconcile} - 使用清单文件来创建或者更新 `rbac.authorization.k8s.io/v1` API 对象。 -尚不存在的对象会被创建，如果对应的命名空间也不存在，必要的话也会被创建。 -已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 `--remove-extra-permissions`，可以删除其余权限。 +尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。 +已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 +`--remove-extra-permissions`，可以删除额外的权限。 -已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 `--remove-extra-permissions`，则可以删除其余主体。 +已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 +`--remove-extra-permissions`，则可以删除多余的主体。 例如: + * 测试应用 RBAC 对象的清单文件，显示将要进行的更改： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml --dry-run - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run + ``` -* 应用 RBAC 对象的清单文件， 保留角色中的其余权限和绑定中的其他主体： + +* 应用 RBAC 对象的清单文件，保留角色中的额外权限和绑定中的其他主体： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` -* 应用 RBAC 对象的清单文件, 删除角色中的其他权限和绑定中的其他主体： + +* 应用 RBAC 对象的清单文件, 删除角色中的额外权限和绑定中的其他主体： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + 查看 CLI 帮助获取详细的用法。 +## 服务账号权限 {#service-account-permissions} +默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 +但是不会对 `kube-system` 名字空间之外的服务账号授予权限。 +（除了授予所有已认证用户的发现权限） + +这使得你可以根据需要向特定服务账号授予特定权限。 +细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 +粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， +但更易于管理。 + + -## 服务账号权限 - -默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 -但是不会对 `kube-system` 命名空间之外的服务账号授予权限。 -（除了授予所有已认证用户的 discovery 权限） - -这使得您可以根据需要向特定服务账号授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 -更粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限升级），但更易于管理。 - 按从最安全到最不安全的顺序，存在以下方法： 1. 为特定应用的服务账户授予角色（最佳实践） - 这要求应用在其 pod 规范中指定 `serviceAccountName` ， - 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 + + 这要求应用在其 Pod 规约中指定 `serviceAccountName`， + 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 - ```shell - kubectl create rolebinding my-sa-view \ - --clusterrole=view \ - --serviceaccount=my-namespace:my-sa \ - --namespace=my-namespace - ``` + 例如，在名字空间 "my-namespace" 中授予服务账号 "my-sa" 只读权限： -2. 将角色授予某命名空间中的 ”default” 服务账号 + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` - 如果一个应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。 + +2. 将角色授予某名字空间中的 "default" 服务账号 - {{< note >}}不指定 `serviceAccountName` 的话， - "default" 服务账号的权限会授予给命名空间中所有未指定 `serviceAccountName` 的 Pods。{{< /note >}} + + 如果某应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。 - ```shell - kubectl create rolebinding default-view \ - --clusterrole=view \ - --serviceaccount=my-namespace:default \ - --namespace=my-namespace - ``` + {{< note >}} + "default" 服务账号所具有的权限会被授予给名字空间中所有未指定 + `serviceAccountName` 的 Pod。 + {{< /note >}} - 许多附加组件 [add-ons](/docs/concepts/cluster-administration/addons/) 目前在 `kube-system` 命名空间以 "default" 服务账号运行。 - 要允许这些附加组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 `kube-system` 命名空间中的 "default" 服务账号。 + 例如，在名字空间 "my-namespace" 中授予服务账号 "default" 只读权限： - {{< note >}}启用这一配置意味着在 `kube-system` 命名空间中包含以超级用户账号来访问 API 的 Secrets。{{< /note >}} + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` - ```shell - kubectl create clusterrolebinding add-on-cluster-admin \ - --clusterrole=cluster-admin \ - --serviceaccount=kube-system:default - ``` + + 许多[插件组件](/zh/docs/concepts/cluster-administration/addons/) 在 `kube-system` + 名字空间以 "default" 服务账号运行。 + 要允许这些插件组件以超级用户权限运行，需要将集群的 `cluster-admin` 权限授予 + `kube-system` 名字空间中的 "default" 服务账号。 + + {{< note >}} + 启用这一配置意味着在 `kube-system` 名字空间中包含以超级用户账号来访问 API + 的 Secrets。 + {{< /note >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` +3. 将角色授予名字空间中所有服务账号 -3. 将角色授予命名空间中所有的服务账号 + 如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账号， + 可以将角色授予该名字空间的服务账号组。 - 如果你想要在命名空间中所有的应用都具有某角色，无论它们使用的什么服务账号， - 你可以将角色授予该命名空间的服务账号组。 + 例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账号： - 例如，在命名空间 "my-namespace" 中的只读权限授予该命名空间中的所有服务账号： - - ```shell - kubectl create rolebinding serviceaccounts-view \ - --clusterrole=view \ - --group=system:serviceaccounts:my-namespace \ - --namespace=my-namespace - ``` - -4. 对集群范围内的所有服务账户授予一个受限角色（不鼓励） - - 如果你不想管理每一个命名空间的权限，你可以向所有的服务账号授予集群范围的角色。 - - 例如，为集群范围的所有服务账号授予跨所有命名空间的只读权限： - - ```shell - kubectl create clusterrolebinding serviceaccounts-view \ - --clusterrole=view \ - --group=system:serviceaccounts - ``` - -5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） - - 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。 - - {{< warning >}} - 这将允许所有能够读取 Secrets 和创建 Pods 的用户访问超级用户的私密信息。 - {{< /warning >}} - - ```shell - kubectl create clusterrolebinding serviceaccounts-cluster-admin \ - --clusterrole=cluster-admin \ - --group=system:serviceaccounts - ``` + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` +4. 在集群范围内为所有服务账户授予一个受限角色（不鼓励） + + 如果你不想管理每一个名字空间的权限，你可以向所有的服务账号授予集群范围的角色。 + + 例如，为集群范围的所有服务账号授予跨所有名字空间的只读权限： + + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + + +5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） + + 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。 + + {{< warning >}} + 这样做会允许所有应用都对你的集群拥有完全的访问权限，并将允许所有能够读取 + Secret（或创建 Pod）的用户对你的集群有完全的访问权限。 + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + + -# 从版本1.5升级 +## 从 ABAC 升级 -在Kubernetes 1.6版本之前，许多部署可以使用非常宽松的 ABAC 策略， +原来运行较老版本 Kubernetes 的集群通常会使用限制宽松的 ABAC 策略， 包括授予所有服务帐户全权访问 API 的能力。 -默认的 RBAC 策略被授予控制面组件、节点和控制器。 -`kube-system` 命名空间外的服务账号将没有权限 -（除了授予所有认证用户的发现权限之外） +默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限，但不会为 +`kube-system` 名字空间外的服务账号授权 +（除了授予所有认证用户的发现权限之外）。 这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。 -这里有两种方法来完成这种转变: +这里有两种方法来完成这种转换: -### 平行鉴权 +### 并行鉴权 {#parallel-authorizers} 同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含 -[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： +[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) +的策略文件： -``` +```shell --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -RBAC 鉴权器将首先尝试对请求进行鉴权。如果它拒绝 API 请求， -则 ABAC 鉴权器运行。这意味着被 RBAC 或 ABAC 策略所允许的任何请求 -都是被允许的请求。 + +关于命令行中的第一个选项：如果早期的鉴权组件，例如 Node，拒绝了某个请求，则 +RBAC 鉴权组件尝试对该 API 请求鉴权。如果 RBAC 也拒绝了该 API 请求，则运行 ABAC +鉴权组件。这意味着被 RBAC 或 ABAC 策略所允许的任何请求都是被允许的请求。 -如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` or `--v=5`）， -你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC DENY:`） -您可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 -一旦你将 [角色授予服务账号](#服务账号权限) ，工作负载运行时在服务器日志中 -没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 + +如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` 或 `--v=5`）， +你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC:`） +你可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 + + +一旦你[将角色授予服务账号](#service-account-permissions) ，工作负载运行时 +在服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 +## 宽松的 RBAC 权限 {#permissive-rbac-permissions} + +你可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 {{< warning >}} + - -## 宽松的 RBAC 权限 - -可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 - -{{< warning >}} 下面的策略允许 **所有** 服务帐户充当集群管理员。 -容器中运行的所有应用程序都会自动收到服务帐户的凭据， -可以对 API 执行任何操作，包括查看 Secrets 和修改权限。 -这个策略是不被推荐的。 +容器中运行的所有应用程序都会自动收到服务帐户的凭据，可以对 API 执行任何操作， +包括查看 Secrets 和修改权限。这一策略是不被推荐的。 -``` +```shell kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ @@ -2136,3 +1891,11 @@ kubectl create clusterrolebinding permissive-binding \ --group=system:serviceaccounts ``` {{< /warning >}} + + +在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的 +信息安全需求。 +