3、k8s集群安全-授权
授权模式/机制/策略
通过API Server的启动参数 --authorization-mode 来设置。
可以指定多个授权模式 --authorization-mode=Node,RBCA,Webhook
多个模式按指定顺序对请求进行授权，每当一个模式拒绝请求时，请求会被转至下一个模式，直至用户授权完成，不再执行之后的授权模式
NODE授权：节点授权，用于kubelet向api server汇报节点状况使用 System Node组 只处理节点请求？
ABAC(Attribute-Based Access Control)：基于属性的访问控制，将一个用户或一组用户与权限相关联，只要有新用户就要关联权限
RBAC(Role-Based Access Control)：基于角色的访问控制，将角色与一组权限向关联，用户和角色相关联，即用户属于这个角色
Webhook，通过于第三方工具，将k8s的用户和权限的请求传给第三方工具，让其决定是否赋予权限。通过调用外部REST服务对用户进行授权
AlwaysDeny：拒绝所有请求，一般用于测试
AlwayAllow：允许所有请求，而不执行授权检查
RBAC资源对象说明
Role
* 一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。
* 角色（Role）的授权范围是名称空间（namespace）。
ClusterRole
* 集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。
* 集群范围的资源，例如Node。
* 非资源型的路径，例如“/healthz”。
* 包含全部命名空间的资源，例如pods（用于kubectl get pods --all-namespaces这样的操作授权）。
* 集群角色（ClusterRole）授权范围是整个kubernetes集群（即所有的名称空间）。
RoleBinding 和 ClusterRoleBinding
* 角色绑定（RoleBinding）或集群角色绑定（ClusterRoleBinding）用来把一个角色绑定到一个目标上，绑定目标可以是User（用户）、Group（组）或Service Account。
* 使用RoleBinding为某个命名空间授权。
* 使用ClusterRoleBinding为集群范围内授权。
* User（用户）和Group（组）是对kubenetes使用者（即是对人的）进行授权，Service Account是对pod进行授权。
语法：
kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname]
#--group=证书签署请求中O的值
#--user=证书签署请求中CN的值（如果多个user属于同一个group，绑定（rolebinding）group的时候，其组内的所有user都会被授权）
* RoleBinding可以引用Role，只对一个名称空间生效。
* RoleBinding也可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组ClusterRole，然后在多个命名空间中重复使用这些ClusterRole。
* ClusterRoleBinding只能引用ClusterRole，用于进行集群级别或者对所有命名空间都生效的授权。
resource、role、rolebinding之间的关系
kubectl get roles
kubectl get rolebingings
查看用户是否可以访问特定资源
kubectl auth can-i create deployments --as dev-user
kubectl auth can-i delete nodes --as dev-user
kubectl auth can-i delete pods --as dev-user --namespace test
kubectl create role developer --verb=list,create,delete --resource=pods
创建Role
developer-role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: developer # 角色命名，为开发人员创建的角色
namespace: default
rules:
- apiGroups: [""] # 支持的API组列表，空白表示核心组
resources: ["pods"] # 支持的资源对象列表角色可以访问的资源是pod
verbs: ["get", "watch", "list"] # 对资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等
resourceNames: [ "blue","orange" ] # 指定某个具体的资源名称
- apiGroups: [""]
resources: ["ConfigMap"]
verbs: ["create"]
创建ClusterRole
cluser和cluserrolebingding作用于集群资源
可以为命名空间资源创建cluster角色，用户可以访问所有命名空间中的这些资源
cluster-admin-role.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: cluser-administrator
rules:
- apiGroups: [""] # 表示核心组
resources: ["nodes"]
verbs: ["get", "create", "list"]
RoleBinding引用Role进行授权
* 下面的例子中的RoleBinding将在default命名空间中把pods_role角色授予用户user_name，这一操作可以让user_name读取default命名空间中的Pod：
]# kubectl create rolebinding rolebinding-pods_role --role=pods_role --user=user_name -n default --dry-run=client -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rolebinding-pods_role
namespace: default
roleRef:
#"roleRef"指定与某Role或ClusterRole的绑定关系
apiGroup: rbac.authorization.k8s.io
kind: Role #此字段必须是Role或ClusterRole
name: pods_role #此字段必须与你要绑定的Role或ClusterRole的名称匹配
subjects:
#你可以指定不止一个“subject（主体）”
#Subjects可以是user、group、service account
#user和group可以是数字、字符串、email，前缀为 system: 的是系统保留，创建时避免使用
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user_name #"user_name"是区分大小写的
RoleBinding引用ClusterRole进行授权
* 例如，在下面的例子中，虽然secrets_clusterrole是一个集群角色，但是因为使用了RoleBinding，所以user_name只能读取default命名空间中的secret：
]# kubectl create rolebinding rolebinding-secrets_clusterrole --clusterrole=secrets_clusterrole --user=user_name -n default --dry-run=client -o yaml
apiVersion: rbac.authorization.k8s.io/v1
#此角色绑定使得用户"user_name"能够读取"default"名字空间中的Secrets
kind: RoleBinding
metadata:
name: rolebinding-secrets_clusterrole
#RoleBinding的名称空间决定了访问权限的授予范围。
#这里隐含授权仅在"default"名字空间内的访问权限。
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: secrets_clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user_name #'user_name'是区分大小写的
ClusterRoleBinding引用ClusterRole进行授权
* 下面的例子允许用户user_name读取任意Namespace中的secret：
]# kubectl create clusterrolebinding clusterrolebinding-secrets_clusterrole --clusterrole=secrets_clusterrole --user=user_name -n default --dry-run=client -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: clusterrolebinding-secrets_clusterrole
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: secrets_clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user_name
命名空间资源&集群资源
命名空间资源
pods rs jobs deployments services secrets roles rolebingdings configmaps pvc
集群资源
nodes pv clusterroles clusterrolebindings certificatesigningrequests namespaces
查看某资源是否是命名空间资源
kubectl api-resources --namespaced=ture
kubectl api-resources --namespaced=false
对资源的引用方式
resources对一类资源进行授权
* 在Kubernetes API中，大多数资源都是使用对象名称的字符串表示来呈现与访问的，例如，对于Pod应使用"pods"。但有一些Kubernetes API涉及子资源（subresource），例如Pod的log，对Pod日志的请求url是GET /api/v1/namespaces/{namespace}/pods/{name}/log。
* 在RBAC角色表达资源时，使用对应API端点的URL中的名字来引用资源。
* 在RBAC角色表达子资源时，使用斜线（/）来分隔资源和子资源（"资源/子资源"）。
示例：
* pods对应名称空间的Pod资源，而log是pods的子资源。允许某主体能同时够读取Pod和Pod log。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"] #!
verbs: ["get", "list"]
ResourceName对某个资源实例进行授权
* 资源还可以通过资源名字（ResourceName）进行引用。在指定ResourceName后，使用get、delete、update和patch动词的请求，就会被限制在这个资源实例范围内。
* 注意：
* 不能使用资源名字（ResourceName）来限制create或者deletecollection请求。对于create请求而言，这是因为在鉴权时可能还不知道新对象的名字。
* 如果使用资源名字（ResourceName）来限制list或者watch请求，客户端必须在它们的list或者watch请求里包含一个与指定的resourceName匹配的metadata.name字段选择器。例如，kubectl get configmaps --field-selector=metadata.name=my-configmap
示例：
* 某主体只能对一个ConFigmap进行get和update操作。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
# 在HTT 层面，用来访问ConfigMap的资源的名称为"configmaps"
resources: ["configmaps"]
resourceNames: ["my-configmap"] #!
verbs: ["update", "get"]
查看集群角色（clusterrole）admin
* 包含所有的资源
kubectl get clusterrole admin -o yaml