一、概述
1、通过此前描述可以知道k8s是以后运行我们生产环境中重要应用程序的尤其是无状态程序的一个非常重要的平台。这里面能托管一些核心应用以及核心数据，很显然对于k8s对应接口的访问不是任何人都可以轻易使用的，比如kubectl 这种工具进行访问，如果人人都可以通过kubectl 进行访问那么很显然它能够随意操作我们的应用程序，这是非常危险的，因此k8s对于我们整个系统的认证，授权和访问控制等做了非常精密和精心的设计，考虑到k8s诞生到今天为止还不算太长，但是到目前为止模型设计上已经做的足够安全了。整个k8s集群来说我们apiserver是作为访问控制的唯一入口，如果我们在上面部署了应用程序后通过ingress或者通过service把他们暴露出去之后它是不需要apiserver访问的，它是通过我们节点的nodeport 或者通过我们ingress中ingress controall定义的daemoset 共享宿主机节点网络名称空间监听的宿主机地址，也就是我们的节点空间监听的宿主机的地址，也就是我们的节点地址，直接进入即可。我们作为部署的pod的容器中的应用程序的客户端他们的访问无需经过apiserver，apiserver是我们作为管理平台上的对应的我们部署的各种资源对象而使用的，我们也讲过，apiserver中的api他们还是分了群组的，他们还可以自动做迭代，但是不管怎么讲任何用户试图到这个平台上来操作资源对象时他们必须要经历三种安全相关的操作
a、认证：任何客户端在经由apiserver做操作之前得先完成认证操作，也就意味着用户得有访问k8s的正确的账号和能够通过安全认证才可以
b、授权：认证通过以后只是证明他是一个合法的当前系统用户，它是否拥有删除对应资源的权限还需要做授权检查。
c、准入控制：授权检查完以后貌似我们已经可以操作某些资源了，但是有些资源的操作还要关联到其它资源和相应的环境才能满足他的兼容条件，因此，一个授权操作对于某个资源对象要做的操作虽然用户获得授权但是关联到的其它资源是否有权限呢？以及他是不是在我们指定的操作范围内，还有第三关检查机制，我们称为准入控制。意思是你虽然得到了授权但是这次操作因为要关联到其它的资源或者是其它相关操作我是不是允许你执行这个操作就有准入控制的检查。
2、k8s是高度模块化设计的，因此他的认证授权和准入控制各自都通过插件的方式可由用户自定义选择用什么样的插件来完成何种控制逻辑，比如说对认证来讲他可能有n个认证插件，支持多种不同的认证方式。
a、令牌认证：我们可以支持令牌认证，令牌认证是指双方有一个域共享秘钥，服务端存在的密码就像mysql一样，我们在服务器上事先先创建一个密码存下来随后在登陆时就拿这个密码登陆，这种登陆方式就称之类似于秘钥登陆方式，而且叫对称秘钥认证方式，但是由于k8s提供的是restful 风格的接口，他的所有服务都是通过http协议提供的，因此我们认证信息只能经由http协议的认证守护进行传递，这种认证守护在传递时我们通常称为叫做认证令牌 (token)，此处我们可以称为承载令牌，因为他要经历我们的http协议的守护来实现从客户端，kubectl要拿着这个令牌转为http协议来传输并发给apiserver并由apiserver进行认证。这是最简单的认证方式。这种认证一般就是双方只需要交换一下是否拥有域共享秘钥就足够了。
b、ssl认证：对于k8s访问来讲
第一，ssl认证能让我们客户端去确认服务器的身份，大家知道我们去和服务器通信之前先要求服务器发一个服务器的证书过来我们先看一看这个证书是否是我们认可的ca签署的。如果是我们认可的ca签署的而且里面的信息也就是subject信息与服务器的访问目标主机保持一致那么就认为这个服务器的身份得到认证了，反过来，在k8s通信中重要的是服务器还要认证客户端的身份，因此，kubectl自己也应该有一个证书，也应该有一个私钥，而且这个证书也必须是server端所认可的ca所翻发的证书，更重要的是，客户端身份也要与我们证书当中标识的身份保持一致。所以双方都需要做双向证书认证。认证完以后他们还可以基于ssl会话实现加密通信，也就意味着二者要通过https进行通信了。
8分21秒
Kubernetes 学习14 kubernetes 认证及serviceaccount
原文：https://www.cnblogs.com/Presley-lpc/p/11151860.html