k8s学习笔记-授权（RBAC）
授权模块：
- Node - v1.7+支持Node授权，配合NodeRestriction准入控制来限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源，
- 了解更多Node授权模式的信息，请参阅Node授权
- ABAC - 基于属性的访问控制（ABAC）定义了访问控制范例，通过将属性组合在一起的策略来授予用户访问权限。
- ABAC策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。了解更多ABAC模式的信息，请参阅ABAC模式
- RBAC - 在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。
- 在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，
- 用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。要了解有关使用RBAC模式的更多信息，
- 请参阅RBAC模式 .. *截至1.6版本 RBAC模式还是beta版本。
- Webhook - WebHook是一个自定义HTTP回调方法：事件发生时发送HTTP POST; 通过HTTP POST进行简单的事件通知。实现WebHooks的Web应用程序将在某些事件发生时向URL发送消息。
- 了解如何使用Webhook模式的更多信息，请参阅Webhook模式
- Custom Modules - 可以创建Kubernetes的（Custom Modules）自定义模块。
RBAC: Role-based AC
授权user 授权group 授权 service_accout 可以让pod有相应的权限
基于角色的访问控制（“RBAC”）使用“rbac.authorization.k8s.io”API 组来实现授权控制，允许管理员通过Kubernetes API动态配置策略。
在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是 把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。此种方式仅作用于名称空间当中，这是什么意思呢？当User1绑定到Role角色当中，User1就获取了对该NamespaceA的操作权限，但是对NamespaceB是没有权限进行操作的，如get，list等操作。
另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2，User3通过ClusterRoleBinding到ClusterRole，从而使User2、User3拥有集群的操作权限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图：
但是这里有2种绑定ClusterRoleBinding、RoleBinding。也可以使用RoleBinding去绑定ClusterRole。
当使用这种方式进行绑定时，用户仅能获取当前名称空间的所有权限。为什么这么绕呢？？举例有10个名称空间，每个名称空间都需要一个管理员，而该管理员的权限都是一致的。那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得更加繁重。为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，换句话说，此时只需要创建一个ClusterRole就解决了以上的需求。
这里要注意的是：RoleBinding仅仅对当前名称空间有对应的权限。
在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。
user accout OR service accout 只有针对当前的名称空间
角色的创建：
kubectl create role -h
使用kubectl create进行创建角色绑定，指定角色绑定的名称，--role|--clusterrole指定绑定哪个角色，--user指定哪个用户
kubectl create role pods-reader --verb=get,list,watch --resource=pods
[root@k8s-master k8s]# kubectl get role
NAME AGE
pods-reader 4s
[root@k8s-master k8s]# kubectl describe pods-reader
[root@k8s-master k8s]# kubectl create rolebinding -h
kubectl create rolebinding doudou-read-pods --role=pods-reader --user=doudou
[root@k8s-master k8s]# kubectl explain rolebinding.roleRef
[root@k8s-master pki]# kubectl config use-context doudou@kubernetes
Switched to context "doudou@kubernetes".
[root@k8s-master pki]# kubectl get pods 可以运行成功
[root@k8s-master pki]# kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden: User "doudou" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"
从上面的操作，可以总结出，role的定义和绑定，仅作用于当前名称空间，在获取ingress-nginx名称空间时，一样会出现Forbidden！！！
下面clusterrole定义
[root@k8s-master pki]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods
kubectl get ClusterRole|egrep read
kubectl delete rolebinding doudou-read-pods #删除前面的绑定
集群绑定
kubectl create clusterrolebinding magedu-read-all-pods --clusterrole=cluster-read --user=doudou
为了方便演示创建一个普通用户
这里我们需要切换回kubernetes-admin账户，是由于magedu账户不具备创建的权限，这也说明普通用户是无法进行创建K8S资源的，除非进行授权。
如下，我们另开一个终端，将配置到一个普通用户ik8s上，使其使用豆豆账户进行通信
[ik8s@k8s-master k8s]$ kubectl config use-context doudou@kubernetes
Switched to context "doudou@kubernetes".
[ik8s@k8s-master k8s]$ kubectl get pods
[ik8s@k8s-master k8s]$ kubectl get pods -n kube-system
[ik8s@k8s-master k8s]$ kubectl get pods -n ingree-nginx
[ik8s@k8s-master k8s]$ kubectl delete pods myapp-deploy-675558bfc5-bmkmv
Error from server (Forbidden): pods "myapp-deploy-675558bfc5-bmkmv" is forbidden:
上面测试结果可以看到用户有了集群的赋予角色权限，可以看所有名称空间的POD资源，但是其他删除操作还是拒绝的。
通过rolebinding到集群角色magedu-read-pods当中，此时，doudou仅作用于当前名称空间的所有pods资源的权限
kubectl delete clusterrolebinding doudou-read-all-pods
kubectl create rolebinding doudou-read-pods --clusterrole=cluster-reader --user=doudou
[ik8s@k8s-master k8s]$ kubectl get pods
在查询其他名称空间的就会报错，这里不做测试了
[ik8s@k8s-master ~]$ kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden:
查看管理员的集群角色的资源信息
kubectl get clusterrole admin -o yaml
可以发现对POD 有删除和查看权限。。。。。
创建角色绑定资源，把管理集群角色的权限绑定到之前的用户标识上面，这样就可以实现删除和查看POD 资源了
kubectl create rolebinding default-ns-admin --clusterrole=admin --user=doudou
[ik8s@k8s-master k8s]$ kubectl get pods
[ik8s@k8s-master k8s]$ kubectl delete pods myapp-deploy-675558bfc5-tkxdx
pod "myapp-deploy-675558bfc5-tkxdx" deleted
[ik8s@k8s-master k8s]$ kubectl get deploy
[ik8s@k8s-master k8s]$ kubectl delete deploy/myapp-deploy
deployment.extensions "myapp-deploy" deleted
总结：
RBAC不仅仅可以对user进行访问权限的控制，还可以通过group和serviceaccount进行访问权限控制。
当我们想对一组用户进行权限分配时，即可将这一组用户归并到一个组内，从而通过对group进行访问权限的分配，达到访问权限控制的效果。
从前面serviceaccount我们可以了解到，Pod可以通过 spec.serviceAccountName来定义其是以某个serviceaccount的身份进行运行，
当我们通过RBAC对serviceaccount进行访问授权时，即可以实现Pod对其他资源的访问权限进行控制。
也就是说，当我们对serviceaccount进行rolebinding或clusterrolebinding，会使创建Pod拥有对应角色的权限和apiserver进行通信。
浙公网安备 33010602011771号