配置 Aggregation Layer

配置 Aggregation Layer允许使用其他API拓展kubernetes apiserver,即便这些api并非是kubernetes API的核心API部分.

在开始之前
认证流程
启用Kubernetes Apiserver flags

在开始之前

你需要一个kubernetes集群,并且能够正常使用kubectl命令行工具操作该集群,如果你没有准备好的集群,你可以使用Minikube部署,当然你也可以使用如下方式进行测试:

检查集群版本,输入kubectl version.

Note: 在你的环境里配置proxy和extension apiservers间使用双向TLS( mutual TLS)认证时,有一定配置要求:kubernetes和kube-apiserver需要有多个CA证书,这是为了确保proxy是使用Aggregation Layer的CA证书而非其他,例如master的CA证书

警告: 对不同类型的客户端重用相同的CA会对集群的运行能力产生负面影响,从CA Reusage and Conflicts这里获取更多信息

认证流程

不同于Custom Resource Definitions (CRDs), 在你的集群中,除了标准的kubernetes apiserver之外,Aggregation API还设计另外一台服务器,即你的Extension apiserver(例如metrics-server),kubernetes apiserver与extension apiserver双向交互,为了确保安全的交互,kubernetes apiserver使用X509证书认证其自身与extension apiserver的连接.

本节介绍身份验证以及授权流程的工作方式,并如何配置他们.

高级流程如下:

kube-apiserver: 对请求的User进行身份验证并授权他们所请求的路径;
kube-apiserver: 代理请求到extension server;
Extension apiserver: 认证来自kube-apiserver的请求;
Extension apiserver: 认证原始用户的请求
Extension apiserver: 执行

本节的其余部分将详细介绍这些步骤.

流程图如下所示

Kubernetes Apiserver认证和授权

对extension apiserver提供的服务请求路径与其他API请求的方式相同: 与kubernetes apiserver交互,并且extension apiserver提供的该路径已经注册到kubernetes apiserver.

User与kubernetes apiserver交互,需要被允许访问该路径,kubernetes apiserver使用标准身份验证与授权规则来验证用于与组织访问特定路径.

有关kubernetes集群身份验证的概述,请参考“Authenticating to a Cluster”. 有关kubernetes集群资源授权的概述,请参阅“Authorization Overview”.

到目前为止,一切都是标准的kubernetes API请求,身份验证与授权.

kubernetes apiserver现在准备将请求发送到extension apiserver

Kubernetes Apiserver代理请求

现在kubernetes apiserver将会发送或者代理请求到已经注册的extension apiserver处理该请求.为了做到这一点,它需要知道几件事:

kubernetes apiserver向extension apiserver进行身份验证,通知extension apiserver该请求来自有效的kubernetes apiserver.
kubernetes apiserver如何通知extension apiserver原始请求的username和group已经通过验证

为了解决如上两项,你必须配置kubernetes apiserver的一些参数

kubernetes Apiserver客户端证书

kubernetes apiserver通过TLS加密连接到extension apiserver ,使用客户端证书对自己进行验证,你必须在kubernetes apiserver启动时提供如下参数:

使用参数--proxy-client-key-file提供私钥文件
使用参数--proxy-client-cert-file提供客户登入证书文件
使用参数--requestheader-client-ca-file提供客户登入CA证书文件
使用参数--requestheader-allowed-names提供在客户登入证书中有效的Common Names (CN字段)

kubernetes apiserver将使用--proxy-client-*-file认证extension server,为了使一个请求通过一个兼容的extension apiserver被认为是有效的,必须满足如下条件:

该连接必须使用CA证书(--requestheader-client-ca-file提供的证书文件)签发的客户端证书登入
该连接使用的客户端证书CN字段必须列在--requestheader-allowed-names内.Note:你可以设置该参数为空--requestheader-allowed-names="",此表示所有的CN将被允许

当使用这些参数启动时kubernetes apiserver将:

使用这些参数验证extension apiserver
在kube-system命名空间创建名称为extension-apiserver-authentication的configMap,起内容包含了CA证书,以及被允许的CN列表,这些信息将被extension apiserver使用来验证请求

Note: kubernetes apiserver使用相同的哭护短证书验证所有的extension apiserver,它不会对每个extension apiserver创建客户端证书,相当于某一个证书用于验证kubernetes apiserver,那么将被重用与所有的extension apiserver.

原始请求的Username和Group

