当设置产品 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 的名字是随意的。
令牌文件的例子:
生成 tokens 的一个非常简单的方法就是运行以下命令:
基于令牌的身份验证面临的挑战就是,令牌是无期限的,而且对令牌清单做任何的修改都需要重新启动 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 策略文件样本如下所示:
在以上例子中,策略文件中的每一行都是 JSON 对象,且指定一个策略。这是从 Kubernetes 文档页面上对策略对象的简要描述。
版本控制特性——允许多版本和策略的转换格式。
api 版本,字符串类型:有效值就是“abac.authorization.kubernetes.io/v1beta1”。
kind,字符串类型:有效值是“policy”。
规格属性——是一个用以下属性的映射:
面向对象匹配属性:
用户,字符串:用户字符串不是从-token-auth-file,就是从证书文件的普通名字(CN)而来。如果你指定用户,那么它就肯定跟经过身份验证的用户匹配。*跟所有请求都匹配。
group,字符串:如果你指定 group,那么它肯定跟 groups 中经过身份验证的用户相匹配。*跟所有请求都匹配。
资源匹配属性
apiGroup,字符串类型:API group,比如拓展版本。*跟所有 APIgroup 相匹配。
命名空间,字符串类型:命名空间字符串。*跟所有的资源请求相匹配。
资源,字符串类型:资源,比如 pods。*匹配所有的资源请求。
非资源匹配属性:
nonResourcePath,字符串类型:跟所有的非资源请求路径相匹配(比如/version,/apis)。*跟匹配所有非资源请求。/foo/*跟/foo/,以及它的子路径。
只读,布尔型:当为真,也就意味着策略只应用于获取,列出和监测操作。
Webhook
调出一个外部 RESTful 授权服务。
身份验证和授权机制的选择取决于你的要求。然而在我的经验看来,我发现基于证书的身份验证方法,基于身份验证方法的 keystone(LDAP),基于身份验证策略的 ABAC,这三种方法的灵活结合提供了所需的功能,来培养 Kubernetes 环境。
想要了解更多关于认证和授权的信息,建议浏览一下两个链接:
认证:http://kubernetes.io/docs/admin/authentication/
授权:http://kubernetes.io/docs/admin/authorization
本文转载自才云 Caicloud 公众号。
原文链接:https://mp.weixin.qq.com/s/wSMDcQpySKFV7xkbC5wJlw
评论