kubernetes 1.6 RBAC访问控制

prollerweg

　　一、简介
　　之前，Kubernetes中的授权策略主要是ABAC(Attribute-Based Access Control)。对于ABAC，Kubernetes在实现上是比较难用的，而且需要Master Node的SSH和根文件系统访问权限，授权策略发生变化后还需要重启API Server。
　　Kubernetes 1.6中，RBAC(Role-Based Access Control)基于角色的访问控制进入Beta阶段。RBAC访问控制策略可以使用kubectl或Kubernetes API进行配置。使用RBAC可以直接授权给用户，让用户拥有授权管理的权限，这样就不再需要直接触碰Master Node。在Kubernetes中RBAC被映射成API资源和操作。
　　二、RBAC API的资源对象
　　在Kubernetes 1.6中通过启动参数--authorization-mode=RBAC.API Overview为API Server启用RBAC。
　　使用kubeadm初始化的1.6版本的Kubernetes集群，已经默认为API Server开启了RBAC，可以查看Master Node上API Server的静态Pod定义文件，如果- apiserver底下没有看到
　　如果没有下面红色的信息，说明没有启用RBAC
　　- apiserver
　　- --bind-address=0.0.0.0
　　- --secure-port=443
　　- --insecure-bind-address=0.0.0.0
　　- --insecure-port=8080
　　- --allow-privileged=true
　　- --service-cluster-ip-range=10.3.0.0/24
　　- --advertise-address=172.16.71.200
　　- --cors-allowed-origins=.*
　　- --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota
　　- --tls-cert-file=/etc/kubernetes/ssl/apiserver.pem
　　- --tls-private-key-file=/etc/kubernetes/ssl/apiserver-key.pem
　　- --client-ca-file=/etc/kubernetes/ssl/ca.pem
　　- --service-account-key-file=/etc/kubernetes/ssl/apiserver-key.pem
　　- --v=3
　　- --etcd-servers=http://172.16.71.200:2379,http://172.16.71.201:2379,http://172.16.71.202:2379,http://172.16.71.203:2379
　　- --authorization-mode=RBAC
　　

　　

　　RBAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限：

• Role
  
• ClusterRole
  
• RoleBinding
  
• ClusterRoleBinding
  

1、Role和ClusterRole
　　在RBAC API中，Role包含表示一组权限的规则。 权限是纯粹的加法（没有“否定”规则）。 一个Role可以在一个namespace中用一个角色来定义，也可以使用ClusterRole在群集范围内定义。
　　Role只能用于授予对单个namespace中资源的访问权限。 以下是“default”命名空间中可用于授予对pod的读访问权限的示例：
　　

kind: Role　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
namespace: default　　name: pod
-reader　　
rules:
　　

- apiGroups: [""] # "" indicates the core API group　　resources: [
"pods"]　　verbs: [
"get", "watch", "list"]　　

　　ClusterRole可用于授予与Role相同的权限，但由于它们是集群范围的，因此也可以使用它们来授予对以下内容的访问权限：

• 集群范围的资源（如nodes）
  
• 非资源端点（如“/ healthz”）
  
• 在所有namespace中的资源（如pod）（例如：kubectl get pods --all-namespaces）
  

　　以下ClusterRole可用于授予对任何特定namespace或所有namespace中的secrets 的读取访问（取决于其绑定方式）：
　　

kind: ClusterRole　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
　　#
"namespace" omitted since ClusterRoles are not namespaced　　name: secret
-reader　　
rules:
　　

- apiGroups: [""]　　resources: [
"secrets"]　　verbs: [
"get", "watch", "list"]　　


2、RoleBinding和ClusterRoleBinding
　　RoleBinding把Role绑定到账户主体Subject（users, groups, or service accounts），让Subject继承Role所在namespace下的权限。ClusterRoleBinding把ClusterRole绑定到Subject，让Subject集成ClusterRole在整个集群中的权限。
　　以下RoleBinding将“pod-reader”角色授予“默认”命名空间中的用户“hzb”。 这允许“hzb”在“默认”命名空间中读取pod。
　　

# This role binding allows "jane" to read pods in the "default" namespace.　　
kind: RoleBinding
　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
　　name: read
-podsnamespace: default　　
subjects:
　　

