Kubernetes安全机制——Rbac

官网文档：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

1.Kubernetes的安全框架

Kubernetes: 认证、授权 
API server： 
subject --> action --> object 
认证：token，tls，user/password 
账号：UserAccount, ServiceAccount 

授权：RBAC 
role, rolebinding 
clusterrole, clusterrolebinding 
Role，clusterrole表示针对哪些资源可以做那些操作
Rolebinding，clusterrolebinding 表明了把那些Role、clusterrole绑在那些主体（useraccount、serviceaccountNname）之上

rolebinding, clusterrolebinding: 
subject： 
user 
group

role, clusterrole 
object: 
resouce group 
resource 
non-resource url 

action：get, list, watch, patch, delete, deletecollection, ...

Rbac只有许可，没有拒绝
访问K8S集群的资源需要过三关：认证、鉴权、准入控制
• 普通用户若要安全访问集群API Server，往往需要证书、Token或者用户名+密码；Pod访问，需要ServiceAccount
• K8S安全控制框架主要由下面3个阶段进行控制，每一个阶段都支持插件方式，通过API Server配置来启用插件。

1. Authentication 认证
2. Authorization 鉴权
3. Admission Control 准入控制
   

2.传输安全，认证，授权，准入控制

（1）传输安全
告别8080，迎接6443
• 全面基于HTTPS
（2）认证（是否是一个合格的管理者用户）
三种客户端身份认证：
• HTTPS 证书认证：基于CA证书签名的数字证书认证
• HTTP Token认证：通过一个Token来识别用户
• HTTP Base认证：用户名+密码的方式认证 （用的少）
能认证不代表可以操作
（3）授权（是否具有权限）
RBAC（Role-Based Access Control，基于角色的访问控制）：负责完成授权（Authorization）工作。
（4）准入控制（是否具有级联权限，就是说操纵某一个资源的时候，会关联到其他资源，对其他资源是否有权限）
Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器
插件的检查，检查不通过，则拒绝请求。
1.11版本以上推荐使用的插件：
–enable-admission-plugins= \
NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,ResourceQuota
插件可以同时存在
授权插件：Node，ABAC,RBAC,Webhok

3.测试授权

user: username, uid     用户 
group:                用户组
extra： 
API
Request path
  http://172.20.0.70:6443/apis/apps/v1/namespaces/default/deployments/myapp-deploy/ 
HTTP request verb:      做的操作  请求动作
get, post, put, delete 
API requets verb：      具体操作
get, list, create, update, patch, watch, proxy, redirect, delete, deletecollection 
Resource：            访问什么资源
Subresource：         子资源
Namespace 
API group

与api 打交道的 2种
1.来自外部的客户通过api-server对外监听的地址进行通信
2.来自集群内部的pod与api-server通讯是通过service， 客户的证书需要能解析你操纵的service以及pod的ip 用户第一种：
人类用户 userAccountName
第二种pod用户 serviceAccountName kubectl explain pod.spec

这里可以起一个kubectl proxy 反向代理master的api接口，可以在master起也可以在node起，因为走https所以curl不能用那么只能起一个代理，代理和api做认证而我们访问代理并不需要认证，前提是得有认证信息，才能来查询授权
kubectl proxy --port=8080
curl http://localhost:8080/api/v1/namespaces
路径访问方式

http://172.20.0.70:6443/apis/apps/v1/namespaces/default/deployments/myapp-deploy/
复数 组名 命名空间 资源 资源对象
对于k8s来说所有的api都起源于apis（复数），如果你定义资源不直接写v1的都要使用apis/api起始apis

4.RBAC授权策略

RBAC（Role-Based Access Control，基于角色的访问控制），允许通过Kubernetes API动态配置策略。只可以定义许可权限，无法定义拒绝权限，除了许可之外都是拒绝

• 角色 
• Role：授权特定命名空间的访问权限 
• ClusterRole：授权所有命名空间的访问权限 
• 角色绑定 
• RoleBinding：将角色绑定到主体（即subject） 
• ClusterRoleBinding：将集群角色绑定到主体 
• 主体（subject） 
• User：用户 
• Group：用户组 
• ServiceAccount：服务账号

让一个用户扮演一个角色，角色拥有权限，然后用户就拥有了对应角色的权限
把一个permissions授予给一个角色

role：           角色
    operations     有什么样的权限
    objects        对象        

           
总结就是对角色对对象具有什么样的权限 
  rolebinding	角色绑定
user account OR service account    用户账号
role                             角色
总结：让那个用户绑定那个角色，从而用户就拥有了角色的权限
  Role   rolebinding   主要是授予名称空间级别的权限，针对某一个命名空间的权限

