K8S进阶实践 之 鉴权控制（ServiceAccount&RBAC）

1、RBAC的四种资源

一、Role

一个Role只能受权访问单个namespace

## 示例定义一个名为pod-reader的角色，该角色具备读取default这个命名空间下的pods的权限
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" 表明全部
resources: ["pods"]
verbs: ["get", "watch", "list"]

## apiGroups: "","apps", "autoscaling", "batch", kubectl api-versions
## resources: "services", "pods","deployments"... kubectl api-resources
## verbs: "get", "list", "watch", "create", "update", "patch", "delete", "exec"

二、ClusterRole

一个ClusterRole可以授予和Role同样的权限，可是它是集群范围内的。

## 定义一个集群角色，名为secret-reader，该角色能够读取全部的namespace中的secret资源
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

三、Rolebinding

将role中定义的权限分配给用户和用户组。RoleBinding包含主题（users,groups,或service accounts）和授予角色的引用。对于namespace内的受权使用RoleBinding，集群范围内使用ClusterRoleBinding。

## 定义一个角色绑定，将pod-reader这个role的权限授予给jane这个User，使得jane能够在读取default这个命名空间下的全部的pod数据
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User   #这里能够是User,Group,ServiceAccount
name: jane 
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role #这里能够是Role或者ClusterRole,如果ClusterRole，则权限也仅限于rolebinding的内部
name: pod-reader # match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

注意：rolebinding既能够绑定role，也能够绑定clusterrole，当绑定clusterrole的时候，subject的权限也会被限定于rolebinding定义的namespace内部，若想跨namespace，须要使用clusterrolebinding

## 定义一个角色绑定，将dave这个用户和secret-reader这个集群角色绑定，虽然secret-reader是集群角色，可是由于是使用rolebinding绑定的，所以dave的权限也会被限制在development这个命名空间内
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
name: read-secrets
#
# The namespace of the RoleBinding determines where the permissions are granted.
# This only grants permissions within the "development" namespace.
namespace: development
subjects:
- kind: User
name: dave # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: dave # Name is case sensitive
namespace: luffy
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

考虑一个场景： 若是集群中有多个namespace分配给不一样的管理员，每一个namespace的权限是同样的，就能够只定义一个clusterrole，而后经过rolebinding将不一样的namespace绑定到管理员身上，不然就须要每一个namespace定义一个Role，而后作一次rolebinding。

四、ClusterRolebingding

容许跨namespace进行受权

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

二 、确认当前K8S集群的受权策略

前面介绍过，认证能够经过证书（kubectl），也能够经过使用ServiceAccount（服务帐户）的方式来作认证。大多数时候，咱们在基于k8s作二次开发时都是选择经过ServiceAccount + RBAC 的方式

3、鉴权控制实例需求描述

例子：a,b,c,d四个用户，分别权限以下：
a：受权访问查看kang空间的pods资源
b：受权查看、删除、更新kang空间的的pods资源
c：受权查看全部空间下的pods资源
d：受权查看、删除、更新全部空间下的pods资源

4、a用户受权演示

一、yaml文件

kind: Role         #建立一个role角色
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kang
  name: reader
rules:
- apiGroups: [""] # "" 表明全部
  resources: ["pods"]  # 受权的资源
  verbs: ["get", "watch", "list"]   #可操做方法

---
apiVersion: v1 
kind: ServiceAccount        #建立一个ServiceAccount
metadata:
  name: a                   #a的ServiceAccount
  namespace: kang

---
kind: RoleBinding           #将role与ServiceAccount绑定
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: test
  namespace: kang           #RoleBinding需指定namespace空间
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: Role
  name: reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: a
  namespace: kang

二、根据yaml文件建立相关资源

三、查看a用户token信息

四、Dashboard验证权限

尝试删除其中一个pod，验证是否只有查看

5、b\c\d用户的对应yaml文件

b用户

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kang
  name: writer
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list","update", "patch", "delete"]

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: b
  namespace: kang

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: writer
  namespace: kang
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: Role
  name: writer
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: b
  namespace: kang

c用户yaml文件

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: reader-allpod
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods","namespaces"]
  verbs: ["get", "watch", "list"]

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: c
  namespace: kang

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: reader-allpod
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: reader-allpod
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: c
  namespace: kang

d用户yaml文件

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: writer-allpod
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods","namespaces"]
  verbs: ["get", "watch", "list","update", "patch", "delete"]

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: d
  namespace: kang

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: writer-allpod
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: writer-allpod
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: d
  namespace: kang

6、API请求方法（curl方法）