在前面的学习中,我们知道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,如下所示
原文地址:http://www.cnblogs.com/cosmos-wong/p/16867442.html