Karmada 组件证书内容标准化基于单一根 CA 的组件级 X.509 证书隔离方案【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada导读Karmada 控制平面包含 apiserver、scheduler、controller-manager、webhook 等十余个相互通信的组件历史上它们大量共享同一份证书内容导致无法通过证书 Subject 区分组件身份、单点证书泄露即可危及整个控制面。本方案Self-Signed_Certificate_Content_Standardization提出基于单一根 CA 的分层证书体系为 8 个服务端组件签发独立服务端证书、为 11 个客户端组件签发独立客户端证书并在 SAN、CN、O 字段上全面标准化。读完本文你将掌握 Karmada 各组件证书的职责划分、证书生成脚本的改造思路、每个组件的推荐 CN/SAN 取值与对应启动参数并能结合 hack/deploy-karmada.sh 中已落地的实现进行验证。一、背景共享证书带来的身份混淆与安全风险1.1 当前证书管理的两大缺陷Karmada 控制平面的组件间通信高度依赖自签证书。原方案下证书管理存在两个突出问题身份混淆风险所有组件共享相同内容的证书无法通过证书 Subject 字段区分组件身份。一旦审计或排障时需要确认这条请求来自哪个组件证书本身给不出答案。安全脆弱性单个证书泄露即可能危及整个系统安全违背最小权限原则least privilege。任何一个组件的私钥丢失都等于把整个控制面的通信密钥交给了攻击者。1.2 服务器端组件与客户端组件的定义方案给出了判定组件角色的清晰标准若组件存在连接其他组件的行为可视为客户端组件若组件存在对外提供 API 端点的行为可视为服务端组件。按此标准Karmada 当前包含8 个服务端组件karmada-apiserver同时充当服务端与客户端karmada-aggregated-apiserver同时充当服务端与客户端karmada-scheduler-estimator同时充当服务端与客户端karmada-metrics-adapter同时充当服务端与客户端karmada-webhook同时充当服务端与客户端karmada-search同时充当服务端与客户端etcdkarmada-interpreter-webhook同时充当服务端与客户端11 个客户端组件karmada-apiserver连接 etcdkarmada-aggregated-apiserver连接 etcd、apiserverkarmada-scheduler-estimator连接 apiserverkarmada-controller-manager连接 apiserverkarmada-metrics-adapter连接 apiserverkarmada-webhook连接 apiserverkarmada-search连接 apiserver、etcdkarmada-descheduler连接 apiserver、karmada-scheduler-estimatorkarmada-scheduler连接 apiserver、karmada-scheduler-estimatorkarmada-interpreter-webhook连接 apiserverkarmadactl连接 apiserver注karmada-agent 亦作为客户端连接 apiserver属于该体系的覆盖范围。1.3 改造前的证书分配现状服务端组件仅有 apiserver 与本地 etcd 拥有独立证书其余服务端组件共享同一张cnkarmada-admin证书多数组件通过卷挂载volume mount方式将证书载入容器。客户端组件所有连接 apiserver 的客户端组件共享由 karmada-apiserver 签发的交互用客户端证书所有连接 etcd 的客户端组件共享 etcd 签发的 etcd-client 证书所有连接 karmada-scheduler-estimator 的客户端组件共用 karmada-scheduler-estimator 签发的 gRPC 校验证书。1.4 两个特殊场景gRPC 连接场景karmada-scheduler 与 karmada-descheduler 是仅有的通过 gRPC 协议连接 karmada-scheduler-estimator 的组件。此场景下证书仅用于 TLS 加密传输不含身份校验属性其身份校验通过 apiserver 侧证书完成因此这两个组件的 gRPC 证书只需保障通道加密。demo 组件暂缓karmada-interpreter-webhook 目前仍是演示demo组件其证书内容的改造被暂时推迟仅复用既有server/client证书。二、方案目标与边界2.1 Goals预期成果设计一套符合安全建议的 Karmada 证书隔离框架完成为 8 个服务端组件签发不同证书并将证书内容写入对应的证书 Secret完成为 11 个客户端组件签发不同证书并将证书内容写入对应的证书 Secret 或 Config Secret。2.2 Non-Goals明确不做的事由于证书改造对存量生产集群影响显著本次更新仅限使用 hack 脚本的部署方式即hack/deploy-karmada.sh驱动的本地/远程拉起流程生产环境常用的其他部署方式如 karmada-operator、Helm Chart 等保持不变未来视需要可将整体改动同步到其他部署方式。这正是文档将其定位为preliminary experimental update初步实验性更新的原因——证书资源极为敏感需要更多社区测试后再行同步。三、证书生成脚本改造详解3.1 改造前一纸证书走天下原 hack/deploy-karmada.sh 中的证书生成逻辑如下对应改造前流程# Prepare the karmadaAltNames certificate SAN field. karmadaAltNames(*.karmada-system.svc.cluster.local *.karmada-system.svc localhost 127.0.0.1 $(util::get_apiserver_ip_from_kubeconfig ${HOST_CLUSTER_NAME}) ${interpreter_webhook_example_service_external_ip_address}) # 1. First create root CA util::create_signing_certkey ${CERT_DIR} ca karmada client auth,server auth # 2. Create common certificates for servers using root CA util::create_certkey ${CERT_DIR} ca server server ${karmadaAltNames[]} util::create_certkey ${CERT_DIR} ca client system:admin system:masters ${karmadaAltNames[]} util::create_certkey ${CERT_DIR} ca front-proxy-client front-proxy-client ${karmadaAltNames[]} util::create_certkey ${CERT_DIR} ca etcd-server etcd-server ${karmadaAltNames[]} util::create_certkey ${CERT_DIR} ca etcd-client etcd-client ${karmadaAltNames[]} # 3. Create service account key pair util::create_key_pair ${CERT_DIR} sa可以看到改造前的所有证书几乎都灌入了同一个通配符 SAN 集合*.karmada-system.svc.cluster.local且server、etcd-server等证书的 CN 并不具备组件级区分度。3.2 改造后逐组件独立签发改造后的逻辑为每个服务端组件定义独立的 SAN 列表并分别为服务端证书、客户端证书、etcd 客户端证书、gRPC 证书生成独立条目# Prepare the karmadaAltNames certificate SAN field. karmadaAltNames(*.karmada-system.svc.cluster.local *.karmada-system.svc localhost 127.0.0.1 $(util::get_apiserver_ip_from_kubeconfig ${HOST_CLUSTER_NAME}) ${interpreter_webhook_example_service_external_ip_address}) # Define SAN names for each server component karmada_apiserver_alt_names(karmada-apiserver.karmada-system.svc.cluster.local karmada-apiserver.karmada-system.svc localhost 127.0.0.1 $(util::get_apiserver_ip_from_kubeconfig ${HOST_CLUSTER_NAME})) karmada_aggregated_apiserver_alt_names(karmada-aggregated-apiserver.karmada-system.svc.cluster.local karmada-aggregated-apiserver.karmada-system.svc localhost 127.0.0.1) karmada_webhook_alt_names(karmada-webhook.karmada-system.svc.cluster.local karmada-webhook.karmada-system.svc localhost 127.0.0.1) ... # 1. Create root CA util::create_signing_certkey ${CERT_DIR} ca karmada client auth,server auth # 2. Create independent certificates for each server component util::create_certkey ${CERT_DIR} ca karmada-apiserver system:karmada:karmada-apiserver ${karmada_apiserver_alt_names[]} util::create_certkey ${CERT_DIR} ca karmada-aggregated-apiserver system:karmada:karmada-aggregated-apiserver ${karmada_aggregated_apiserver_alt_names[]} util::create_certkey ${CERT_DIR} ca karmada-webhook system:karmada:karmada-webhook ${karmada_webhook_alt_names[]} ... # 3. Create client certificates for components that connect to external components util::create_certkey ${CERT_DIR} ca karmada-apiserver-etcd-client karmada-apiserver util::create_certkey ${CERT_DIR} ca karmada-aggregated-apiserver-etcd-client karmada-aggregated-apiserver ... # 4. Create service account key pair util::create_key_pair ${CERT_DIR} sa3.3 底层签名工具hack/util.sh 中的证书函数生成逻辑依赖 hack/util.sh 中三个核心函数理解它们有助于看懂上面的脚本参数util::create_signing_certkey sudo dest_dir id cn purpose用 openssl 生成自签根 CA写入{id}.crt/{id}.key并生成 cfssl 签名配置{id}-config.json默认有效期 3650 天、RSA 3072 位。util::create_certkey sudo dest_dir ca id cn og hosts...使用 cfssl 以指定 CA 签发证书。参数中id是输出文件名前缀cn是证书 Common Nameog是 Organization写入 Subject 的 O 字段其后所有参数按序拼为 SANhosts。若hosts为空则生成的证书不含 SAN——这正是客户端证书去除不必要 SAN、聚焦身份的实现方式。util::create_key_pair sudo dest_dir name生成 service account 的公私钥对RSA 3072。当前 hack/deploy-karmada.sh 已完整落地该改造服务端证书按组件逐一签发karmada-apiserver、karmada-aggregated-apiserver、karmada-webhook、karmada-search、karmada-metrics-adapter、karmada-scheduler-estimator、etcd-server客户端证书按apiserver 客户端 / etcd 客户端 / gRPC 客户端三类分组签发CN 统一采用system:karmada:组件名命名空间式格式O 字段统一为system:masters。3.4 证书内容写入 Secret生成后的证书与私钥被 base64 编码后通过generate_cert_related_secrets见 hack/deploy-karmada.sh写入 karmada-system 命名空间下的各类 Secret服务端证书 Secret按组件名逐一生成karmada-apiserver-cert、karmada-aggregated-apiserver-cert、karmada-webhook-cert、karmada-search-cert、karmada-metrics-adapter-cert、karmada-scheduler-estimator-cert、etcd-cert等模板为artifacts/deploy/karmada-cert-secret.yamletcd 客户端证书 Secretkarmada-apiserver-etcd-client、karmada-aggregated-apiserver-etcd-client、karmada-search-etcd-client、etcd-etcd-client等gRPC 客户端证书 Secretkarmada-scheduler-scheduler-estimator-client、karmada-descheduler-scheduler-estimator-clientConfig Secretkubeconfig为 karmada-controller-manager、karmada-scheduler、karmada-descheduler、karmada-metrics-adapter、karmada-search、karmada-webhook 等组件使用各自专属客户端证书生成 kubeconfig模板为artifacts/deploy/karmada-config-secret.yaml。四、证书内容变化示例证书内容的修改集中在三处Subject 字段的 CN 与 O 取值SANSubject Alternative Name范围证书用途与权限设置。4.1 服务端证书示例karmada-apiserverCertificate: Issuer: CN karmada Subject: CN system:karmada:karmada-apiserver X509v3 extensions: X509v3 Subject Alternative Name: DNS:karmada-apiserver.karmada-system.svc.cluster.local, DNS:karmada-apiserver.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1, IP Address:172.18.0.2主要改进使用组件专属 CNsystem:karmada:karmada-apiserverSAN 使用精确 DNS 名避免通配符对比改造前所有证书共享*.karmada-system.svc.cluster.local清晰标识组件身份与访问范围。4.2 客户端证书示例karmada-schedulerCertificate: Issuer: CN karmada Subject: O system:masters, CN system:karmada:karmada-scheduler X509v3 extensions: X509v3 Subject Alternative Name:主要改进使用标准化 CN 格式system:karmada:karmada-scheduler移除不必要的 SAN 信息客户端证书无需绑定主机名通过 O 字段清晰标识权限级别system:masters。这些修改带来的整体收益每个组件拥有唯一身份、证书访问范围更精确、权限控制更清晰、符合 Kubernetes 证书最佳实践CN 采用system:前缀以便与 RBAC 用户体系对齐。五、各组件证书格式规范完整参考本节给出每个组件的服务端/客户端证书的推荐 CN 与 SAN 取值、注入方式命令行参数以及该证书的用途说明。以下内容可直接作为审计、生成或校验证书的核对清单。5.1 Karmada API Server服务端证书——用于加密并认证 karmada-apiserver 与客户端之间的通信防止中间人攻击。注入参数--tls-cert-file部署文件见 karmada-apiserver.yaml推荐取值Subject: CNsystem:karmada:karmada-apiserver Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:karmada-apiserver.karmada-system.svc.cluster.local, DNS:karmada-apiserver.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1, IP Address:${apiserver_service_ip_address}ETCD 客户端证书——karmada-apiserver 访问 etcd 数据存储时的身份认证确保只有授权的 apiserver 实例可读写 etcd。注入参数--etcd-certfile配套--etcd-keyfile推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-apiserver-etcd-client Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSEFront Proxy 客户端证书——用于前置代理与 karmada-apiserver 之间的通信认证。在 Karmada 的 API 聚合架构中前置代理负责转发聚合 API Server 的请求该证书保障请求转发过程的安全可信。注入参数--proxy-client-cert-file配套--proxy-client-key-file、--requestheader-client-ca-file并通过--requestheader-allowed-namesfront-proxy-client限定可用的客户端名推荐取值Subject: CNfront-proxy-client Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.2 Karmada Aggregated API Server服务端证书——服务于 Karmada 的 API 聚合层使 API 扩展可以动态挂载到核心 API Server 之上保障聚合 API Server 的身份认证与通信安全。注入参数--tls-cert-file推荐取值Subject: CNsystem:karmada:karmada-aggregated-apiserver Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:karmada-aggregated-apiserver.karmada-system.svc.cluster.local, DNS:karmada-aggregated-apiserver.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1客户端证书——karmada-aggregated-apiserver 以客户端身份访问 karmada-apiserver 时的身份认证。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-aggregated-apiserver Subject Public Key Info: X509v3 extensions: X509v3 Subject Alternative Name:ETCD 客户端证书——karmada-aggregated-apiserver 访问 etcd 存储扩展 API 资源状态时的身份认证。注入参数--etcd-certfile推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-aggregated-apiserver-etcd-client Subject Public Key Info: X509v3 extensions: X509v3 Subject Alternative Name:5.3 Karmada Webhook服务端证书——加密并认证 karmada-webhook 与 karmada-apiserver 之间的通信。karmada-webhook 负责资源校验与准入控制确保对资源的所有操作符合预定规则。注入参数--cert-dir自动从目录读取见 karmada-webhook.yaml推荐取值Subject: CNsystem:karmada:karmada-webhook Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:karmada-webhook.karmada-system.svc.cluster.local, DNS:karmada-webhook.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1客户端证书——karmada-webhook 以客户端身份访问 karmada-apiserver 时的身份认证。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-webhook Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.4 Karmada Search服务端证书——加密并认证 karmada-search 与客户端之间的通信。karmada-search 提供跨集群资源搜索能力。注入参数--tls-cert-file推荐取值Subject: CNsystem:karmada:karmada-search Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:karmada-search.karmada-system.svc.cluster.local, DNS:karmada-search.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1客户端证书——karmada-search 与 karmada-apiserver 之间的通信认证。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-search Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSEETCD 客户端证书——karmada-search 访问 etcd 数据存储时的身份认证。注入参数--etcd-certfile推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-search-etcd-client Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.5 Karmada Metrics Adapter服务端证书——加密并认证 karmada-metrics-adapter 与 karmada-apiserver 之间的通信。metrics-adapter 提供自定义指标 API支撑基于自定义指标的调度与自动扩缩容。注入参数--tls-cert-file推荐取值Subject: CNsystem:karmada:karmada-metrics-adapter Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:karmada-metrics-adapter.karmada-system.svc.cluster.local, DNS:karmada-metrics-adapter.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1客户端证书——karmada-metrics-adapter 与 karmada-apiserver 之间的通信认证。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-metrics-adapter Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.6 Karmada Scheduler Estimator服务端证书——加密并认证 karmada-scheduler-estimator 与 karmada-scheduler、karmada-descheduler 之间的通信。estimator 为调度决策提供集群负载估算。注入参数--grpc-auth-cert-file源码定义见 cmd/scheduler-estimator/app/options/options.goSSL certification file used for grpc SSL/TLS connections推荐取值Subject: CNsystem:karmada:karmada-scheduler-estimator Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:*.karmada-system.svc.cluster.local, DNS:*.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1说明estimator 是 Karmada 中按成员集群部署的组件每个成员集群的 estimator 通过集群内服务名形如karmada-scheduler-estimator-cluster.karmada-system.svc被访问因此该服务端证书保留了*.karmada-system.svc通配 SAN这是文档中列出的唯一保留通配符的服务端证书。5.7 ETCD服务端证书——加密并认证 etcd 服务端与客户端之间的通信。etcd 是 Karmada 的核心数据存储保存全部集群状态该证书是保护敏感数据读写权限的关键。注入参数--key-fileetcd 启动参数证书/私钥文件推荐取值Subject: CNsystem:karmada:etcd-server Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Alternative Name: DNS:etcd.karmada-system.svc.cluster.local, DNS:etcd.karmada-system.svc, DNS:etcd-client.karmada-system.svc.cluster.local, DNS:etcd-client.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1ETCD 客户端证书——用于 etcd 服务的自健康检查与内部通信保障 etcd 服务的可用性。注入方式构建 etcd 容器时在容器内执行如下命令etcdctl get /registry --prefix --keys-only --endpoints https://127.0.0.1:2379 \ --cacert /etc/karmada/pki/etcd-client/ca.crt \ --cert /etc/karmada/pki/etcd-client/tls.crt \ --key /etc/karmada/pki/etcd-client/tls.key推荐取值Subject: CNsystem:karmada:etcd-etcd-client Subject Public Key Info: X509v3 extensions: X509v3 Subject Alternative Name:5.8 Karmada Controller Manager客户端证书——karmada-controller-manager 与 karmada-apiserver 之间的通信认证。controller-manager 内含多个控制循环负责维护集群期望状态该证书保障控制器与 apiserver 之间读写资源状态的安全性。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-controller-manager Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.9 Karmada Scheduler客户端证书——karmada-scheduler 与 karmada-apiserver 之间的通信认证。scheduler 负责决定资源分配到哪些成员集群是多集群管理的核心组件。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-scheduler Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSEGRPC 证书——加密并认证 karmada-scheduler 与 karmada-scheduler-estimator 之间的 gRPC 通信scheduler 通过该通道获取集群负载估算信息。注入参数--scheduler-estimator-cert-file源码定义见 cmd/scheduler/app/options/options.goSSL certification file used to secure scheduler estimator communication推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-scheduler-grpc Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE5.10 Karmada Descheduler客户端证书——karmada-descheduler 与 karmada-apiserver 之间的通信认证。descheduler 通过重新调度优化既有资源分配提升集群整体效率。注入参数通过包含证书的--kubeconfig传入推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-descheduler Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSEGRPC 证书——加密并认证 karmada-descheduler 与 karmada-scheduler-estimator 之间的 gRPC 通信descheduler 通过该通道获取集群负载信息用于调度决策。注入参数--scheduler-estimator-cert-file推荐取值Subject: Osystem:masters, CNsystem:karmada:karmada-descheduler-grpc Subject Public Key Info: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE六、与仓库现状的对照方案已落地于 hack 脚本值得说明的是本提案并非停留在纸面当前仓库的 hack/deploy-karmada.sh 已按上述设计实现了整套证书生成逻辑可作为方案的参考实现来对照学习根 CA 创建util::create_signing_certkey ${CERT_DIR} ca karmada client auth,server auth服务端证书8 个组件karmada-apiserver、karmada-aggregated-apiserver、karmada-webhook、karmada-search、karmada-metrics-adapter、karmada-scheduler-estimator、etcd-server外加保留的通用server证书供 interpreter-webhook 等示例组件使用客户端证书连接 apiserverkarmada-apiserver-client、karmada-aggregated-apiserver-client、karmada-webhook-client、karmada-search-client、karmada-metrics-adapter-client、karmada-scheduler-estimator-client、karmada-controller-manager-client、karmada-scheduler-client、karmada-descheduler-clientetcd 客户端证书karmada-apiserver-etcd-client、karmada-aggregated-apiserver-etcd-client、karmada-search-etcd-client、etcd-clientgRPC 客户端证书karmada-scheduler-grpc、karmada-descheduler-grpcfront proxy 证书front-proxy-clientservice account 密钥对sa。各组件的部署清单artifacts/deploy/*.yaml也已切换为按组件挂载独立 Secret 并注入对应启动参数例如karmada-apiserver.yaml--etcd-certfile/etc/karmada/pki/etcd-client/tls.crt、--proxy-client-cert-file/etc/karmada/pki/front-proxy-client/tls.crt、--requestheader-allowed-namesfront-proxy-client、--tls-cert-file/etc/karmada/pki/server/tls.crtkarmada-aggregated-apiserver.yaml--etcd-certfile与--tls-cert-file指向各自的 etcd-client 与 server 挂载点karmada-scheduler.yaml 与 karmada-descheduler.yaml--scheduler-estimator-cert-file/etc/karmada/pki/scheduler-estimator-client/tls.crtkarmada-scheduler-estimator.yaml--grpc-auth-cert-file/etc/karmada/pki/server/tls.crtkarmada-search.yaml 与 karmada-metrics-adapter.yaml--tls-cert-file、--etcd-certfile按组件挂载。由于证书是敏感资源当前落地范围仅覆盖 hack 脚本部署路径local-up / remote-up 等生产环境中使用 Helm Chartcharts/karmada或 karmada-operatoroperator部署时证书管理仍沿用各自的既有实现读者在两类部署方式之间切换时需注意证书体系差异。七、验证与排障建议部署完成后可以用以下方式核验证书是否已按本方案生成# 查看 Karmada apiserver 使用的服务端证书内容 openssl x509 -in /etc/karmada/pki/karmada-apiserver.crt -text -noout # 查看 etcd 客户端证书 openssl x509 -in /etc/karmada/pki/karmada-apiserver-etcd-client.crt -text -noout # 在运行中的 Pod 内验证挂载的证书 kubectl -n karmada-system exec -it deploy/karmada-controller-manager -- \ openssl x509 -in /etc/karmada/pki/server/tls.crt -text -noout重点检查项Subject.CN 是否唯一每个组件证书的 CN 应形如system:karmada:组件名互不重复SAN 范围服务端证书应只包含本组件的精确服务 DNS 名与必要 IP不出现无关通配符客户端证书原则上无 SANO 字段面向 apiserver 的客户端证书 O 为system:masters与 RBAC 中system:masters组的超级权限语义一致根 CA 一致性所有证书的 Issuer 均为CN karmada根 CA保证控制面内互信。八、小结Karmada 组件证书内容标准化方案以单一根 CA 逐组件独立证书为核心通过统一system:karmada:命名空间式 CN、收紧 SAN 范围、按用途拆分服务端/客户端/etcd/gRPC 证书从根本上解决了共享证书带来的身份混淆与最小权限违背问题。该方案已在 hack/deploy-karmada.sh 中形成参考实现文档第五节给出的各组件证书规范可直接作为证书生成、轮换与审计的核对依据。对于 karmadactl、karmada-agent 等证书相关链路如 pkg/controllers/certificate/approver/agent_csr_approving.go后续可继续在本框架内演进并最终同步至 karmada-operator 与 Helm 等生产部署路径。【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考