笔记记录 k8s-RBAC

 K8s集群认证之RBAC
kubernetes认证，授权概括总结：

RBAC简明总结摘要：
API Server认证授权过程:
subject(主体)----->认证----->授权【action(可做什么)】------>准入控制【Object(能对那些资源对象做操作)】

认证：
有多种方式，比较常用的：token，tls，user/password
账号:
k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。
它有两种账号: UserAccount(人使用的账号), ServiceAccount（Pod使用的账号）

授权：RBAC
k8s中的授权机制也有很多，但目前主流是RBAC(基于角色的访问控制)
RBAC中的核心概念:
    基于单个名称空间:
role, clusterrole, rolebinding

整个集群级别:
clusterrole , clusterrolebinding

role, clusterrole : 是定义职务，权限，就像公司成立时，就事先制定好有CTO，CEO，总监，经理等职务
rolebinding, clusterrolebinding: 是将具体的账号(Subject) 和 某个role/clusterrole关联，即授权，或叫任职。

subject:
在k8s中，主体是个泛称，它表示k8s中的三类主体， user， group， serviceAccount

object：
Object这个词，含义比较丰富，在不同场景理解要有变化，在k8s中我们通过
# kubectl describe role myrole
Name: myrole
.............
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
deployments [] [] [get list watch]
pods    [] [] [get list watch]
其中，Resources： 它可被称为Resource Group
Resource Names: 它可被称为 Resource，它表ResourceGroup中具体的单个资源
Non-Resource URLs： 它被称为非资源URL
而这三类Object是k8s系统基本的Object。
在yaml清单中，经常看到某种属性为<[]Object>它实际上是yaml语法中的字典 或叫映射(map)。这在报错时，经常看到。
它和这里说的Object可不是一回事。

action:
即具体能对Ojbect做什么，它有: get, list, watch, patch, delete, update, create 等。。。

RBAC核心概念公式
role/clusterrole = object + action
授权单个名称空间： rolebinding = subject + role/clusterRole
授权集群： clusterRoleBinding = subject + clusterRole

 
基本原理：

K8s中的认证和授权机制:
在K8s中我们操作任何资源都需要经历三个检查步骤：认证、授权 和 准入控制。
当然这些仅针对普通用户，k8s中默认clusteradmin是拥有最高权限的。

    认证: 即用户要登陆k8s上操作资源，你必须提供合法的用户名和密码。
    授权: 用户认证通过后，要查看该用户能操作什么资源，若其要操作的资源在其允许操作的资源范围内则通过。
    准入控制: 用户要操作的资源，也许需要级联其它相关资源或级联了其它相关操作，那么这些级联的资源 或 级联的操作该用户是否有权限访问？这个就是有准入控制来检查的，若不允许访问级联资源，那么该资源也将无法访问。因为k8s是高度模块化设计，因此，这三种检查都允许用户自定义使用何种检测机制来进行访问控制。

认证:

    token: 此方式又称为预共享密钥方式的认证，即用户名和密码，如同MySQL中root要登陆，必须事先在user表中创建root密码.
    TLS: 此中方式为证书认证方式，此时K8s服务端 和 客户端要做双向证书认证，即客户端要认证服务端的证书是否为自己认可的CA所签发的证书，且证书中的subject信息CN(主机名)必须与服务端的主机名一致，等等；而服务器端也要认证客户端的证书，也要认可签发该证书的CA，以及证书中的信息也要匹配。以上是两种比较常用的认证方式，还有其它认证，可自行研究。需要注意的是 认证插件中只有一个认证通过，其它插件就无需再次认证了。

授权:
它也是模块化设计,它和认证一样都同时支持多个模块并存，但只要有一个模块认证通过，即通过了此关，可进入下一关进一步检查。
除了下面几种常用授权模块，我们也可在测试时，使用“总是允许” 或 “总是拒绝”来测试账号。

    RBAC：基于角色的访问控制机制，它只有允许授权，没有拒绝授权，因为默认是拒绝所有，我们仅需要定义允许该用户做什么即可。默认kubectl创建的K8s资源，都是默认启用强制RBAC的
    ABAC
    基于Node的授权
    Web-huke的授权（这是一种通过Web的回调机制实现的授权)

准入控制：
这块主要是对认证授权通过后，后期对要操作的级联对象操作的检查，无需过多关注。

K8s上的用户账户:
k8s客户端(一般用:kubectl) ------>API Server
APIServer需要对客户端做认证，默认使用工具安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

通常一个正常的API请求是包含: 用户认证信息，API请求的URL，共同组成。
1. 在K8s中用户账户为:
user: username + userID
group:
extra: 一些扩展信息

2. 在k8s中发起API请求，其内部实际是一个URL请求路径:
格式: http://API_Server_IP:6443/apis/apps/v1/namespaces/default/deployments/myapp-deploy/
一个普通的HTTP请求有:
get, post, put, delete
在K8s中实际用的还是基本的请求方法，但K8s将这些基本方法，又做了更细致的封装，于是就有以下API 请求命令:
get, list, create, update, patch, watch, proxy, redirect(重定向)， delete，deletecollection(级联删除)
一个API请求的URL拆解开后会包含以下信息，当然这些信息是不包含认证，仅是资源:
API Group
Namespace
Resource
Subresource
#再进一步理解授权：
若当前仅授权某用户可get资源，那么它就不能做create，update，delete等操作。
 

在k8s中访问资源，其实就是对URL发起增删改查的操作.
验证方式:
1. 在安装了kubectl的节点上，启动kubectl的代理. 【注: kubectl所在节点必须有认证配置信息,即 .kube/config】
kubectl proxy --port=8888
2. 接着就可以在本地使用HTTP访问8888来向运行在HTTPS协议上的API Server发起请求了
curl   http://localhost:8888/....

#注意：一定要先启动一个Proxy，因为，kubectl自身是有认证信息的，你每次执行kubectl命令时，它都会读取 ~/.kube/config 文件中的认证信息，所以你不需要输入任何认证信息，其实背后，是自动做了认证数据传递的。但你若直接使用curl 来请求APIServer，你就必须给 curl 制作一个API Server认可的认证信息，否则，curl是获取不到任何信息的！所以为了简单演示期间，可以使用上面的命令，先启动一个kubectl代理，然后，curl向它发起请求，这样curl就不需要提供任何认证信息，所有认证都将在kubectl proxy 和 API Server之间自动进行，但通常为了安全，通常仅将代理启动为监听在127.0.0.1上，然后在本地做 curl 请求。
复制代码

kind(即:类型)：
它有三种类型：【每种类型都有一个固定的JSON表达方式,配置清单使用yaml写，但在提交时,会被自动转换为JSON格式】
    1. 对象类型，如: Pod, deployment, service,namespace等这些都称为对象，它们都是可在集群上创建出来的具体实体。
    2. 列表类型，在RESTful风格下它被称为集合,在K8s上称为列表(list)
    # curl  http://localhost:8888/api/v1/namespaces   #注意:namespaces其实就是一个集合,它会列出该对象集合中的所有子资源.
    # curl http://localhost:8888/ap