Kubernetes RBAC 内置集群角色ClusterRole

Kubemetes提供了 一组默认的ClusterRole和ClusterRoleBinding， 每次API服务器启动时都会更新它们。这保证了在你错误地删除角色和绑定，或者Kubernetes的新版本使用了不同的集群角色和绑定配置时， 所有的默认角色和绑定都会被重新创建。

view、 edit、 admin和cluster-adrnin ClusterRole是最重要的角色， 它们应该绑定到用户定义pod中的ServiceAccount上。

默认的ClusterRole列表包含了大量其他的ClusterRole，它们以syst em: 为前缀。 这些角色用于各种Kubemetes组件中 。 在它们之中 ， 可以找到如system:kube-scheduler之类的角色， 它明显是 给调度器使用的， system:node是给Kubelets组件使用的，等等。

虽然Controller Manager作为一个独立的

pod来运行 ， 但是在其中运行的每个控制器都可以使用单独的ClusterRole和ClusterRoleBinding (它们以system:Controller: 为前缀）。

这些系统的每个ClusterRole都有 一 个匹配的ClusterRoleBinding，它会绑定到系统组件用来身份认证的用户上。 例如， system:kube-scheduler ClusterRoleBinding将名称相同的ClusterRole分配给 system:kube-scheduler用户， 它是调度器作为身份认证的用户名。

 

 

k8s 内置的集群角色 system

---

k8s为了让用户使用某些特定的权限，给大家预留了四个集群角色，这个是可以是直接使用的。

以system开头的都是k8s内置的 ，不要随便删除，删除了可能导致集群功能不正常。

[root@k8s-master ~]# kubectl get clusterrole
NAME                                                                   CREATED AT
system:aggregate-to-admin                                              2020-11-15T06:56:58Z
system:aggregate-to-edit                                               2020-11-15T06:56:58Z
system:aggregate-to-view                                               2020-11-15T06:56:58Z
system:aggregated-metrics-reader                                       2020-11-17T17:05:55Z
system:auth-delegator                                                  2020-11-15T06:56:58Z
system:basic-user                                                      2020-11-15T06:56:58Z
system:certificates.k8s.io:certificatesigningrequests:nodeclient       2020-11-15T06:56:58Z
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   2020-11-15T06:56:58Z
system:certificates.k8s.io:kube-apiserver-client-approver              2020-11-15T06:56:59Z
system:certificates.k8s.io:kube-apiserver-client-kubelet-approver      2020-11-15T06:56:59Z
system:certificates.k8s.io:kubelet-serving-approver                    2020-11-15T06:56:58Z
system:certificates.k8s.io:legacy-unknown-approver                     2020-11-15T06:56:58Z
system:controller:attachdetach-controller                              2020-11-15T06:56:59Z
system:controller:certificate-controller                               2020-11-15T06:56:59Z
system:controller:clusterrole-aggregation-controller                   2020-11-15T06:56:59Z
system:controller:cronjob-controller                                   2020-11-15T06:56:59Z
system:controller:daemon-set-controller                                2020-11-15T06:56:59Z
system:controller:deployment-controller                                2020-11-15T06:56:59Z
system:controller:disruption-controller                                2020-11-15T06:56:59Z
system:controller:endpoint-controller                                  2020-11-15T06:56:59Z
system:controller:endpointslice-controller                             2020-11-15T06:56:59Z
system:controller:endpointslicemirroring-controller                    2020-11-15T06:56:59Z
system:controller:expand-controller                                    2020-11-15T06:56:59Z
system:controller:generic-garbage-collector                            2020-11-15T06:56:59Z
system:controller:horizontal-pod-autoscaler                            2020-11-15T06:56:59Z
system:controller:job-controller                                       2020-11-15T06:56:59Z
system:controller:namespace-controller                                 2020-11-15T06:56:59Z
system:controller:node-controller                                      2020-11-15T06:56:59Z
system:controller:persistent-volume-binder                             2020-11-15T06:56:59Z
system:controller:pod-garbage-collector                                2020-11-15T06:56:59Z
system:controller:pv-protection-controller                             2020-11-15T06:56:59Z
system:controller:pvc-protection-controller                            2020-11-15T06:56:59Z
system:controller:replicaset-controller                                2020-11-15T06:56:59Z
system:controller:replication-controller                               2020-11-15T06:56:59Z
system:controller:resourcequota-controller                             2020-11-15T06:56:59Z
system:controller:route-controller                                     2020-11-15T06:56:59Z
system:controller:service-account-controller                           2020-11-15T06:56:59Z
system:controller:service-controller                                   2020-11-15T06:56:59Z
system:controller:statefulset-controller                               2020-11-15T06:56:59Z
system:controller:ttl-controller                                       2020-11-15T06:56:59Z
system:coredns                                                         2020-11-15T06:57:02Z
system:discovery                                                       2020-11-15T06:56:58Z
system:heapster                                                        2020-11-15T06:56:58Z
system:kube-aggregator                                                 2020-11-15T06:56:58Z
system:kube-controller-manager                                         2020-11-15T06:56:58Z
system:kube-dns                                                        2020-11-15T06:56:58Z
system:kube-scheduler                                                  2020-11-15T06:56:59Z
system:kubelet-api-admin                                               2020-11-15T06:56:58Z
system:metrics-server                                                  2020-11-17T17:05:55Z
system:node                                                            2020-11-15T06:56:58Z
system:node-bootstrapper                                               2020-11-15T06:56:58Z
system:node-problem-detector                                           2020-11-15T06:56:58Z
system:node-proxier                                                    2020-11-15T06:56:59Z
system:persistent-volume-provisioner                                   2020-11-15T06:56:58Z
system:public-info-viewer                                              2020-11-15T06:56:58Z
system:volume-scheduler                                                2020-11-15T06:56:58Z

k8s预定好了四个集群角色供用户使用，使用kubectl get clusterrole查看，其中systemd:开头的为系统内部使用。（以system开头的是绝对不能删除的，删除了可能导致集群异常）

 

k8s 组件的集群角色 

---

除了system开头的，还有搭建组件自己创建的集群角色，也是用来访问api的，比如calico

[root@k8s-master ~]# kubectl get clusterrole
NAME                                                                   CREATED AT
calico-kube-controllers                                                2020-11-15T08:13:24Z
calico-node                                                            2020-11-15T08:13:24Z
cluster-admin                                                          2020-11-15T06:56:58Z

 

k8s 内置集群角色 cluster-admin admin edit view

---

• cluster-admin  超级管理员，对集群所有权限，和linux下面root一样（在部署dashboard的时候，先创建sa，然后将sa绑定到角色cluster-admin，最后获取到token，这就使用了内置的cluster-admin ）
• admin   主要用于授权命名空间所有读写权限(针对于某个命名空间)
• edit   允许对命名空间大多数对象读写操作，不允许查看或者修改角色、角色绑定。
• view 允许对命名空间大多数对象只读权限，不允许查看角色、角色绑定和Secret

view ClusterRole 允许对资源的只读访问

在前面的例子中， 我们已经使用了默认的view ClusterRole。 它允许读取 一个 命名空间中的大多数资源， 除了Role、 RoleBinding和 Secret。 你可能会想为什么Secrets不能被读取？因为Secrets中的某一个可能包含一个认证token，它比定义在view ClusterRole中的资源有更大的权限 ， 并且允许用户伪装成不同的用户来获取 额外的权限（权限扩散）。

edit ClusterRole允许对资源的修改

接下来是edit ClusterRole, 它允许你修改一 个命名空间中的资源，同时允许读取和修改Secret。

但是， 它也不允许查看或修改Role和 RoleBinding, 这是为了防止权限扩散。

admin ClusterRole赋予一个命名空间全部的控制权

一 个命名空间中的资源的完全控制权是由admin ClusterRole赋予的。 有这个ClusterRole的主体可以读取和修改命名空间中的任何资源， 除了ResourceQuota 和命名空间资源本身。 edit和admin ClusterRole 之间的主要区别是能否在命名空间中查看和修改Role和RoleBinding。

注意为了防止权限扩散， API服务器只允许用户在已经拥有一个角色中列出的所有权限（以及相同范围内的所有权限）的 情 况下， 创建和更新这个角色 。

用cluster-adminClusterRole得到完全的控制

通过将cluster-adminClusterRole赋给主体， 主体可以获得Kubernetes 集群完全控制的权限。 正如你前面了解的那样， adminClusterRole不允许用户修改命名空间的 ResourceQuota对象或者命名空间资源本身。

如果你想允许用户这样做， 需要创建一 个指向cluster-adminClusterRole的 RoleBinding。 这使得RoleBinding 中包含的用户 能够完全控制创建RoleBinding所在命名空间上的所有方面 。

如果你留心观察， 可能已经知道如何授予用户一个集群中所有命名空间的完全控制权 。 就是通过在ClusterRoleBinding而不是RoleBinding中引用cluster admin ClusterRole。

内置角色是可以直接使用的，这样方便授权。

部署 Dashboard

[root@k8s-master ~]# wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.3/aio/deploy/recommended.yaml

修改，只需要添加一行 

spec:
  ports:
    - port: 443
      targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard
  type: NodePort   加上这一行就行了

[root@k8s-master ~]# kubectl apply -f recommended.yaml 

[root@k8s-master ~]# kubectl get pod -n kubernetes-dashboard
NAME                                         READY   STATUS    RESTARTS   AGE
dashboard-metrics-scraper-7b59f7d4df-5tzgb   1/1     Running   2          263d
kubernetes-dashboard-5dbf55bd9d-tgt7b        1/1     Running   6          263d
[root@k8s-master ~]# kubectl get svc -n kubernetes-dashboard
NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
dashboard-metrics-scraper   ClusterIP   10.108.138.194   <none>        8000/TCP        263d
kubernetes-dashboard        NodePort    10.106.187.194   <none>        443:31383/TCP   263d

这里暴露的是443表示使用https访问，对外暴露端口是31383

这里使用token来认证，创建service account并绑定默认cluster-admin管理员集群角色：

[root@k8s-master ~]#  kubectl create serviceaccount dashboard-admin -n kube-system
serviceaccount/dashboard-admin created

 用户授权 

[root@k8s-master ~]# kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
clusterrolebinding.rbac.authorization.k8s.io/dashboard-admin created

[root@k8s-master ~]# kubectl -n kube-system get secret | grep dashboard-admin
dashboard-admin-token-spfnp                      kubernetes.io/service-account-token   3      263d

[root@k8s-master ~]# kubectl -n kube-system get secret | grep dashboard-admin | awk '{print $1}'
dashboard-admin-token-spfnp

[root@k8s-master ~]# kubectl describe secret dashboard-admin-token-spfnp -n kube-system
Name:         dashboard-admin-token-spfnp
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: dashboard-admin
              kubernetes.io/service-account.uid: 8e757c86-13af-47fa-8d69-a4d0805d0152

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InR0cTRHNDNQUGFMeUZ5Rnp1azZnSUEyRVU0WEY1dWdEMEYwd056ZnNkWWcifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tc3BmbnAiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiOGU3NTdjODYtMTNhZi00N2ZhLThkNjktYTRkMDgwNWQwMTUyIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.zbOZ4-5UKqllErK1HLZ75srq6zeBzWWNtmz5LTIS0HES-Ih-HZbyGRJxqoW7-T692DW2J-LvRIZH-RrCw-V-wWT435KR-fku6X6YR6tTSzaUIYB3eh3UDjrgQlHriy1M752YwoCpXBi0k3sHAvzGPDJFupeihum2Dr3ZCvUqtpKeSx9zEoWEXWKyVyux4Wr7zbDYWGT-fe2DEAikosKt_70xPM3igexUT67ljH7DdITWzdcEFqB78NVfWGzSlLX6zddvQu2O17NLL_ea-yaxcv6rSMyYgYShRoPwmY55HHsP81dWuoIosBKml-TYbXAQXIcruKvU0vRS71KzN9yAyQ

使用输出的token登录Dashboard。

 

 

了解其他默认的ClusterRole

---

默认的ClusterRole列表包含了大量其他的ClusterRole, 它们以system:为前缀。 这些角色用于各种Kubemetes组件中 。在它们之中 ， 可以找到如system:kube-scheduler之类的角色， 它明显是给调度器使用的，system:node是给Kubelets组件使用的， 等等。

虽然Controller Manager作为一 个独立的pod来运行 ， 但是在其中运行的每个控制器都可以使用单独的ClusterRole和ClusterRoleBinding (它们以system:Controller: 为前缀）。

这些系统的每个ClusterRole都有 一个匹配的ClusterRoleBinding，它会绑定到系统组件用来身份 认证的用户上。 例如， system:kube-scheduler ClusterRoleBinding将名称相同的ClusterRole分配给 system:kube-scheduler用户， 它是调度器作为身份认证的用户名。
 

 

理性地授予授权权限

---

在默认情况下， 命名空间中的默认ServiceAccount除了未经身份验证的用户没有其他权限（你可能记得前面的示例之一， system:discovery ClusterRole和相关联的绑定允许任何人对一些非资源型的URL发送GET请求）。

因此，在默认情况下，pod甚至不能查看集群状态。 应该授予它们适当的权限来做这些操作。
显然， 将所有的ServiceAccounts赋予cluster-admin ClusterRole是一个坏主意。 和安全问题一 样， 我们最好只给每个人提供他们工作所需要的权限， 一个单独权限也不能多（最小权限原则）。

为每个 pod 创建特定的 ServiceAccount

一 个好的想法是为每一个pod(或一组pod的副本）创建一个特定ServiceAccount， 并且把它和一个定制的Role (或ClusterRole)通过RoleBinding联系起来（不是ClusterRoleBinding, 因为这样做会给其他命名空间的pod对资源的访问权限 ， 这可能不是你想要的）

如果你的一个pod(应用程序在它内部运行）只需要读取pod，而其他的pod也需要修改它们，然后创建两个不同的ServiceAccount，并且让这些pod通过指定在pod spec中的serviceAccountName属性来进行使用，不要将这两个pod所需的所有必要权限添加到命名空间中的默认ServiceAccount上。

假设你的应用会被入侵

你的目标是减少入侵者获得集群控制的可能性 。 现在复杂的应用程序会包含很多的漏洞， 你应该期望不必要的用户最终获得ServiceAccount的身份认证token。 因此你应该始终限ServiceAccount, 以防止它们造成任何实际的伤害。