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