授权发生在认证成功之后、同i过认证就可以知道请求用户是谁、然后kubernetes会根据事先定义的授权策略来决定用户是否有权限访问、这个过程就称为授权
每个发送到APIServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等、授权就是根据这些信息和授权策略进行比较、如果符合策略、则认为授权通过、否则会返回错误
API Server目前支持以下几种授权策略：
·AlwaysDeny：表示拒绝所有请求、一般用于测式
·AlwaysAllow：允许接收所有请求、相当于集群不需要授权流程（kubernetes默认的策略）
·ABAC:基于属性的访问控制、表示使用用户配置的授权规则对用户请求进行匹配和控制
·Webhook：通过调用外部REST服务对用户进行授权
·Node：是一种专用模式、用于对kubernetes发出的请求进行访问控制
·RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）
RBAC（Role-Base Access Control）基于角色的访问控制、只要是在描述一件事情：给哪些对象授予了哪些权限、其中涉及到了下面几个概念：
·对象：User、Group、ServiceAccount
·角色：代表着一组定义在资源上的可操作的动作
·绑定：将定义好的角色跟用户绑定在一起
RBAC引入了4个顶级资源对象：
·Role、ClusterRole：角色、用于指定一组权限
·RoleBinding、ClusterRoleBinding：角色绑定、哟用于将角色（权限） 赋予对象
Role、ClusterRole：一个角色就是一组权限的集合、这里的权限都是许可形式的（白名单）
#Role 的资源清单：
#Role只能对命名空间内的资源进行授权、需要指定namespace
--------------------------------------------------------------------------
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: authorization-role
namespace: dev
rules:
- apiGroups: [""] #支持的API组列表、""空字符串、表示核心API群
resources: ["pods"] #支持的资源对象列表
verbs: ["get", "watch", "list"] #资源对象可操作的方法（资源对象的权限）
-----------------------------------------------------------------------------------
#ClusterRole的资源清单：
#ClusterRole可以对集群范围内资源、跨namespace的范围资源、非资源类型进行授权
----------------------------------------------------------------------------------
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: authorization-clusterrole
rules:
- apiGroups: [""] #支持的API组列表、""空字符串、表示核心API群
resources: ["pods"] #支持的资源对象列表
verbs: ["get", "watch", "list"] #资源对象可操作的方法（资源对象的权限）
------------------------------------------------------------------------------
需要详细说明的是rule中的参数：
1、apiGroups：支持的资源对象列表
·"","apps","autoscaling","batch"
2、resources：支持的资源对象列表
·"services", "endpoints", "pods", "secrets,“configmaps","crontabs","deployments","jobs""nodes","rolebindings",
·"clusterroles","da aemonsets", "replicasets", "statefulsets","horizontalpodautoscalers","replicationco ontrollers","cronjobs"
3、verbs：对资源对象的操作方法列表
·"get", "list", "watch", "create", "updatae", "patch", "delete", "exec"
RoleBinding、ClusterRoleBinding
RoleBinding、ClusterRoleBinding
角色绑定用来把一个角色绑定到一个目标对象上、绑定目标可以是User、Group或则是ServiceAccount
#RoleBinding的资源清单：
#RoleBinding可以将同一namespace中的subject绑定到某个Role下、则此subject即具有该Role定义的权限
-----------------------------------------------------
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: authorization-role-binding
namespace: dev
subject: #用于定义对象
- kind: User
name: taixin
apiGroup: rbac.authorization.k8s.io
roleRef: #指向的角色
kind: Role
name: authorization-role
apiGroup:rbac.authorization.k8s.io
-----------------------------------------------------------------------
#ClusterRoleBinding的资源清单
#ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject域ClusterRole绑定、授予权限
--------------------------------------------------------------
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: authorization-role-binding
subject: #用于定义对象
- kind: User
name: taixin
apiGroup: rbac.authorization.k8s.io
roleRef: #指向的角色
kind: Role
name: authorization-role
apiGroup:rbac.authorization.k8s.io
-----------------------------------------------------------
实战：创建一个只能管理dev空间下的Pods资源的账号
1、创建账号
1、创建证书：
·mkdir /etc/kubernetes/pki/ -p
· cd /etc/kubernetes/pki/
· (umask 007;openssl genrsa -out devman.key 2048) #创建一个名为devman.key 的证书
2、用apiserver的证书去签署
·签名申请、申请的用户是devman、组是devgroup
·openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/0=devgroup" #生成一个dev.csr的签名证书
3、签署证书：
·openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650
---------------------------------------------------
Signature ok
subject=/CN=devman
Getting CA Private Key
#生成devman.crt和ca.srl文件
------------------------------------
4、设置集群、用户、上下文信息
·设置集群kubernetes：kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.177.160:6443
·设置用户devman：kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key
·让用户devman绑定到集群kubernetes：kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman
5、切换账户devman：
·kubectl config use-context devman@kubernetes
---------------------------------------------------
Switched to context "devman@kubernetes". #当前用户
-----------------------------------------------------
·使用该账户执行查看dev下的pod、提示无权限：kubectl get pods -ndev
----------------------------------------------------------------------
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"
-----------------------------------------------------------------------------------------------------------------------------------
6、切换会管理员权限去给devman账户授权：
·默认admin是管理员：kubectl config use-context kubernetes-admin@kubernetes
7、创建角色Role、然后将角色绑定（RoleBinding）到devman用户：
·创建yaml文件：vim dev-role.yaml
---------------------------------------------------------------------
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
namespace: dev
name: dev-role #角色名
rules:
- apiGroups: [""] #组
resources: ["pods"] #角色可操作的资源对象
verbs: ["get", "watch", "list"] #角色的权限
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: authorization-role-binding
namespace: dev
subjects: #绑定的用户信息
- kind: User
name: devman
apiGroup: rbac.authorization.k8s.io
roleRef: #给用户授权绑定的角色
kind: Role
name: dev-role #角色吗，名
apiGroup: rbac.authorization.k8s.io
------------------------------------------------------------------------------------
8、执行文件创建角色和用户授权：kubectl create -f dev-role.yaml
----------------------------------------------------------------------
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created
-------------------------------------------------------------------------
9、再次切换账户devman：
·kubectl config use-context devman@kubernetes
·再查看pod资源：kubectl get pods -ndev
·此时就可以查看dev空间下的pods了
·注意只能查看dev空间下的、其它空间的没有授权是无法查看的标签：48,kubernetes,dev,角色,devman,k8s,authorization From： https://www.cnblogs.com/littlecc/p/17701161.html