网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载本文围绕 Calico 仓库中 hack/test/certs/README.md 所描述的 FVFeature Validation测试证书目录展开系统讲解这套仅用于测试环境的 Kubernetes PKI 证书体系——包括根 CA、admin 客户端证书、API Server 证书与 Service Account 密钥的生成逻辑regenerate.sh、cfssl 签名配置、两类 kubeconfig 的差异以及证书最终如何被挂载进 Felix FV 测试中临时启动的 kube-apiserver 容器。读完本文你将掌握 Calico FV 测试 TLS 基础设施的完整链路并能在本地复现证书再生成流程。FV 证书的作用与适用场景根据 hack/test/certs/README.md 的说明该目录下的全部密钥与证书仅在当前仓库的 FV 测试中使用并且是按照开源社区广泛流传的 Kubernetes the Hard Way 教程的步骤生成的。这意味着它并非生产环境制品而是一套为测试用例临时拉起真实 kube-apiserver 而准备的信任链。FV 测试之所以需要完整 PKI是因为 Felix 的数据面测试见 felix/fv/infrastructure/infra_k8s.go会在容器内启动一个真实的 kube-apiserver 与 kube-controller-manager用于验证 Calico 与 Kubernetes 的集成行为。API Server 需要 TLS 证书对外提供 HTTPS 服务控制器需要 Service Account 密钥完成 SA Token 签发客户端则需要合法证书访问 API——目录中每一份材料都对应测试链路上的一个角色。目录完整内容如下文件角色ca.pem/ca-key.pem根 CA 证书与私钥签发链的信任锚点ca-config.json/ca-csr.jsoncfssl 的签名策略配置与 CA 证书签名请求admin.pem/admin-key.pemadmin 客户端证书Osystem:masterskubernetes.pem/kubernetes-key.pemAPI Server 服务端证书含 SANservice-account.pem/service-account-key.pemService Account 签名密钥对admin-csr.json/kubernetes-csr.json/service-account-csr.json各证书的 CSR 定义kubeconfigadmin 用户访问测试 API Server 的客户端配置kube-controller-manager.kubeconfig控制器访问 API Server 的配置证书内嵌regenerate.sh一键再生成全部密钥与证书的脚本证书信任链架构一个 CA 派生全部凭证从目录中四组 CSR 与证书可以清晰看出整套体系采用单一根 CA 多角色证书的经典结构根 CACNKubernetes由ca-csr.json定义regenerate.sh通过cfssl gencert -initca初始化是所有下级证书的签发者admin 客户端证书CNadminadmin-csr.json中Osystem:masters使该证书具备集群管理员权限用于 FV 测试中 kubectl 对 API Server 的读写操作kubernetes 服务端证书CNkubernetes同时充当 API Server 的服务端证书其 SAN 覆盖10.96.0.1集群 Service IP、127.0.0.1及一组kubernetes.default域名确保容器内外的多种访问方式都能通过 TLS 校验service-account 密钥对CNservice-accounts用于 kube-controller-manager 签发/校验 ServiceAccount Token是测试集群内 Pod 身份认证的基础。其中kubernetes-csr.json的 CN 与 SAN 设计值得注意KUBERNETES_HOSTNAMES变量见 regenerate.sh覆盖了kubernetes、kubernetes.default、kubernetes.default.svc、kubernetes.default.svc.cluster与kubernetes.svc.cluster.local五个主机名这些正是 kube-apiserver 以 Service 形式暴露时客户端可能使用的 DNS 名称。cfssl 签名策略与 CSR 配置逐项解析签名策略ca-config.json{ signing: { default: { expiry: 87600h }, profiles: { kubernetes: { usages: [signing, key encipherment, server auth, client auth], expiry: 87600h } } } }该配置定义了一个名为kubernetes的签名 profile核心参数含义expiry: 87600h证书有效期 10 年87600 小时测试证书无需频繁轮换usages同时包含server auth与client auth使同一把kubernetes证书既能充当服务端证书也能作为客户端证书复用这是测试环境的务实做法signing与key encipherment允许证书用于签名与密钥封装满足 API Server 的 TLS 握手需求。CSR 公共字段四份 CSRca-csr.json、admin-csr.json、kubernetes-csr.json、service-account-csr.json的密钥参数一致rsa算法、2048位长度组织信息统一为CUS, LPortland, STOregon, OKubernetes, OUCAadmin 证书的 OU 为Kubernetes The Hard Way。差异集中在CN与OCSRCNO组织用途ca-csr.jsonKubernetesKubernetes根 CA 自身admin-csr.jsonadminsystem:masters管理员客户端kubernetes-csr.jsonkubernetesKubernetesAPI Server 服务端service-account-csr.jsonservice-accountsKubernetesSA Token 签名admin证书的Osystem:masters是关键设计kube-apiserver 默认将system:masters组映射为超级管理员测试中的 kubectl 操作因此无需额外 RBAC 配置。一键再生成regenerate.sh 完整流程README 明确指出要重新生成证书运行./regenerate.sh该脚本会彻底删除并重建全部密钥与证书包括根 CA。完整脚本内容如下regenerate.sh#!/bin/bash set -xe rm -f *.pem *.key *.csr cfssl gencert -initca ca-csr.json | cfssljson -bare ca cfssl gencert \ -caca.pem \ -ca-keyca-key.pem \ -configca-config.json \ -profilekubernetes \ admin-csr.json | cfssljson -bare admin KUBERNETES_HOSTNAMESkubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.svc.cluster.local cfssl gencert \ -caca.pem \ -ca-keyca-key.pem \ -configca-config.json \ -hostname10.96.0.1,127.0.0.1,${KUBERNETES_HOSTNAMES} \ -profilekubernetes \ kubernetes-csr.json | cfssljson -bare kubernetes cfssl gencert \ -caca.pem \ -ca-keyca-key.pem \ -configca-config.json \ -profilekubernetes \ service-account-csr.json | cfssljson -bare service-account kubectl config set-credentials system:kube-controller-manager \ --client-certificateadmin.pem \ --client-keyadmin-key.pem \ --embed-certstrue \ --kubeconfigkube-controller-manager.kubeconfig rm *.csr脚本执行顺序与关键点清场rm -f *.pem *.key *.csr删除当前目录全部旧制品保证每次再生成都是全新信任链根 CA 也会重建因此旧证书立即全部失效生成根 CAcfssl gencert -initca ca-csr.json | cfssljson -bare ca产出ca.pem与ca-key.pem签发 admin 证书使用-profilekubernetes签名策略产出admin.pem与admin-key.pem签发 kubernetes 证书这是唯一带-hostname参数的一步SAN 列表由10.96.0.1,127.0.0.1与KUBERNETES_HOSTNAMES拼接而成10.96.0.1对应 kube-apiserver 的 ClusterIP 段127.0.0.1对应本地回环访问签发 service-account 证书与 admin 相同仅用 CSR 与 profile生成控制器 kubeconfig用kubectl config set-credentials将 admin 证书内嵌--embed-certstrue写入kube-controller-manager.kubeconfigsystem:kube-controller-manager是 Kubernetes 内置的系统用户名收尾删除所有中间.csr文件。环境依赖方面脚本依赖cfssl/cfssljson与kubectl两个命令行工具且默认假设在hack/test/certs目录内执行set -xe保证出错即停、输出执行过程。执行后再生成时只要测试基础设施按同一路径挂载新证书见下文FV 测试即可继续工作。两类 kubeconfig 的差异与设计意图目录中的两份 kubeconfig 形态完全不同值得对比理解。admin 版 kubeconfigkubeconfigapiVersion: v1 clusters: - cluster: insecure-skip-tls-verify: true server: https://127.0.0.1:6443 name: test-apiserver contexts: - context: cluster: test-apiserver user: admin name: admin current-context: admin kind: Config users: - name: admin user: # The tests which use this kubeconfig are run in a container # and expect these files to be mounted at this location. client-certificate: /home/user/certs/admin.pem client-key: /home/user/certs/admin-key.pem要点server: https://127.0.0.1:6443指向测试容器内 kube-apiserver 的标准监听地址证书以文件路径引用方式配置且注释明确指出使用该 kubeconfig 的测试运行在容器中期望证书被挂载到/home/user/certs这一固定位置开启insecure-skip-tls-verify: true因为测试环境为临时集群跳过对 API Server 证书链的校验可简化故障排查。控制器版 kubeconfigkube-controller-manager.kubeconfig与 admin 版不同这份 kubeconfig 通过kubectl config set-credentials --embed-certstrue生成client-certificate-data与client-key-data两个字段中直接内嵌了 Base64 编码的证书与私钥无需外部文件server字段为空字符串实际访问地址由测试基础设施在启动控制器时另行指定。两种形态对应两种使用环境admin kubeconfig 供测试容器内手动执行的 kubectl 命令使用文件挂载即可控制器 kubeconfig 则因 kube-controller-manager 由测试框架以容器参数方式拉起内嵌证书可避免额外的挂载编排。证书在 FV 测试中的实际挂载链路证书最终价值的体现点在 felix/fv/infrastructure/infra_k8s.go该文件是 Felix FV 测试的 Kubernetes 基础设施封装从源码结构可以看到完整的挂载与消费关系统一挂载点通过-v $CERTS_PATH:/home/user/certsCERTS_PATH为环境变量将证书目录整体挂载进 kube-apiserver、kube-controller-manager 与客户端容器与 kubeconfig 中的/home/user/certs路径一一对应API Server 消费--service-account-key-file/home/user/certs/service-account.pem、--service-account-signing-key-file/home/user/certs/service-account-key.pem、--client-ca-file/home/user/certs/ca.pem、--tls-cert-file/home/user/certs/kubernetes.pem、--tls-private-key-file/home/user/certs/kubernetes-key.pem——即用kubernetes.pem对外提供 TLS 服务、用ca.pem校验客户端证书、用service-account密钥对完成 SA Token 的签发kube-controller-manager 消费--kubeconfig/home/user/certs/kube-controller-manager.kubeconfig与--root-ca-file/home/user/certs/ca.pem、--service-account-private-key-file/home/user/certs/service-account-key.pem控制器据此访问 API Server 并签发 SA Token客户端消费测试中的 kubectl 通过--kubeconfig/home/user/certs/kubeconfig apply -f /crds/等命令应用 CRD 清单其身份凭证正是admin.pem与admin-key.pemTLS 校验方向kubernetes.pem还会被复制进客户端容器kubernetes.pem作为 CA 信任链上传确保客户端到 API Server 的 HTTPS 连接可完成证书链验证。由此可以完整还原测试链路根 CA 签发三张证书 → 证书以目录挂载形式进入各测试容器 → kube-apiserver 用 kubernetes 证书对外服务、用 ca.pem 校验 admin 客户端 → admin 证书驱动 kubectl 操作 → service-account 密钥对支撑控制器签发 SA Token四个角色各司其职、缺一不可。再生成时的注意事项运行./regenerate.sh会连同根 CA 一起删除重建因此这是推倒重来式的操作而不是增量轮换再生成后所有依赖旧证书的已运行容器需重新拉起脚本使用set -xe任何一步失败都会立即终止可通过执行日志快速定位是 cfssl 配置问题还是工具缺失再生成后需确保$CERTS_PATH指向新证书目录且挂载路径仍为/home/user/certs否则 kubeconfig 中引用的绝对路径将失效由于ca-config.json中expiry长达 87600 小时10 年日常开发中该目录极少需要再生成README 提供该脚本的意义更多在于保证证书来源可追溯、可重建避免仓库内长期滞留无法再生的测试密钥。综上Calico 的 FV 证书目录是一个小而完整的 PKI 实践样本它用 cfssl 完成单 CA 多角色证书的标准化签发用两种 kubeconfig 适配容器化测试的两种消费方式并在infra_k8s.go中形成了目录挂载 启动参数的确定性交付链路。理解这套体系不仅能看懂 Calico FV 测试的 TLS 握手过程也能为其他需要自建测试集群 PKI 的项目提供直接可复用的参考模板。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐EMQX 测试基础设施中的 TLS 证书体系docker-compose 测试服务证书的生成、命名与维护EMQX 测试基础设施中的 TLS 证书体系docker compose 测试服务证书的生成、命名与维护 本篇技术指南聚焦 EMQX 开源仓库中为 docke后端物联网消息队列通信Lore 服务端 mTLS 测试证书体系test_data 目录与 QUIC 安全测试基础设施Lore 服务端 mTLS 测试证书体系test_data 目录与 QUIC 安全测试基础设施 本文围绕 Lore 仓库中的测试证书目录 lore serve版本控制后端Recommenders 测试体系深度解析从 PR Gate 到 Nightly Build 的 MLOps 测试基础设施Recommenders 测试体系深度解析从 PR Gate 到 Nightly Build 的 MLOps 测试基础设施 Recommenders 是微软开人工智能机器学习深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考