Authentication

在前面的学习中，我们知道Kubernetes由一系列的节点和各种组件构成。它们有像管理员那样的用户，对集群进行管理操作，也有像developers的用户，执行测试和部署应用，也有很多终端用户访问部署在集群内的应用。

下面我们将学习，如何实现集群安全，通过使得集群内部组件之间的访问安全，和如何使得访问，管理集群变得安全，通过认证和授权机制，。

 

有四种不同的用户能够访问集群。End Users访问集群内应用的安全，是由应用自身所管理的，因此不在我们的讨论范围

 

 

 

我们仅仅讨论为了实现管理目的，访问kubernetes集群的用户

 

因此，我们只剩下两种类型的账户，human如管理员、开发人员；robot，如进程、服务或应用，它们要求访问集群

 

 

 

kubernetes本身并不管理用户账号，它依赖外部源，如包含用户细节的文件或证书，或其他第三方身份认证服务，如LDAP，去管理这些账户。因此你无法像下面的这种方式来创建和查看用户

 

 

然而，就Service Account而言，kubernetes能够管理它们

 

 

 

所有的账户访问都被api-server所管理，不论是通过Kubectrl工具访问还是直接通过API访问，所有的这些请求都会经过api-server

 

 

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，如下所示

 

注意，这些以明文形式存放用户名、密码和token到静态文件中的方式，并不被推荐，因为不安全。比较推荐的做法是使用证书

---

如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮，您的“推荐”将是我最大的写作动力！欢迎各位转载，但是未经作者本人同意，转载文章之后必须在文章页面明显位置给出作者和原文连接，否则保留追究法律责任的权利。