- kind: User　　name: hzb
　　apiGroup: rbac.authorization.k8s.io
　　
roleRef:
　　kind: Role
　　name: pod
-reader　　apiGroup: rbac.authorization.k8s.io
　　

　　RoleBinding还可以引用ClusterRole来授予RoleBinding命名空间中ClusterRole中定义的命名空间资源的权限。 这允许管理员为整个集群定义一组通用角色，然后在多个命名空间中重用它们。也就是说，ClusterRole一旦被RoleBinding到某一个namespace中，它只能访问该namesapce中的资源。
　　例如，即使以下RoleBinding引用了ClusterRole，“hzb”只能在“development”这个namespace（RoleBinding的命名空间）中读取secrets 。
　　

# This role binding allows "dave" to read secrets in the "development" namespace.　　
kind: RoleBinding
　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
　　name: read
-secretsnamespace: development # This only grants permissions within the "development" namespace.　　
subjects:
　　

- kind: User　　name: hzb
　　apiGroup: rbac.authorization.k8s.io
　　
roleRef:
　　kind: ClusterRole
　　name: secret
-reader　　apiGroup: rbac.authorization.k8s.io
　　

　　ClusterRoleBinding可以用于在集群级别和所有namespace中授予权限。 以下ClusterRoleBinding允许组“manager”中的任何用户在任何namespace中读取secrets 。
　　

kind: ClusterRoleBinding　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
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
　　


3、子资源权限
　　大多数资源由其名称的字符串表示形式表示，例如“pod”，就像它出现在相关API端点的URL中一样。 然而，一些Kubernetes API涉及“子资源”，例如pod的日志。 pod的日志端点的URL是：
　　

GET /api/v1/namespaces/{namespace}/pods/{name}/log　　

　　在这种情况下，“pod”是namespace资源，“log”是pod的子资源。 要在RBAC角色中表示此角色，请使用/来划分资源和子资源。 要允许主题读取pod和pod日志，请写：
　　

kind: Role　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
namespace: default　　name: pod
-and-pod-logs-reader　　
rules:
　　

- apiGroups: [""]　　resources: [
"pods", "pods/log"]　　verbs: [
"get", "list"]　　


4、资源名称引用
　　Role权限的资源也可以是某一定义好的资源的名称引用，需要在resourceNames中指定名称。 比如限制一个主题只能“获取”和“更新”一个configmap（这个configmap是用户自己定义的一个资源名称），您可以写：
　　

kind: Role　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
metadata:
namespace: default　　name: configmap
-updater　　
rules:
　　

- apiGroups: [""]　　resources: [
"configmap"]　　resourceNames: [
"my-configmap"]　　verbs: [
"update", "get"]　　

　　值得注意的是，如果设置了resourceName，那么以上的verbs不能是list，watch，create或deletecollection。

5、Role举例
　　以下示例中仅显示了规则部分。
　　允许读取核心API组中的资源“pod”：
　　

rules:　　

- apiGroups: [""]　　resources: [
"pods"]　　verbs: [
"get", "list", "watch"]　　

　　允许在“extensions”和“apps”API组中读/写“deployments”：
　　

rules:　　

- apiGroups: ["extensions", "apps"]　　resources: [
"deployments"]　　verbs: [
"get", "list", "watch", "create", "update", "patch", "delete"]　　

　　允许读“pod”和阅读/写“jobs”：
　　

rules:　　

- apiGroups: [""]　　resources: [
"pods"]　　verbs: [
"get", "list", "watch"]　　

- apiGroups: ["batch", "extensions"]　　resources: [
"jobs"]　　verbs: [
"get", "list", "watch", "create", "update", "patch", "delete"]　　

　　允许读取名为“my-config”的ConfigMap（必须使用RoleBinding绑定才能限制在单个namespace中的单个ConfigMap）：
　　

rules:　　

- apiGroups: [""]　　resources: [
"configmaps"]　　resourceNames: [
"my-config"]　　verbs: [
"get"]　　

　　允许读取核心组中的资源“nodes”（因为nodes是集群范围的，必须是ClusterRole用ClusterRoleBinding绑定才有效）：
　　

rules:　　

- apiGroups: [""]　　resources: [
"nodes"]　　verbs: [
"get", "list", "watch"]　　

