11 k8s 第八篇

0.机制说明

上图：当外部用户（human user）对一个pod 进行操作访问apiserver，首先第一步
认证（authentication），查看你是否是被注册过得用户，然后假如你是get  pod   
的操作，那么就进入到鉴权（authentization），查看你是读还是写，假如是读操
作，那么直接在鉴权环节结束，但是当是写操作，那么要进行准入控制
（admission），查看你的写入操作是否正确，如果全部正确那么写的内容则会被运
行进行到apiserver（这三个程序都在apiserver中，但是是按照插件顺序执行的，
某个对应的插件检查正确才会被下一别执行然后直到最后一步），然后被调用分配到
node上，最后写入到etcd中

当是k8s集群内部的某个pod或service对apiserver进行访问，这种用户叫service 
account ，而这种用户就是k8s内部资源的标准化格式，pod和service的访问是直接
提交到apiserver上，然后k8s根据自己内部的etcd里面存储的信息进行对比认证的

认证：因为系统不是开放给所以用户，因而我们必须确保来访问者是我们当前系统注
册过的用户切允许使用该系统服务或资源的用户，所以他的作用就是注册让该系统识
别的用户

授权（短路模式）：即便是该用户进入k8s系统了，但是不同用户所获得的不同资源权
限，对不同级别的用户或不同职能的用户赋予不同的权限

准入控制（只针对用户的写入操作）：他起到一个审计的作用，假如当用户在使用控
制器创建资源清单的时候，有错误的参数或者执行不正确的操作，准入控制应当检查
出他的错误，然后进行拦截错误不被写入k8s的apiserver中，定义的某些内容是否合
乎apiserver上面的格式，和一些字段等等，都是有准入控制实现

1.访问控制概论

2.认证管理

案例一静态令牌认证：手动创建用户让apiserver加载

第一步：创建密码 账户 UID 所属的组
第二步：修改系统kubeapiserver.yaml文件（此步骤为认证），添加引用参数，数据卷进行引用，容器进行挂载

案例中的–basic-auth-file= 这个选项在v1.20中已经不支持了，再做测试的时候选用别的测试参数
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/ 这里官网可以查看选项参数

----------------------------------------------------

总结：
0.访问方式有两种，一种是远程组件和近程组件访问apiserver，第二种是pod访问
1.如果是master中的组件（比如Controller Manager.scheduler）访问apiserver一般不需要认证，因为在同一台机器上
2.如果是远程的组件（kubectl、kubelet、kube-proxy）访问apiserver话需要https双向认证证书
3.如果是pod访问apiserver，由于pod经常增删，没必要频繁双向认证的话，那么需要使用sa

3.授权管理

在一个组织里面，具有某些权限的集合定义成一个又一个的角色，然后设定某个用户
可以扮演其中的一到多个角色，然后把用户和角色绑定，进而使用户就拥有了角色所
拥有的对应的系统的授权，RBAC是许可授权，没有拒绝的权限，他允许谁干什么，没
有说拒绝谁干什么，默认拒绝所有

授权第一步：创建角色

上图解释：把这个名为pod-reader的角色赋予给用户之后，这个用户可以在default名称空间下对的pod进行  获取pod信息  监听pod  列出所有pod 	

第二步：进行绑定

上图解释：创建名为secret-reader的集群角色，这个集群角色拥有在所有的名称空间下对secrets进行  get secrets信息  监听secrets  列出所有secrets 的操作

上图解释：由于上上个图已经创建了集群角色，名为secret-reader ，然后上图中引
用集群角色，使用roledindig的绑定方式，绑定给Dave用户，仅限于development
名称空间级别下，所以dave用户在development名称空间级别下拥有对旗下的secrets有get    
list  watch的权限