1. 什么是API Server

2.访问控制浏览

Object schema validation：表示我们对请求做完变形之后，还要看看这个请求是否合法。
Validating admission：是一个额外的附加校验

3.访问控制细节

API Server是一个服务器，它会起不同的Gorouting来处理不同的请求，当请求出现pannic的时候，这里面就要去确保某个gorouting panic的时候不会把整个HTTP server弄死，所以就有一个panic recovery的机制。
request-timeout：如果不设置超时时间，客户端的这个connection就会一直连着
impersonation:给request加一些header信息
max-in-flight:用于限流的
kube-aggregator:如果我们自定义了一些k8s对象，然后我们有另外的API Server来支撑这些新的对象，我们可以在这里做一些配置

4. 认证

4.1 认证插件

4.2 基于Webhook的认证服务集成

4.2.1 构建符合K8S规范的认证服务

4.2.2 开发认证服务

4.2.3 配置认证服务

4.2.3 配置apiserver

authentication-token-webhook-cache-ttl 表示认证有效期，如果不设置这个可能会导致每次访问都要去访问外部的hook，这样会有成本。

5.鉴权机制

5.1 什么是鉴权

5.2 RBAC VS ABAC

5.2.1 RBAC老图

RBAC是以Role为核心的一个鉴权体系，RBAC并不是K8S特有的，RBAC定义了一些对象以及用什么方式去操作这些对象，这就是PERMISSIONS

5.2.2 RBAC新解

授权主体在K8S里面有两类，如果是基于一个外部认证系统，那么它就是User，如果是由K8S自己生成的系统账号，那就是ServiceAccount。
Role和RoleBindings跟Namespace是相关的。如果我们定义了一个Role，这个Role是要放在某个namespace下面的，也就是说只有这个namespace里面它可以引用这个Role，rolebindings所附有的权限只是针对这个namespace的。比如我们创建一个Role是针对Pod的，verbs是get，当创建RoleBinding的时候，这两个对象都是建在default namespace,那用户拥有roleBinding的时候，只有default namespace的Pod get权限。
clusterRole是集群范围的权限，表示全局范围的。

5.2.3Role与ClusterRole

5.2.4 binding

5.2.5 账户/组的管理

在一个namespace下面可以有很多很多的serviceAccount

5.2.6 针对群组授权

5.2.7 规划系统角色