前言：
kubernetes集群系统比较复杂的部分应该算是权限验证了，本文也主要就二进制安装的k8s集群的权限控制做一个简单的抛砖引玉。
主要还是根据前面所写的部署博客来分析，博文地址为：kubernetes二进制安装教程单master_zsk_john的博客-CSDN博客
一，什么是权限控制？什么是RBAC？
一般我们认为RBAC就是权限控制，是基于角色来进行的细度话的权限控制，主要在于用户可能有一个，但，用户的属性，角色可能会有很多个，这样组合方式就非常多，也能做到更加的精细，细粒度很高。
- RBAC（Role-Based Access Control，基于角色的访问控制），允许通过Kubernetes API动态配置策略。也就是说整个用户系统是围绕角色来进行权限的分配划分。当然，也可以看做是一套复杂的访问控制策略。
二，权限控制的分类
在k8s中，大体可以分为六种权限控制：ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。
从1.6版本起，Kubernetes 默认启用RBAC访问控制策略。从1.8开始，RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC，启用RABC。所以RBAC也就成了一种默认选用的授权模式。
webhook在k8s中的使用是在ingress插件中使用，最主要的也是最常用的就让RBAC。
二，RBAC的构成要素
在RBAC模型里面，有3个基础组成部分，分别是：主体、角色和权限。
- User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
- group（用户组）：相同类型的用户组成的组
- serverAccount（服务账号）：User，group，serverAccout都是主体类型对象
- Role（角色）：不同角色具有不同的权限，角色，比较抽象的对象。是一系列权限的集合，例如一个Role可包含读取和列出 Pod的权限
- Permission（权限）：访问权限（例如，get，update，list，也就是那些verbs）
- 用户-角色映射：用户和角色之间的映射关系
- 角色-权限映射：角色和权限之间的映射
那么，这里就有一个线性逻辑了，权限--->角色---->主体，也就是从权限开始，结束于主体了。权限指的是对于各种资源也可以称之为对象的动作定义，例如，列出pod名称，列出所有的deployment等等。
关于资源也就是对象，在k8s中是由apiserver定义的，其中关于权限认证的资源对象有这些：
[root@master cfg]# k api-resources NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding configmaps cm true ConfigMap secrets true Secret serviceaccounts sa true ServiceAccount mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration apiservices apiregistration.k8s.io false APIService tokenreviews authentication.k8s.io false TokenReview localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview subjectaccessreviews authorization.k8s.io false SubjectAccessReview certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest poddisruptionbudgets pdb policy true PodDisruptionBudget podsecuritypolicies psp policy false PodSecurityPolicy clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding clusterroles rbac.authorization.k8s.io false ClusterRole rolebindings rbac.authorization.k8s.io true RoleBinding roles rbac.authorization.k8s.io true Role
认证「Authentication」
认证有如下几种方式：
1、HTTP Token认证：通过一个Token来识别合法用户。
HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串来表达客户的一种方式。每一个Token对应一个用户名，存储在API Server能访问的文件中。当客户端发起API调用请求时，需要在HTTP Header里放入Token。
2、HTTP Base认证：通过用户名+密码的方式认证
用户名:密码 用base64算法进行编码后的字符串放在HTTP Request中的Heather Authorization 域里发送给服务端，服务端收到后进行解码，获取用户名和密码。
3、最严格的HTTPS证书认证：基于CA根证书签名的客户端身份认证方式
授权「Authorization」
认证只是确认通信的双方都是可信的，可以相互通信。而授权是确定请求方有哪些资源的权限。API Server目前支持如下几种授权策略（通过API Server的启动参数 --authorization-mode 设置）
- AlwaysDeny：表示拒绝所有请求。仅用于测试
- AlwaysAllow：表示允许所有请求。如果有集群不需要授权流程，则可以采用该策略
- Node：节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的 API 请求
- Webhook：是一种 HTTP 回调模式，允许使用远程 REST 端点管理授权
- ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
- RBAC：基于角色的访问控制，默认使用该规则
localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview subjectaccessreviews authorization.k8s.io false SubjectAccessReview
例如这些资源就是授权，但很少使用。
那么，RBAC的开启是在apiserver的配置文件内，例如，我前面写的二进制安装部署文档内：
[root@master cfg]# cat /opt/kubernetes/cfg/kube-apiserver.conf KUBE_APISERVER_OPTS="--v=2 \ --logtostderr=false \ --log-dir=/opt/kubernetes/logs \ --etcd-servers=https://192.168.217.16:2379,https://192.168.217.17:2379,https://192.168.217.18:2379 \ --bind-address=192.168.217.16 \ --secure-port=6443 \ --advertise-address=192.168.217.16 \ --allow-privileged=true \ --service-cluster-ip-range=10.0.0.0/24 \ --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \ --authorization-mode=RBAC,Node \ 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
可以看到，--authorization-mode可以定义多个，也就是授权模式可以混用。
RBAC【RBAC】
clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding clusterroles rbac.authorization.k8s.io false ClusterRole rolebindings rbac.authorization.k8s.io true RoleBinding roles rbac.authorization.k8s.io true Role
其实，本文主要要讨论的就是这四个：角色，角色绑定，集群角色，集群角色绑定，这里需要注意，角色和角色绑定是被限定在namespace里的。
三，
（1）角色的建立
role定义只是定义权限，无关主体也就是用户，组，sa这些，是权限的集合。例如，建立一个名字叫test的角色，role和namespace是绑定的：
命令行方式：
[root@master cfg]# k create role test --verb=list,get,watch --resource=pods role.rbac.authorization.k8s.io/test created
yaml文件形式：
[root@master cfg]# cat test-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: test rules: - apiGroups: [""] resources: ["nodes", "pods", "services", "resourcequotas", "replicationcontrollers", "limitranges", "persistentvolumeclaims", "persistentvolumes", "namespaces", "endpoints"] verbs: ["list", "watch","get","update","create","ptach"] - apiGroups: ["extensions"] resources: ["daemonsets", "deployments", "replicasets"] verbs: ["list", "watch"] - apiGroups: ["apps"] resources: ["statefulsets"] verbs: ["list", "watch"] - apiGroups: ["batch"] resources: ["cronjobs", "jobs"] verbs: ["list", "watch"] - apiGroups: ["autoscaling"] resources: ["horizontalpodautoscalers"] verbs: ["list", "watch"]
以yaml文件形式为例详解：
这个新建的role是没有定义namespace，因此，是默认default这个namespace下，这个可以随意定义一个namespace，role是仍然可以建立的。
- apiGroups: [""] # apiGroups 就是api资源组，使用kubectl api-resources 第三列可以查看到 例如，k api-resources 里查到的jobs是属于batch 这个apigroup的 --verb=* 用星号可表示全部权限
resources 指的就是资源对象了，比如，这个角色就对很多的资源有权限，例如pod，namespace，--resource=* 同样也可以用星号表示所有资源
verbs 就是指的权限了，所有权限是verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
[root@master cfg]# k describe role test
Name: test
Labels: <none>
Annotations: PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
endpoints [] [] [list watch get update create ptach]
limitranges [] [] [list watch get update create ptach]
namespaces [] [] [list watch get update create ptach]
nodes [] [] [list watch get update create ptach]
persistentvolumeclaims [] [] [list watch get update create ptach]
persistentvolumes [] [] [list watch get update create ptach]
pods [] [] [list watch get update create ptach]
replicationcontrollers [] [] [list watch get update create ptach]
resourcequotas [] [] [list watch get update create ptach]
services [] [] [list watch get update create ptach]
statefulsets.apps [] [] [list watch]
horizontalpodautoscalers.autoscaling [] [] [list watch]
cronjobs.batch [] [] [list watch]
jobs.batch [] [] [list watch]
daemonsets.extensions [] [] [list watch]
deployments.extensions [] [] [list watch]
replicasets.extensions [] [] [list watch]
（2）集群角色 clusterrole
clusterrole是不和namespace绑定的，适用范围是整个集群，很明显是比role的使用范围大的。别的和role都基本一致，例如：
定义一个clusterrole：
[root@master ~]# kubectl create clusterrole testclusterrole --verb=get,list,watch --resource=pods --dry-run -o yaml W0904 20:27:52.564182 19827 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: testclusterrole rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch
