Authentication
在前面的学习中，我们知道Kubernetes由一系列的节点和各种组件构成。它们有像管理员那样的用户，对集群进行管理操作，也有像developers的用户，执行测试和部署应用，也有很多终端用户访问部署在集群内的应用。
下面我们将学习，如何实现集群安全，通过使得集群内部组件之间的访问安全，和如何使得访问，管理集群变得安全，通过认证和授权机制，。
有四种不同的用户能够访问集群。End Users访问集群内应用的安全，是由应用自身所管理的，因此不在我们的讨论范围
我们仅仅讨论为了实现管理目的，访问kubernetes集群的用户
因此，我们只剩下两种类型的账户，human如管理员、开发人员；robot，如进程、服务或应用，它们要求访问集群
kubernetes本身并不管理用户账号，它依赖外部源，如包含用户细节的文件或证书，或其他第三方身份认证服务，如LDAP，去管理这些账户。因此你无法像下面的这种方式来创建和查看用户
然而，就Service Account而言，kubernetes能够管理它们
api-server在处理请求之前，会先认证它。
api-server是如何认证的呢？
能够配置很多种不同的认证机制。你可以使用一组保存了用户名和密码的静态密码文件，或者使用静态token文件，或者使用证书来进行认证，另外一组选项是连接到第三方认证协议，如：LDAP、kerberos等。
让我们以一个简单的认证开始。你可以创建一组用户名和密码，保存到csv文件中，使用它作为用户信息源
该文件有三列：密码、用户名、用户ID
随后将该文件作为api-server的选项参数：
如果以服务方式部署的kubernetes，可以这样来添加选项参数，修改完成后，需要重启服务
如果是以kubeadm方式安装的Kubernetes，可以这样来添加选项参数，更新完成后kubeadm将会自动重启api-server
当访问api-server的时候，指定用户名和密码，如在curl命令中，这样来使用
在上面的CSV文件中，我们还可以定义第四列，用来指定用户所属组。
类似地，我们还可以使用静态token文件。指定token，将token文件作为选项参数，传递到api-server中
当在请求api-server时，指定该token作为认证的bearer token，如下所示