　　允许“GET”和“POST”请求到非资源端点“/ healthz”和所有子路径（必须是ClusterRole用ClusterRoleBinding绑定才有效）：
　　

rules:　　

- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match　　verbs: [
"get", "post"]　　


6、给Subjects授权
　　RoleBinding或ClusterRoleBinding将角色绑定到subjects。 subjects可以是 groups, users or service accounts。
　　Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如 “alice”；也可以是 email 格式的邮箱地址，如 “bob@example.com”；甚至是一组字符串形式的数字>system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式
　　Kubernetes中的groups目前由Authenticator模块提供。 groups表示为字符串，该字符串没有格式要求，除了前缀system:被保留。
　　service accounts具有前缀为system:serviceaccount:用户名，属于前缀为system:serviceaccount:的组

RoleBinding举例：
　　以下示例中仅显示了RoleBinding的subjects部分。对于名为“hzb@test.com”的用户：
　　

subjects:　　

- kind: User　　name:
"alice@example.com"　　apiGroup: rbac.authorization.k8s.io
　　

　　给一个名为frontend-admins的组
　　

subjects:　　

- kind: Group　　name:
"frontend-admins"　　apiGroup: rbac.authorization.k8s.io
　　

　　对于kube-system命名空间中的默认服务帐户：
　　

subjects:　　

- kind: ServiceAccount　　name:
default　　namespace: kube-system
　　

　　对于“qa”命名空间中的所有服务帐户：
　　

subjects:　　

- kind: Group　　name: system:serviceaccounts:qa
　　apiGroup: rbac.authorization.k8s.io
　　

　　对于任何的 service accounts：
　　

subjects:　　

- kind: Group　　name: system:serviceaccounts
　　apiGroup: rbac.authorization.k8s.io
　　

　　对于所有 authenticated users (version 1.5+):
　　

subjects:　　

- kind: Group　　name: system:authenticated
　　apiGroup: rbac.authorization.k8s.io
　　

　　对于所有 unauthenticated users (version 1.5+):
　　

subjects:　　

- kind: Group　　name: system:unauthenticated
　　apiGroup: rbac.authorization.k8s.io
　　

　　对于所有users (version 1.5+):
　　

subjects:　　

- kind: Group　　name: system:authenticated
　　apiGroup: rbac.authorization.k8s.io
　　

- kind: Group　　name: system:unauthenticated
　　apiGroup: rbac.authorization.k8s.io
　　

　　三、默认的Roles and Role Bindings
　　API  servers 创建一组默认的ClusterRole和ClusterRoleBinding对象。 其中许多是system:前缀，表示资源由基础架构“拥有”。 对这些资源的修改可能导致集群异常。 一个例子是system:node。 此角色定义了kubelet的权限。 如果角色被修改，它可能使kubelets无法工作。
　　所有的 cluster roles and rolebindings 被label标记为：
　　

kubernetes.io/bootstrapping=rbac-defaults　　

　　API Server 在每次启动后都会更新已经丢失的默认 ClusterRole 和 其绑定的相关 Subjects；这将允许集群自动修复因为意外更改导致的 RBAC 授权错误，同时能够使在升级集群后基础设施的 RBAC 授权得以自动更新。
　　如果想要关闭 API Server 的自动修复功能，只需要将默认创建的 ClusterRole 和其 RoleBind 的 rbac.authorization.kubernetes.io/autoupdate 注解设置为 false 即可，这样做会有很大风险导致集群因为意外修改 RBAC 而无法工作
　　Auto-reconciliation 在 1.6+ 版本被默认启用(当 RBAC 授权被激活时)

Discovery Roles

默认ClusterRole
默认ClusterRoleBinding
描述
system:basic-user
system:authenticated and system:unauthenticatedgroups
允许用户只读访问有关自己的基本信息。
system:discovery
system:authenticated and system:unauthenticatedgroups
允许只读访问API发现端点，以发现和协商API级别。
User-facing Roles
　　一些默认角色不是system:前缀。 这些是面向用户的角色。 它们包括超级用户角色（cluster-admin），旨在使用ClusterRoleBindings（cluster-status）授予集群范围的角色，以及旨在使用RoleBindings（admin，edit，view）在特定命名空间中授予的角色。