如图所示，
（1）如果rolebinding把user与role绑定，那么user只能针对当前这个命名空间的所有资源具有role这个角色的权限，也只是针对当前命名空间
（2）当然如果ClusterRoleBinding把user绑定ClusteRrole，那么这个user就可以针对所有命名空间的所有资源具备ClusterRole这个角色的权限
（3）如果用RoleBinding将user1和ClusterRole绑定的话，RoleBinding只针对当前命名空间，那么user只具备clusterRole的权限，针对当前命名空间的权限，举个例子，比如ClusterRole拥有对所有命名空间的get以及delete的权限，如果RoleBinding将user和ClusterRole绑定以后，那么user只是针对当前命名空间具备了get以及delete的权限，对其他命名空间还是没权限，适用场景，比如10个命名空间每一个命名空间我都需要一个管理员，那么如果用普通的方式需要来10个role并且将10个user分别在各自的命名空间绑定RoleBinding，如果用这种方式的话只需要将10个不同命名空间的user用RoleBinding绑跟ClusterRole绑定起来，我们给ClusterRole赋予权限，那么10个不同命名空间的user就在各自的命名空间具备ClusterRole的权限

红色圆圈代表role 红色长方形代表RoleBinding 红色五边形代表user ，黑色长方形代表命名空间
那么老的方法每一个命名空间需要一个管理员的话就是在每一个命名空间来一个role并且跟user绑定，然后再给role授权

同上不过就是多了个外围的红色五边形代表ClusterRole
那么我们只需要RoleBinding把user和ClusterRole绑定然后给ClusterRole授权那么，每个命名空间的user都可以获得针对自己当前命名空间ClusterRole所拥有的权限
注意：role是命名空间级别，ClusterRole是集群级别，

5.授权姿势（命令or yaml）

（1）创建role
kubectl create role pod-reader --verb=get,list --resource=pod --dry-run -o yaml > lll.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader        #这个角色name
  namespace: default       #那个命名空间 不写默认
rules:
- apiGroups:               #针对api
  - ""
  resources:                #针对那些资源
  - pods 
  verbs:                   #具备那些操作权限
  - get
  - list

（2）资源限制的三种方式

1.具体针对某个资源 Resources
2.可以把Resources设置一个类，然后在这个类下面某一些资源Resource Names
3.也可以Resources设置一个类，然后加一些非资源对象url Non-Resource URLs
（3）创建RoleBinding
kubectl create rolebinding qushuaibo --role=pod-reader --user=qushuaibo --dry-run -o yaml > kkk.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: xxx
  namespace: default
roleRef:                             #表示引用哪一个role而不是ClusterRole
  apiGroup: rbac.authorization.k8s.io   #哪一个api之内的
  kind: Role                        #哪一类资源
  name: pod-reader                #当中的哪一个名称   
subjects:                #被绑定的用户 2类 human和Pod Service Account
- apiGroup: rbac.authorization.k8s.io
  kind: User     #"User", "Group", and "ServiceAccount"如果是sa需要指定namespace
  name: xxx

这里这个用户是serviceaccount创建的用户以及绑定集群在十五会介绍如何创建用户

（4）创建ClusterRole
[root@k8s-master rbac]# kubectl create clusterrole cluster-readers --verb=get --resource=pods --dry-run -o yaml > clusterroole.yaml
这个一般不定义命名空间因为是针对集群资源的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-readers
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list

（5）创建ClusterRoleBinding
切记ClusterRoleBinding跟RoleBinding不同的是ClusterRoleBinding只可以绑定ClusterRole而RoleBinding既可以绑定Role也可以绑定ClusetrRole
[root@k8s-master rbac]# kubectl create clusterrolebinding qushuaibo-adm --clusterrole=cluster-readers --user=qushuaibo --dry-run -o yaml > clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: adm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-readers
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: xxx

（6）用RoleBinding将ClusterRole和User绑定

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: qushuaibo
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-readers
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: qushuaibo

（7）创建命名空间管理员

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: qushuaibo
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: qushuaibo

因为admin是管理员ClusterRole，当把这个跟user用RoleBindeing绑定以后user就具备了在RoleBindeing所在命名空间内的所有权限，
（8）绑定serviceaccount
如果我们授权的时候给一个serviceaccountNa的名字授权了，如果pod启动的时候serviceaccountName 是授权过的name，那么这个pod就拥有了权限

所以pod运行过程中就有role的权限，当然也可以绑定ClusterRole
标准的样板flannel.yaml，如何绑定可以仔细查看flannel.yaml的模板