Kubernetes系统安全-授权策略(authorization policy)
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.Kubernetes授权策略(authorization policy)概述
紧随认证环节之后的是"授权"检查环境;一个常规请求必须在其请求报文中包含用户名,请求的动作以及目标对象;若存在某授权策略对于此请求给予了许可授权，即授权成功。 Kubernetes授权要求使用通用REST属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 Kubernetes支持多种授权模块，如ABAC模式、RBAC模式和Webhook模式，当管理员创建集群时，他们配置了应该在API服务器中使用的授权模块。
如果配置了多个授权模块，Kubernetes将检查每个模块，如果有任何模块授权请求，则可以继续请求，如果所有模块拒绝请求，则拒绝请求（HTTP状态代码403）。
1>.Kubernetes的请求属性(Request Attributes)
user:
身份验证期间提供的用户字符串。
group:
经过身份验证的用户所属的组名列表。
extra:
由身份验证层提供的任意字符串密钥到字符串值的映射。
API:
指示请求是否针对API资源。
Request path:
其他非资源终结点（如/api或/healthz）的路径
API request verb:
API动词get、list、create、update、patch watch、proxy、redirect、delete和deletecollection用于资源请求。
HTTP request web:
HTTP动词get、post、put和delete用于非资源请求。
Resource:
正在访问的资源的ID或名称（仅限资源请求）-对于使用get、update、patch和delete谓词的资源请求，必须提供资源名称。
Subresource:
正在访问的子资源（仅用于资源请求）
Namespace:
正在访问的对象的命名空间（仅适用于命名空间资源请求）。
API group:
正在访问的API组（仅用于资源请求）。enpty字符串指定核心API组。
2>.授权模块(Authorization Modules)
Node:
专用的授权插件，根据Pod对象调度的结果为Node进行授权。
ABAC(Attribute-based access control):
基于属性的访问控制（ABAC）定义了一种访问控制模式，通过使用将属性组合在一起的策略，将访问权限授予用户。这些策略可以使用任何类型的属性（用户属性、资源属性、对象、环境属性等）。
RBAC(Role-based access control):
基于角色的访问控制（RBAC）是一种基于企业中各个用户的角色来管理对计算机或网络资源的访问的方法。在这种情况下，访问是单个用户执行特定任务（如查看、创建或修改文件）的能力。
使用"rbac.authorization.k8s.io" API驱动授权策略,并支持动态配置。
Webhook:
WebHook其实就是一个HTTP回调：在发生某些事情时发生的HTTP POST；通过HTTP POST的简单事件通知。实现WebHooks的web应用程序将在发生某些事情时向URL发送消息。
3>.查看当前操作系统启动的授权
[root@master200.yinzhengjie.org.cn ~]# ll /etc/kubernetes/manifests/ total 16 -rw------- 1 root root 1798 Feb 4 19:39 etcd.yaml -rw------- 1 root root 2606 Feb 4 19:39 kube-apiserver.yaml -rw------- 1 root root 2533 Feb 4 19:39 kube-controller-manager.yaml -rw------- 1 root root 1120 Feb 4 19:39 kube-scheduler.yaml [root@master200.yinzhengjie.org.cn ~]# [root@master200.yinzhengjie.org.cn ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml - --authorization-mode=Node,RBAC [root@master200.yinzhengjie.org.cn ~]# [root@master200.yinzhengjie.org.cn ~]#
4>.检查API访问权限
kubectl提供auth can-i子命令，用于快速查询API授权层。
该命令使用SelfSubjectAccessReview API来确定当前用户是否可以执行给定的操作，并且无论使用何种授权模式都可以工作。
管理员可以将此与用户模拟结合起来，以确定其他用户可以执行的操作。
二.RBAC授权模块概述
1>.什么是RBAC
基于角色的访问控制（RBAC）根据组织中的角色来限制网络访问，已成为高级访问控制的主要方法之一。
RBAC中的角色是指员工对网络的访问级别。
员工仅可获取有效履行其职责所需的信息:
访问权限可以是多种因素，如权限、责任和工作能力。
此外，对计算机资源的访问可以限制在特定的任务上，例如查看、创建或修改文件的能力。
2>.HTTP方法和kubectl命令的对应动作(verb)关系
HTTP方法与API endpoint(kubectl)的对应关系: POST: 对应API endpoint的create。 GET,HEAD: 对应API endpoint的get(for individual resources)和list(for collections)。 PUT: 对应API endpoint的update。 PATCH： 对应API endpoint的patch。 DELETE： 对应API endpoint的delete(for individual resources)，deletecollection(for collections)。
3>.定义RBAC的规则
角色关联：
只有当Subjects已选择或已分配角色时，主题才能行使权限。需要注意的是，一个用户可以对应多个角色。
角色授权：
必须为Subject授权Subjects的活动角色。
权限授权：
只有当权限被授权为使用者的活动角色时，使用者才能行使权限。
4>.Role和ClusterRole
在RBAC API中，角色包含表示一组权限的规则。权限纯粹是附加的（没有“拒绝”规则）。
角色可以用Role在命名空间中定义，也可以用Cluster Role在集群范围内定义。
角色只能用于授予对单个命名空间中资源的访问权限。
ClusterRole可用于授予与角色相同的权限，但由于它们是群集范围的，因此也可用于授予对以下对象的访问权限：
群集范围的资源（如节点）
non-resource endpoints(like "/healthz")
所有命名空间中的命名空间资源（如pods）（例如，运行kubectl get pods所需的所有命名空间）
5>.Kubernetes内置的集群角色(ClusterRole)
kubernetes内置了四个角色(https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles): cluster-admin: 默认绑定system:master group。 admin: 未绑定(None) edit: 未绑定(None) view: 未绑定(None)
三.Role应用案例
1>.创建角色
[root@master200.yinzhengjie.org.cn ~]# vim /yinzhengjie/data/k8s/manifests/basic/rbac/pods-reader.yaml [root@master200.yinzhengjie.org.cn ~]# [root@master200.yinzhengjie.org.cn ~]# cat /yinzhengjie/data/k8s/manifests/basic/rbac/pods-reader.yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pods-reader rules: - apiGroups: [""] # "" 表示core API group resources: ["pods", "pods/log","services"] verbs: ["get", "list", "watch"] [root@master200.yinzhengjie.org.cn ~]# [root@master200.yinzhengjie.org.cn ~]#