默认ClusterRole
默认ClusterRoleBinding
描述
cluster-admin
system:masters group　　允许超级用户访问对任何资源执行任何操作。如果使用的是ClusterRoleBinding，它可以完全控制集群和所有命名空间中的每个资源，
　　当在RoleBinding中使用时，它可以完全控制rolebinding的命名空间中的每个资源，包括命名空间本身。

admin
none　　允许管理员访问，旨在使用RoleBinding授予对命名空间的访问。 如果在RoleBinding中使用，则允许对命名空间中大多数资源进行读/写访问，
　　包括在命名空间中创建角色和角色绑定的功能。 它不允许对资源配额或命名空间本身的写访问。

edit
none
允许对命名空间中大多数对象的读/写访问。 它不允许查看或修改Role或RoleBinding。
view
none
允许只读访问查看命名空间中的大多数对象。 它不允许查看或修改Role或RoleBinding。 它不允许查看secrets。
Core Component Roles

默认ClusterRole
默认ClusterRoleBinding
描述
system:kube-scheduler
system:kube-scheduler user
允许访问kube-scheduler组件所需的资源。
system:kube-controller-manager
system:kube-controller-manager user
允许访问kube-controller-manager组件所需的资源。 控制器角色中包含单个控制循环所需的权限。
system:node
system:nodes group (deprecated in 1.7)
允许访问kubelet组件所需的资源，包括对所有secrets的读取访问权限，以及对所有pod的访问权限。 从1.7开始，建议使用[Node Authorizer]（/ docs / admin / authorization / node /）和[NodeRestriction admission plugin]（/docs/admin/admission-controllers＃NodeRestriction）而不是此角色，并允许基于计划在其上运行的pod的API访问kubelets。 从1.7开始，当启用“Node”授权模式时，不会自动绑定到“system：nodes”组
system:node-proxier
system:kube-proxy user
允许访问kube-proxy组件所需的资源
Other Component Roles

默认ClusterRole
默认ClusterRoleBinding
描述
system:auth-delegator
none
允许委托认证和授权检查。 这通常由附加API服务器用于统一认证和授权。
system:heapster
none
Heapster组件的角色
system:kube-aggregator
none
kube-aggregator组件的角色。
system:kube-dns
kube-dns service account in the kube-system namespace
kube-dns组件的角色
system:node-bootstrapper
none
允许访问执行Kubelet TLS自举所需的资源。
system:node-problem-detector
none
node-problem-detector组件的角色system:persistent-volume-provisioner
none
允许访问大多数动态卷配置所需的资源Controller Roles
　　Kubernetes控制器管理器运行核心控制环路。 当使用--use-service-account-credentials调用时，每个控制循环都将使用单独的服务帐户启动。 对于每个控制循环，存在相应的角色，前缀为system:controller:。 如果控制器管理器未启动--use-service-account-credentials，它将使用其自己的凭证运行所有控制循环，这些凭证必须被授予所有相关的角色。 这些角色包括：

• system:controller:attachdetach-controller
  
• system:controller:certificate-controller
  
• system:controller:cronjob-controller
  
• system:controller:daemon-set-controller
  
• system:controller:deployment-controller
  
• system:controller:disruption-controller
  
• system:controller:endpoint-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:replicaset-controller
  
• system:controller:replication-controller
  
• system:controller:resourcequota-controller
  
• 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授权器没有被使用也是如此。
　　用户即使在对某个 Role 拥有全部权限的情况下也仅能在其作用范围内(ClusterRole -> 集群范围内，Role -> 当前 namespace 或 集群范围)对其进行 create 和 update 操作；
　　例如 “user-1” 用户不具有在集群范围内列出 secrets 的权限，那么他也无法在集群范围内创建具有该权限的 ClusterRole，也就是说想传递权限必须先获得该权限；
　　想要允许用户 cretae/update Role 有两种方式:

• 授予一个该用户期望 create/update 的 Role 或者 ClusterRole
  
• 授予一个包含该用户期望 create/update 的 Role 或者 ClusterRole 的 Role 或者 ClusterRole(有点绕…)；如果用户尝试 crate/update 一个其不拥有的 Role 或者 ClusterRole，则 API 会禁止。 如果他们尝试创建或修改一个Role或ClusterRole的权限，他们自己还没有被授权，API请求将被禁止。
  