当kubernetes apiserver代理请求到extension apiserver时,kubernetes apiserver通知extension apiserver原始请求的username和group被允许,他们将被提供在代理请求的 header里,你必须告诉kubernetes apiserver相应的header名称

--requestheader-username-headers参数提供的header名被使用作为提供username
--requestheader-group-headers参数提供的header名被作为提供group
--requestheader-extra-headers-prefix参数提供其他额外的header名称

这些header名称都将被存储在名为extension-apiserver-authentication的configMap里,这些信息可以被extension-apiserver检索和使用

Extension Apiserver验证请求

extension apiserver接收到kubernetes apiserver代理过来的请求,必须验证请求是否来自有效的身份验证代理,kubernetes apiserver正在履行哪个角色,extension apiserver将通过如下步骤

从kube-system命名空间的extension-apiserver-authentication内取出如下字段:
客户端CA证书
被允许的名称(CN)列表
username和group的header名称,以及其他额外的header名
检查TLS请求使用的客户端证书
被configMap中检索到的CA证书签名
CN被configMap中检索到的的CN列表包含
从header中提取相应的username和group

如果上面的都通过,那么请求被认为有效,并且是来自合法身份的验证代理服务器,在本例中,验证代理服务器为kubernetes apiserver

Note: 如上行为是extension apiserver利用利用k8s.io/apiserver/包的默认操作,其他人可能会用命令行选项覆盖它

为了使extension apiserver能够在kube-system的configMap中检索数据,在kube-system有一个名为extension-apiserver-authentication-reader的role可以被使用

Extension Apiserver授权请求

extension apiserver现在可以验证来自请求中的user/group,它通过向Kubernetes apiserver发送标准SubjectAccessReview 请求来实现。

为了使extension apiserver能够将自己的SubjectAccessReview请求提交给kubernetes apiserver，其需要正确的权限,kubernetes提供了一个名为system:auth-delegator的ClusterRole,其具有适当的权限,可以被授予extension apiserver使用的service account

Extension Apiserver执行

如果SubjectAccessReview通过,extension apiserver执行该请求

启用Kubernetes Apiserver flags

通过添加如下kube-apiserver参数以启用aggregation layer,他们可能已经由你的提供商处理

--requestheader-client-ca-file=<path to aggregator CA cert>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to aggregator proxy cert>
--proxy-client-key-file=<path to aggregator proxy key>

CA复用以及冲突

kubernetes apiserver有如下2个客户端CA参数:

--client-ca-file
--requestheader-client-ca-file

如果使用不正确,这些功能中的每一个都可能冲突:

--client-ca-file: 当请求到达kubernetes apiserver,如果该参数被使用,kubernetes apiserver检查请求证书,如果登入证书被--client-ca-file参数中提供的额证书签名,请求被视为合法请求,并且User为common name的值CN=,而group是organization的值O=, 点此查看TLS文档.
--requestheader-client-ca-file: 当请求到达kubernetes apiserver,如果该参数被使用,kubernetes apiserver将检查该请求的证书,如果登入证书由--requestheader-client-ca-file指定的证书签发,那么请求被认为合法,kubernetes apiserver检查证书的common name CN=存在于--requestheader-allowed-names列表,如果该用户被允许,该请求被通过,否则不通过

如果--client-ca-file 和--requestheader-client-ca-file 都提供了相应得CA文件,请求将第一个请求--requestheader-client-ca-file,然后再检查--client-ca-file ,一般情况下,不同的CA根CA以及中间CA,用于选项中的每一个,常规请求与--client-ca-file提供的CA匹配,aggregation请求匹配--requestheader-client-ca-file提供的CA,,然而,如果他们提供的CA相同,那么常规会通过--client-ca-file传递的客户端请求将失败,因为将会匹配--requestheader-client-ca-file提供的CA,但是 common name CN= 将不会匹配到--requestheader-allowed-names允许的列表,这可能直接影响到你的kubelet,其他控制组件以及最终用户,将无法向kubernetes apiserver进行身份验证,为此为--client-ca-file使用不同的CA,来授权控制平面组件和最终用户,使用--requestheader-client-ca-file选项提供的CA,授权聚合apiserver请求.

警告: 除非您了解保护CA使用的风险和机制，否则请勿在上下文中使用重复的CA.

如果没有在节点上运行kube-apiserver,那么你必须在kube-apiserver中添加如下启动参数

--enable-aggregator-routing=true

翻译的文档