Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master节点上。在默认情况下，kube-apiserver进程在本机的8080端口（--insecure-port）提供REST服务。我们可以同时启动HTTPS安全端口（--secure=6443）来启动安全机制，加强REST API访问的安全性。

通常我们使用kubectl来与Kubernetes API Server交互，它们之间的接口是REST调用。也可以使用curl命令行工具进行快速验证。

另外是通过编程的方式调用Kubernetes API Server 具体又细分为以下两种场景：

1.     运行在POD里的进程调用Server API. Pod中的进程如何指定API Server的访问地址呢?答案很简单，因为Kubernetes API Server本身也是一个Service,它的名字是“kubernetes”,IP地址是ClusterIP地址池里面的第一个地址。服务端口是HTTPS端口443.

2.       开发基于Kubernetes的管理平台，比如调用Kubernetes API来完成Pod,Service,RC等资源对象的图形化创建和管理界面。可采用社区中相关的Client Library.

正常情况下，为了确保Kubernetes集群的安全，API Server都会对客户端进行身份认证，认证失败则无法调用API。此外，Pod中访问Kubernetes API Server服务的时候，是以Service方式访问服务名为kubernetes的这个服务，而kubernetes服务又只在HTTPS 443上提供服务，那么如何进行身份认证呢？ 答案是 Service Account Token.

如果kubernetes开启了ServiceAccount（–admission_control=…,ServiceAccount,… ）那么会在每个namespace下面都会创建一个默认的default的ServiceAccount。

每个ServiceAccount下面都会拥有一个加密过的secret作为Token. 该token也叫service-account-token，该token才是真正在API Server验证(authentication)环节起作用的。

当用户在该namespace下创建pod的时候都会默认使用这个service account，下面是get pod 截取的部分，可以看到kubernetes会把默认的service account挂载到容器内。

查看一下secret的具体内容

上面的内容是经过base64加密过后的。可以看到ca.crt（这个是API Server的CA公钥证书，用于Pod中的Process对API Server的服务端数字证书进行校验时使用的）,namespace和token被放到了容器内，这样容器就可以通过https的请求访问apiserver了。

API Server的service account验证过程

以kube-system namespace下的“default” service account为例，Pod的usrname全称为：system:serviceaccount:kube-system:default。有了username，那么credentials呢？就是上面提到的service-account-token中的token。API Server的验证环节支持多种身份校验方式：CA 证书认证、Token 认证、Base 认证。一旦API Server发现client发起的request使用的是service account token的方式，API Server就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。该token是API Server在创建service account时用API server启动参数：–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值，那么将默认使用–tls-private-key-file的值，即API Server的私钥。

Secret