k8s 1.28 聚合层部署信息记录

--requestheader-client-ca-file=
--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=
--proxy-client-key-file=

允许聚合层使用apiserver的参数配置

--requestheader-allowed-names=aggregator

--requestheader-client-ca-file=/etc/kubernetes/ssl/ca.pem

--requestheader-extra-header-prefix=X-Remote-Extra-

--requestheader-group-headers=X-Remote-Group

--requestheader-username-headers=X-Remote-User

--proxy-client-cert-file=/etc/kubernetes/ssl/metrics-server.pem

--proxy-client-key-file=/etc/kubernetes/ssl/metrics-server-key.pem

#如果没有在运行api服务器的主机上运行kube-proxy,则需要运行此项。

--enable-aggregator-routing=true

--proxy-client-key-file

--proxy-client-cert-file

--requestheader-client-ca-file

--requestheader-allowed-names

K8s Aggregation Layer 的要求

通过 --proxy-client-key-file 指定私钥文件

通过 --proxy-client-cert-file 指定签名客户端证书文件

通过 --requestheader-client-ca-file 指定签署客户端证书文件的 CA 的证书

通过 --requestheader-allowed-names 指定签名客户端证书中的有效通用名称值 (CNs),如果该值为"",为空,则任何CN名称都是可以接收的

Kubernetes apiserver 将使用 --proxy-client-*-file 指定的文件来对扩展 apiserver 进行身份验证。为了使请求被合规的扩展 apiserver 视为有效,必须满足以下条件:

连接必须使用由 --requestheader-client-ca-file 中的 CA 签署的客户端证书进行。

连接必须使用其 CN 是 --requestheader-allowed-names 中列出的名称之一的客户端证书进行。

注意:您可以将此选项设置为空,如 --requestheader-allowed-names=""。这将向扩展 apiserver 指示任何 CN 都是可以接受的。

当使用这些选项启动时,Kubernetes apiserver 将会:

使用它们对扩展 apiserver 进行身份验证。

在 kube-system 命名空间中创建一个名为 extension-apiserver-authentication 的 configmap,在其中放置 CA 证书和允许的 CN。这些信息可以被扩展 apiservers 用于验证请求。

请注意,Kubernetes apiserver 使用相同的客户端证书对所有扩展 apiservers 进行身份验证。它不会为每个扩展 apiserver 创建一个客户端证书,而是创建一个用于作为 Kubernetes apiserver 进行身份验证的单一客户端证书。这个证书在所有扩展 apiserver 请求中重复使用。

原始请求的用户名和组

当 Kubernetes apiserver 将请求代理到扩展 apiserver 时,它会通知扩展 apiserver 原始请求成功身份验证的用户名和组。它通过代理请求的 HTTP 头部提供这些信息。你必须告知 Kubernetes apiserver 要使用的头部名称。

通过 --requestheader-username-headers 存储用户名的头部

通过 --requestheader-group-headers 存储组的头部

通过 --requestheader-extra-headers-prefix 附加到所有额外头部的前缀

这些头部名称也被放置在 extension-apiserver-authentication configmap 中,以便扩展 apiservers 可以检索和使用。

CA 重用和冲突

Kubernetes apiserver 有两个客户端 CA 选项:

--client-ca-file

--requestheader-client-ca-file

这两个选项是独立工作的,如果使用不当,可能会互相冲突。

--client-ca-file:当请求到达 Kubernetes apiserver 时,如果启用了此选项,Kubernetes apiserver 将检查请求的证书。如果该证书是由 --client-ca-file 所引用文件中的 CA 证书之一签署的,则该请求被视为合法请求,用户的值为公用名称 CN=,组则为组织 O=。请参阅有关 TLS 身份验证的文档。

--requestheader-client-ca-file:当请求到达 Kubernetes apiserver 时,如果启用了此选项,Kubernetes apiserver 将检查请求的证书。如果该证书是由 --requestheader-client-ca-file 所引用文件中的 CA 证书之一签署的,则该请求被视为潜在的合法请求。随后,Kubernetes apiserver 会检查公用名称 CN= 是否在 --requestheader-allowed-names 提供的名称列表中。如果该名称被允许,则请求被批准;如果不被允许,则请求不被批准。

如果同时提供 --client-ca-file 和 --requestheader-client-ca-file,则请求首先检查 --requestheader-client-ca-file 的 CA,然后再检查 --client-ca-file。通常,这两个选项会使用不同的 CA,可能是根 CA 或中间 CA;常规客户端请求与 --client-ca-file 匹配,而聚合请求则与 --requestheader-client-ca-file 匹配。然而,如果两者使用相同的 CA,那么通常会通过 --client-ca-file 通过的客户端请求将失败,因为 CA 将匹配 --requestheader-client-ca-file 中的 CA,但公用名称 CN= 将不会与 --requestheader-allowed-names 中的一个可接受公用名称匹配。这可能导致您的 kubelet 和其他控制平面组件,以及最终用户无法认证到 Kubernetes apiserver。

因此,对于 --client-ca-file 选项(用于授权控制平面组件和最终用户)和 --requestheader-client-ca-file 选项(用于授权聚合 apiserver 请求),请使用不同的 CA 证书。

不认证kubelet的ssl证书:

--kubelet-insecure-tls

非安全的认证方式,一般不推荐,测试环境可以:

kubelet:

anonymousAuth: true

authorizationMode: AlwaysAllow

安全认证的方式,生成环境kubelet配置方式:

kubelet:

anonymousAuth: false

authenticationTokenWebhook: true #必须开启

authorizationMode: Webhook

相关推荐
阿里云云原生2 小时前
理工科 MCP Server 神器,补足人工智能幻觉短板
云原生
人生偌只如初见2 小时前
Kubernetes学习笔记-配置Service对接第三方访问
kubernetes·k8s
阿里云云原生2 小时前
MCP Server 实践之旅第 1 站:MCP 协议解析与云上适配
云原生
liang89993 小时前
Docker(二):docker常用命令
spring cloud·docker·容器
启明真纳5 小时前
统信操作系统使用默认yum源安装 Docker 的踩坑
运维·docker·容器
云攀登者-望正茂5 小时前
Golang 遇见 Kubernetes:云原生开发的完美结合
云原生·golang·kubernetes
lee_yanyi5 小时前
《一键式江湖:Docker Compose中间件部署108式》开篇:告别“配置地狱”,从此笑傲云原生武林!》
docker·云原生·中间件
阿里云云原生6 小时前
Bolt.diy 一键部署,“一句话”实现全栈开发
云原生
weisian1516 小时前
云原生--核心组件-容器篇-1-Docker和云原生关系(Docker是云原生的基石)
docker·云原生·容器