转载

如何理解Kubernetes认证和授权

当设置产品Kubernetes集群的时候，认证和授权是两个很重要的基本需求。在这篇文章中，让我们来浏览一些细节，这些细节可以帮助Kubernetes环境做好方案。

如何理解Kubernetes认证和授权

比如说，你现在已经引发了通过输入yaml文件到kubectl（kubectl create－f pod.yaml）创建POD的命令。这个命令被发送到有安全保障的api－server端口（ http:// ），然后身份验证流就开始生效了。注意，如果你正在为api－server使用不安全的端口（ http:// ），那么验证就无法应用。（ http:// ）理想情况下生产环境设置中应该避免不安全端口（ http:// ）。

以下是这篇文章中会提到的在Kubernetes中可使用的验证途径。

客户证书验证

为了使用这个方案，api－server需要用－client－ca－file＝<PATH_TO_CA_CERTIFICATE_FILE>选项来开启。CA_CERTIFICATE_FILE肯定包括一个或者多个认证中心，可以被用来验证呈现给api－server的客户端证书。客户端证书的／CN将作为用户名。

基于令牌的身份验证

为了使用这个方案，api－server需要用－token－auth－file＝<PATH_TO_TOKEN_FILE>选项来开启。TOKEN_FILE是个csv文件，每个用户入口都有下列格式：token，user，userid，group。

Group的名字是随意的。

令牌文件的例子：

如何理解Kubernetes认证和授权

生成tokens的一个非常简单的方法就是运行以下命令：

如何理解Kubernetes认证和授权

基于令牌的身份验证面临的挑战就是，令牌是无期限的，而且对令牌清单做任何的修改都需要重新启动api－server。

基本认证

为了使用这个方案，api－server需要使用－basic－auth－file＝<PATH_TO_HTTP_AUTH>选项来开启。HTTP_AUTH_FILE是个csv文件，每个用户入口都有下列格式：password，user name，userid。目前，对AUTH_FILE的任意修都需要重新启动api－server。

Open ID

Open ID支持也是可用的，但是还在试验阶段。

Keystone

Keystone支持也是可用的，但是还在试验阶段。如果你想要将keystone跟LDAP或者动态目录服务整合到一起，那么就要使用keystone认证方法。为了使用这个方案，api－server需要用－experimental－keystone－url＝<KEYSTONE_URL>选项来开启服务。验证成功之后，下一步就是找出对于验证用户来说，哪些操作是允许的。目前来讲，Kubernetes支持4种验证策略方案。api－server需要使用－authorization－mode＝<AUTHORIZATION_POLICY_NAME>选项来开启。

始终否认

这个策略否认所有的请求。

始终允许

这个策略允许所有的请求。

基于属性的访问控制

ABAC允许灵活的用户特定授权策略。当使用－authorization－policy－file＝<PATH_TO_ABAC_POLICY_FILE>选项开启api－sever的时候，ABAC的策略文件需要指定。目前，对策略文件有任何的修改都需要重启api－server。ABAC策略文件样本如下所示：

如何理解Kubernetes认证和授权

在以上例子中，策略文件中的每一行都是JSON对象，且指定一个策略。这是从Kubernetes文档页面上对策略对象的简要描述。

版本控制特性——允许多版本和策略的转换格式。

api版本，字符串类型：有效值就是“abac.authorization.kubernetes.io/v1beta1”。kind，字符串类型：有效值是“policy”。

规格属性——是一个用以下属性的映射：

面向对象匹配属性——用户，字符串：用户字符串不是从－token－auth－file，就是从证书文件的普通名字（CN）而来。如果你指定用户，那么它就肯定跟经过身份验证的用户匹配。＊跟所有请求都匹配;group，字符串：如果你指定group，那么它肯定跟groups中经过身份验证的用户相匹配。＊跟所有请求都匹配。