　　如果用户想要创建/更新role binding,那么用户必须已经具有包含在引用角色中的所有权限（与角色绑定相同的范围），或者如果已被赋予权限来执行role binding的verb，如果“user-1”无法在群集范围内列出secrets，则不能向授予该权限的角色创建ClusterRoleBinding。
　　允许用户创建/更新角色绑定：

• 授予他们一个角色，允许他们根据需要创建/更新RoleBinding或ClusterRoleBinding对象。
  
• 授予他们绑定特定角色所需的权限:
  

• 隐含地，通过给他们角色中包含的权限。
  
• 明确地说，通过授予他们在特定角色（或群集角色）上执行绑定动词的权限。
  

　　例如，此集群角色和角色绑定将允许“user-1”授予其他用户在“user-1-namespace”命名空间中的管理，编辑和查看角色：
　　

apiVersion: rbac.authorization.k8s.io/v1beta1　　
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: [
"admin","edit","view"]　　

---　　
apiVersion: rbac.authorization.k8s.io
/v1beta1　　
kind: RoleBinding
　　
metadata:
　　name: role
-grantor-bindingnamespace: 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　　

　　当使用 bootstrapping 时，初始用户尚没有访问 API 的权限，此时想要授予他们一些尚未拥有的权限是不可能的，此时可以有两种解决方案:

• 使用具有system：masters group的credential ，该credential是通过默认绑定绑定到cluster-admin超级用户角色。
  
• 如果您的API服务器在启用了不安全端口（--insecure-port）的情况下运行，那么还可以通过该端口进行API调用，不会强制执行身份验证或授权
  

　　五、RBAC命令行工具
　　存在两个kubectl命令来在命名空间或整个集群中授予角色

kubectl create rolebinding
　　

kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme　　

　　

kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme　　


kubectl create clusterrolebinding
　　

kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root　　

　　

kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet　　

　　

kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp　　


六、Service Account Permissions
　　Service Account概念的引入是基于这样的使用场景：运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
　　默认RBAC策略向 control-plane components, nodes, and controllers授予范围限制的权限，但不向“kube-system”命名空间之外的service accounts授予权限（超出发给所有已验证用户的发现权限）。这允许您根据需要向特定服务帐户授予特定角色。 细粒度角色绑定提供更大的安全性，但需要更多的努力来管理。 更广泛的授权可以给service accounts提供不必要的（可能升级的）API访问，但是更容易管理。
　　从最安全到最不安全的的方式如下：

• 为应用程序特定的服务帐户（最佳实践）授予角色：这要求应用程序在其pod的spec中指定serviceAccountName，并且要创建 service account 。例如，将“my-namespace”中的只读权限授予“my-sa”服务帐户：
  

　　

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace　　

• 在命名空间中为“默认” service account 授予角色：如果应用程序没有指定serviceAccountName，它将使用“默认”service account。注意：授予“默认”服务帐户的权限可用于命名空间中未指定serviceAccountName的任何pod。
  

　　例如，将“my-namespace”中的只读权限授予“默认”service account：
　　

kubectl create rolebinding default-view --clusterrole=view  --serviceaccount=my-namespace:default  --namespace=my-namespace　　

　　许多加载项当前作为“kube-system”命名空间中的“默认”service account运行。 要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予“kube-system”命名空间中的“默认”服务帐户。注意：启用这意味着“kube-system”命名空间包含授予超级用户访问API的权限。
　　

kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default　　

• 为命名空间中的所有service accounts授予角色：如果希望命名空间中的所有应用程序都具有该角色，无论使用什么service accounts，可以将该角色授予该命名空间的service account group 。例如，将“my-namespace”中的只读权限授予该命名空间中的所有service accounts：
  

　　

kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace--namespace=my-namespace　　

• 对集群范围内的所有service accounts（不鼓励）授予有限的权限：如果您不想管理每个命名空间的权限，则可以将群集范围角色授予所有service accounts。例如，将所有命名空间中的只读权限授予群集中的所有service accounts：
  

　　

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts　　

• 授予超级用户访问群集范围内的所有service accounts（强烈不鼓励）：如果您根本不关心分区权限，则可以向所有service accounts授予超级用户访问权限。警告：这允许任何具有读取访问权限的用户访问secrets或能够创建一个pod以访问超级用户credentials。
  

　　

kubectl create clusterrolebinding serviceaccounts-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts