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 规划系统角色
