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