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:58Zk8s预定好了四个集群角色供用户使用，使用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: 443targetPort: 8443selector:k8s-app: kubernetes-dashboardtype: 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-adminkubernetes.io/service-account.uid: 8e757c86-13af-47fa-8d69-a4d0805d0152Type: kubernetes.io/service-account-tokenData
====
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, 以防止它们造成任何实际的伤害。