k8s-RBAC

k8s-RBAC认证授权策略

RBAC介绍

在Kubernetes中，所有资源对象都是通过API进行操作，他们保存在etcd里。而对etcd的操作我们需要通过访问 kube-apiserver 来实现，上面的Service Account其实就是APIServer的认证过程，而授权的机制是通过RBAC：基于角色的访问控制实现

RBAC有四个资源对象，分别是Role、ClusterRole、RoleBinding、ClusterRoleBinding

Role----->RoleBinding：是创建指定系统用户对应的role给与什么样的权限，对哪个命名空间内的资源进行使用【需要先创建Role】

ClusterRole----->ClusterRoleBinding：是创建指定系统用户对应的ClusterRole（集群角色功能）给与什么样的权限，对k8s所有命名空间资源使用【需要先创建ClusterRole，这个有问题，不用】

RoleBinding----->ClusterRole：和上效果一致，【不需要创建role和ClusterRole】

K8s——RBAC官网：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

Role：角色

一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用ClusterRole。例如：定义一个角色用来读取Pod的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac          #对应的名称空间
  name: pod-read           #角色名称
rules:
- apiGroups: [""]               #不写=所有
  resources: ["pods"]
  resourceNames: []
  verbs: ["get","watch","list"]

rules中的参数说明：

1、apiGroups：支持的API组列表，例如："apiVersion: batch/v1"等

2、resources：支持的资源对象列表，例如pods、deplayments、jobs等

3、resourceNames: 指定resource的名称

4、verbs：对资源对象的操作方法列表。

 ClusterRole：集群角色

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权

1、集群范围的资源，例如Node

2、非资源型的路径，例如：/healthz

3、包含全部命名空间的资源，例如Pods

例如：定义一个集群角色可让用户访问任意secrets

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterrole
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

 RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是User，Group，Service Account，使用RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内授权。

例如：将在rbac命名空间中把pod-read角色授予用户es，user---->Role----->RoleBinding

[root@master01 ~]# cat rr.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
  name: jane # "name" 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: www
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role # 此字段必须是 Role 或 ClusterRole
  name: pod-reader     # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: rbac.authorization.k8s.io

[root@master01 ~]# kubectl apply -f rr.yaml 
clusterrole.rbac.authorization.k8s.io/secret-reader created
rolebinding.rbac.authorization.k8s.io/read-pods created

RoleBinding也可以引用ClusterRole，对属于同一命名空间内的ClusterRole定义的资源主体进行授权，【主要是这个】                RoleBinding----->ClusterRole

例如：es能获取到集群中所有的资源信息

[root@master01 ~]# cat rr.yaml 
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名字空间决定了访问权限的授予范围。
  # 这里隐含授权仅在 "development" 名字空间内的访问权限。
  namespace: default
subjects:
- kind: User
  name: dave # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount # May be "User", "Group" or "ServiceAccount"
  name: www
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

[root@master01 ~]# kubectl apply -f rr.yaml 
rolebinding.rbac.authorization.k8s.io/read-secrets created

集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权

ClusterRole----->ClusterRoleBinding

例如：允许manager组的用户读取所有namaspace的default

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-state-metrics
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kube-state-metrics
rules:
- apiGroups: [""]
  resources: ["nodes", "pods", "services", "resourcequotas", "replicationcontrollers", "limitranges", "persistentvolumeclaims", "persistentvolumes", "namespaces", "endpoints"]
  verbs: ["list", "watch"]
- 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"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kube-state-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-state-metrics
subjects:
- kind: ServiceAccount
  name: kube-state-metrics
  namespace: kube-system

资源的引用方式

多数资源可以用其名称的字符串表示，也就是Endpoint中的URL相对路径，例如pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log

如果需要在一个RBAC对象中体现上下级资源，就需要使用“/”分割资源和下级资源。

例如：若想授权让某个主体同时能够读取Pod和Pod log，则可以配置 resources为一个数组

apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
  name: logs-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list"]

资源还可以通过名称（ResourceName）进行引用，在指定ResourceName后，使用get、delete、update、patch请求，就会被限制在这个资源实例范围内

例如，下面的声明让一个主体只能对名为my-configmap的Configmap进行get和update操作：

apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
  namaspace: default
  name: configmap-update
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get","update"]

常见角色示例

（1）允许读取核心API组的Pod资源

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]

（2）允许读写extensions和apps两个API组中的deployment资源

rules:
- apiGroups: ["extensions","apps"]
  resources: ["deployments"]
  verbs: ["get","list","watch","create","update","patch","delete"]

（3）允许读取Pod以及读写job信息

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]、
- apiVersion: ["batch","extensions"]
  resources: ["jobs"]
  verbs: ["get","list","watch","create","update","patch","delete"]

（4）允许读取一个名为my-config的ConfigMap（必须绑定到一个RoleBinding来限制到一个Namespace下的ConfigMap）：

rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get"]

（5）读取核心组的Node资源（Node属于集群级的资源，所以必须存在于ClusterRole中，并使用ClusterRoleBinding进行绑定）：

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","list","watch"]

（6）允许对非资源端点“/healthz”及其所有子路径进行GET和POST操作（必须使用ClusterRole和ClusterRoleBinding）：

rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
  verbs: ["get","post"]

常见的角色绑定示例

（1）用户名alice

subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io

（2）组名alice

subjects:
- kind: Group
  name: alice
  apiGroup: rbac.authorization.k8s.io

（3）kube-system命名空间中默认Service Account

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

（4）qa命名空间中的所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

（5）所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

（6）所有认证用户

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

（7）所有未认证用户

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

（8）全部用户 

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io