From 6575ef86f66d22e465d8f7c38e8059b57979f3a5 Mon Sep 17 00:00:00 2001 From: neo Date: Mon, 25 Sep 2017 11:33:13 +0800 Subject: [PATCH] =?UTF-8?q?=E5=B0=86'=E5=90=8D=E5=AD=97=E7=A9=BA=E9=97=B4'?= =?UTF-8?q?=E4=BF=AE=E6=94=B9=E4=B8=BA=E6=9B=B4=E9=80=9A=E7=94=A8=E7=9A=84?= =?UTF-8?q?'=E5=91=BD=E5=90=8D=E7=A9=BA=E9=97=B4'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- concepts/concepts.md | 4 +-- guide/rbac.md | 82 ++++++++++++++++++++++---------------------- 2 files changed, 43 insertions(+), 43 deletions(-) diff --git a/concepts/concepts.md b/concepts/concepts.md index 9303a292a..035e052c0 100644 --- a/concepts/concepts.md +++ b/concepts/concepts.md @@ -114,9 +114,9 @@ Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息 顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和Kubernetes集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。 -### 名字空间（Namespace） +### 命名空间（Namespace） -名字空间为Kubernetes集群提供虚拟的隔离作用，Kubernetes集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。 +命名空间为Kubernetes集群提供虚拟的隔离作用，Kubernetes集群初始有两个命名空间，分别是默认命名空间default和系统命名空间kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。 ### RBAC访问授权 diff --git a/guide/rbac.md b/guide/rbac.md index 8050c787a..9d6ae8170 100644 --- a/guide/rbac.md +++ b/guide/rbac.md @@ -14,9 +14,9 @@ ### Role与ClusterRole -在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由名字空间（namespace）内的`Role`对象定义，而整个Kubernetes集群范围内有效的角色则通过`ClusterRole`对象实现。 +在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由命名空间（namespace）内的`Role`对象定义，而整个Kubernetes集群范围内有效的角色则通过`ClusterRole`对象实现。 -一个`Role`对象只能用于授予对某一单一名字空间中资源的访问权限。 以下示例描述了”default”名字空间中的一个`Role`对象的定义，用于授予对pod的读访问权限： +一个`Role`对象只能用于授予对某一单一命名空间中资源的访问权限。 以下示例描述了”default”命名空间中的一个`Role`对象的定义，用于授予对pod的读访问权限： ```yaml kind: Role @@ -34,9 +34,9 @@ rules: - 集群范围资源（例如节点，即node） - 非资源类型endpoint（例如”/healthz”） -- 跨所有名字空间的名字空间范围资源（例如pod，需要运行命令`kubectl get pods --all-namespaces`来查询集群中所有的pod） +- 跨所有命名空间的命名空间范围资源（例如pod，需要运行命令`kubectl get pods --all-namespaces`来查询集群中所有的pod） -下面示例中的`ClusterRole`定义可用于授予用户对某一特定名字空间，或者所有名字空间中的secret（取决于其[绑定](https://k8smeetup.github.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding)方式）的读访问权限： +下面示例中的`ClusterRole`定义可用于授予用户对某一特定命名空间，或者所有命名空间中的secret（取决于其[绑定](https://k8smeetup.github.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding)方式）的读访问权限： ```Yaml kind: ClusterRole @@ -52,12 +52,12 @@ rules: ### RoleBinding与ClusterRoleBinding -角色绑定将一个角色中定义的各种权限授予一个或者一组用户。 角色绑定包含了一组相关主体（即subject, 包括用户——User、用户组——Group、或者服务账户——Service Account）以及对被授予角色的引用。 在名字空间中可以通过`RoleBinding`对象授予权限，而集群范围的权限授予则通过`ClusterRoleBinding`对象完成。 +角色绑定将一个角色中定义的各种权限授予一个或者一组用户。 角色绑定包含了一组相关主体（即subject, 包括用户——User、用户组——Group、或者服务账户——Service Account）以及对被授予角色的引用。 在命名空间中可以通过`RoleBinding`对象授予权限，而集群范围的权限授予则通过`ClusterRoleBinding`对象完成。 -`RoleBinding`可以引用在同一名字空间内定义的`Role`对象。 下面示例中定义的`RoleBinding`对象在”default”名字空间中将”pod-reader”角色授予用户”jane”。 这一授权将允许用户”jane”从”default”名字空间中读取pod。 +`RoleBinding`可以引用在同一命名空间内定义的`Role`对象。 下面示例中定义的`RoleBinding`对象在”default”命名空间中将”pod-reader”角色授予用户”jane”。 这一授权将允许用户”jane”从”default”命名空间中读取pod。 ```Yaml -# 以下角色绑定定义将允许用户"jane"从"default"名字空间中读取pod。 +# 以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: @@ -73,17 +73,17 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -`RoleBinding`对象也可以引用一个`ClusterRole`对象用于在`RoleBinding`所在的名字空间内授予用户对所引用的`ClusterRole`中 定义的名字空间资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的名字空间中复用这些角色。 +`RoleBinding`对象也可以引用一个`ClusterRole`对象用于在`RoleBinding`所在的命名空间内授予用户对所引用的`ClusterRole`中 定义的命名空间资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色。 -例如，尽管下面示例中的`RoleBinding`引用的是一个`ClusterRole`对象，但是用户”dave”（即角色绑定主体）还是只能读取”development” 名字空间中的secret（即`RoleBinding`所在的名字空间）。 +例如，尽管下面示例中的`RoleBinding`引用的是一个`ClusterRole`对象，但是用户”dave”（即角色绑定主体）还是只能读取”development” 命名空间中的secret（即`RoleBinding`所在的命名空间）。 ```yaml -# 以下角色绑定允许用户"dave"读取"development"名字空间中的secret。 +# 以下角色绑定允许用户"dave"读取"development"命名空间中的secret。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets - namespace: development # 这里表明仅授权读取"development"名字空间中的资源。 + namespace: development # 这里表明仅授权读取"development"命名空间中的资源。 subjects: - kind: User name: dave @@ -94,10 +94,10 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -最后，可以使用`ClusterRoleBinding`在集群级别和所有名字空间中授予权限。下面示例中所定义的`ClusterRoleBinding` 允许在用户组”manager”中的任何用户都可以读取集群中任何名字空间中的secret。 +最后，可以使用`ClusterRoleBinding`在集群级别和所有命名空间中授予权限。下面示例中所定义的`ClusterRoleBinding` 允许在用户组”manager”中的任何用户都可以读取集群中任何命名空间中的secret。 ```yaml -# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何名字空间中的secret。 +# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。 kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: @@ -121,7 +121,7 @@ GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -在这种情况下，”pods”是名字空间资源，而”log”是pods的子资源。为了在RBAC角色中表示出这一点，我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取pods以及pod log，您需要定义以下角色： +在这种情况下，”pods”是命名空间资源，而”log”是pods的子资源。为了在RBAC角色中表示出这一点，我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取pods以及pod log，您需要定义以下角色： ```yaml kind: Role @@ -186,7 +186,7 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -允许读取一个名为”my-config”的`ConfigMap`实例（需要将其通过`RoleBinding`绑定从而限制针对某一个名字空间中定义的一个`ConfigMap`实例的访问）： +允许读取一个名为”my-config”的`ConfigMap`实例（需要将其通过`RoleBinding`绑定从而限制针对某一个命名空间中定义的一个`ConfigMap`实例的访问）： ```yaml rules: @@ -245,7 +245,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -kube-system名字空间中的默认服务账户： +kube-system命名空间中的默认服务账户： ```yaml subjects: @@ -254,7 +254,7 @@ subjects: namespace: kube-system ``` -名为”qa”名字空间中的所有服务账户： +名为”qa”命名空间中的所有服务账户： ```yaml subjects: @@ -325,14 +325,14 @@ API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。 ### 面向用户的角色 -一些默认角色并不包含`system:`前缀，它们是面向用户的角色。 这些角色包含超级用户角色（`cluster-admin`），即旨在利用ClusterRoleBinding（`cluster-status`）在集群范围内授权的角色， 以及那些使用RoleBinding（`admin`、`edit`和`view`）在特定名字空间中授权的角色。 +一些默认角色并不包含`system:`前缀，它们是面向用户的角色。 这些角色包含超级用户角色（`cluster-admin`），即旨在利用ClusterRoleBinding（`cluster-status`）在集群范围内授权的角色， 以及那些使用RoleBinding（`admin`、`edit`和`view`）在特定命名空间中授权的角色。 | 默认ClusterRole | 默认ClusterRoleBinding | 描述 | | ----------------- | ------------------------ | ---------------------------------------- | -| **cluster-admin** | **system:masters** group | 超级用户权限，允许对任何资源执行任何操作。 在**ClusterRoleBinding**中使用时，可以完全控制集群和所有名字空间中的所有资源。 在**RoleBinding**中使用时，可以完全控制RoleBinding所在名字空间中的所有资源，包括名字空间自己。 | -| **admin** | None | 管理员权限，利用**RoleBinding**在某一名字空间内部授予。 在**RoleBinding**中使用时，允许针对名字空间内大部分资源的读写访问， 包括在名字空间内创建角色与角色绑定的能力。 但不允许对资源配额（resource quota）或者名字空间本身的写访问。 | -| **edit** | None | 允许对某一个名字空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。 | -| **view** | None | 允许对某一个名字空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因，不允许查看secret资源。 | +| **cluster-admin** | **system:masters** group | 超级用户权限，允许对任何资源执行任何操作。 在**ClusterRoleBinding**中使用时，可以完全控制集群和所有命名空间中的所有资源。 在**RoleBinding**中使用时，可以完全控制RoleBinding所在命名空间中的所有资源，包括命名空间自己。 | +| **admin** | None | 管理员权限，利用**RoleBinding**在某一命名空间内部授予。 在**RoleBinding**中使用时，允许针对命名空间内大部分资源的读写访问， 包括在命名空间内创建角色与角色绑定的能力。 但不允许对资源配额（resource quota）或者命名空间本身的写访问。 | +| **edit** | None | 允许对某一个命名空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。 | +| **view** | None | 允许对某一个命名空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因，不允许查看secret资源。 | ### Core Component Roles @@ -388,7 +388,7 @@ API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。 RBAC API会阻止用户通过编辑角色或者角色绑定来升级权限。 由于这一点是在API级别实现的，所以在RBAC授权器（RBAC authorizer）未启用的状态下依然可以正常工作。 -用户只有在拥有了角色所包含的所有权限的条件下才能创建／更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于`ClusterRole`来说是集群范围，对于`Role`来说是在与角色相同的名字空间或者集群范围）。 例如，如果用户”user-1”没有权限读取集群范围内的secret列表，那么他也不能创建包含这种权限的`ClusterRole`。为了能够让用户创建／更新角色，需要： +用户只有在拥有了角色所包含的所有权限的条件下才能创建／更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于`ClusterRole`来说是集群范围，对于`Role`来说是在与角色相同的命名空间或者集群范围）。 例如，如果用户”user-1”没有权限读取集群范围内的secret列表，那么他也不能创建包含这种权限的`ClusterRole`。为了能够让用户创建／更新角色，需要： 1. 授予用户一个角色以允许他们根据需要创建／更新`Role`或者`ClusterRole`对象。 2. 授予用户一个角色包含他们在`Role`或者`ClusterRole`中所能够设置的所有权限。如果用户尝试创建或者修改`Role`或者`ClusterRole`以设置那些他们未被授权的权限时，这些API请求将被禁止。 @@ -400,7 +400,7 @@ RBAC API会阻止用户通过编辑角色或者角色绑定来升级权限。 - 隐式地，通过授予用户所有所引用的角色中所包含的权限 - 显式地，通过授予用户在特定Role（或者ClusterRole）对象上执行`bind`操作的权限 -例如，下面例子中的ClusterRole和RoleBinding将允许用户”user-1”授予其它用户”user-1-namespace”名字空间内的`admin`、`edit`和`view`等角色和角色绑定。 +例如，下面例子中的ClusterRole和RoleBinding将允许用户”user-1”授予其它用户”user-1-namespace”命名空间内的`admin`、`edit`和`view`等角色和角色绑定。 ```yaml apiVersion: rbac.authorization.k8s.io/v1beta1 @@ -438,23 +438,23 @@ subjects: ## 一些命令行工具 -有两个`kubectl`命令可以用于在名字空间内或者整个集群内授予角色。 +有两个`kubectl`命令可以用于在命名空间内或者整个集群内授予角色。 ### `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`授予服务账户”myapp”： +- 在名为”acme”的命名空间中将`view` `ClusterRole`授予服务账户”myapp”： `kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme` ### `kubectl create clusterrolebinding` -在整个集群中授予`ClusterRole`，包括所有名字空间。示例如下： +在整个集群中授予`ClusterRole`，包括所有命名空间。示例如下： - 在整个集群范围内将`cluster-admin` `ClusterRole`授予用户”root”： @@ -464,7 +464,7 @@ subjects: `kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet` -- 在整个集群范围内将`view` `ClusterRole`授予名字空间”acme”内的服务账户”myapp”： +- 在整个集群范围内将`view` `ClusterRole`授予命名空间”acme”内的服务账户”myapp”： `kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp` @@ -472,7 +472,7 @@ subjects: ## 服务账户（Service Account）权限 -默认的RBAC策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限， 但对于”kube-system”名字空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 +默认的RBAC策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限， 但对于”kube-system”命名空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 这一点允许您根据需要向特定服务账号授予特定权限。 细粒度的角色绑定将提供更好的安全性，但需要更多精力管理。 更粗粒度的授权可能授予服务账号不需要的API访问权限（甚至导致潜在授权扩散），但更易于管理。 @@ -482,7 +482,7 @@ subjects: 要求应用程序在其pod规范（pod spec）中指定`serviceAccountName`字段，并且要创建相应服务账户（例如通过API、应用程序清单或者命令`kubectl create serviceaccount`等）。 - 例如，在”my-namespace”名字空间中授予服务账户”my-sa”只读权限： + 例如，在”my-namespace”命名空间中授予服务账户”my-sa”只读权限： ```bash kubectl create rolebinding my-sa-view \ @@ -491,13 +491,13 @@ subjects: --namespace=my-namespace ``` -2. 在某一名字空间中授予”default”服务账号一个角色 +2. 在某一命名空间中授予”default”服务账号一个角色 如果一个应用程序没有在其pod规范中指定`serviceAccountName`，它将默认使用”default”服务账号。 - 注意：授予”default”服务账号的权限将可用于名字空间内任何没有指定`serviceAccountName`的pod。 + 注意：授予”default”服务账号的权限将可用于命名空间内任何没有指定`serviceAccountName`的pod。 - 下面的例子将在”my-namespace”名字空间内授予”default”服务账号只读权限： + 下面的例子将在”my-namespace”命名空间内授予”default”服务账号只读权限： ```bash kubectl create rolebinding default-view \ @@ -506,7 +506,7 @@ subjects: --namespace=my-namespace ``` - 目前，许多[加载项（addon）]（/ docs / concepts / cluster-administration / addons /）作为”kube-system”名字空间中的”default”服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予”kube-system”名字空间中的”default”服务帐户。 注意：启用上述操作意味着”kube-system”名字空间将包含允许超级用户访问API的秘钥。 + 目前，许多[加载项（addon）]（/ docs / concepts / cluster-administration / addons /）作为”kube-system”命名空间中的”default”服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予”kube-system”命名空间中的”default”服务帐户。 注意：启用上述操作意味着”kube-system”命名空间将包含允许超级用户访问API的秘钥。 ```bash kubectl create clusterrolebinding add-on-cluster-admin \ @@ -514,11 +514,11 @@ subjects: --serviceaccount=kube-system:default ``` -3. 为名字空间中所有的服务账号授予角色 +3. 为命名空间中所有的服务账号授予角色 - 如果您希望名字空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，您可以为该名字空间的服务账户用户组授予角色。 + 如果您希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，您可以为该命名空间的服务账户用户组授予角色。 - 下面的例子将授予”my-namespace”名字空间中的所有服务账户只读权限： + 下面的例子将授予”my-namespace”命名空间中的所有服务账户只读权限： ```bash kubectl create rolebinding serviceaccounts-view \ @@ -531,7 +531,7 @@ subjects: 如果您不想管理每个命名空间的权限，则可以将集群范围角色授予所有服务帐户。 - 下面的例子将所有名字空间中的只读权限授予集群中的所有服务账户： + 下面的例子将所有命名空间中的只读权限授予集群中的所有服务账户： ```bash kubectl create clusterrolebinding serviceaccounts-view \ @@ -555,7 +555,7 @@ subjects: 在Kubernetes 1.6之前，许多部署使用非常宽泛的ABAC策略，包括授予对所有服务帐户的完整API访问权限。 -默认的RBAC策略将授予控制平面组件（control-plane components）、节点（nodes）和控制器（controller）一组范围受限的权限， 但对于”kube-system”名字空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 +默认的RBAC策略将授予控制平面组件（control-plane components）、节点（nodes）和控制器（controller）一组范围受限的权限， 但对于”kube-system”命名空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 虽然安全性更高，但这可能会影响到期望自动接收API权限的现有工作负载。 以下是管理此转换的两种方法：