agents 插件仓库 mTLS 配置技能实战Istio、Linkerd 与 SPIFFE 模板及运维命令全解【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南以 agents 仓库中 cloud-infrastructure 插件的 mtls-configuration 技能 所附的 references/details.md 为骨架展开它是实现零信任服务间通信时直接可复制的模板库与运维手册。读完你将掌握如何用 Istio PeerAuthentication/DestinationRule 逐步收紧 mTLS、用 cert-manager 托管工作负载证书、集成 SPIFFE/SPIRE 下发动态身份以及 Linkerd 下零配置启用 mTLS 的完整命令集。这份 reference 文档在技能体系中的定位本仓库将技能内容拆分为「导航 深度细节」两层详见 docs/authoring.mdSKILL.md负责说明技能何时触发与核心概念真正的大段模板与完整示例放在references/details.md中由 Agent 在需要具体配置时按需读取——这既能满足 Codex 等 harness 对 SKILL.md 正文 8 KB 的硬性截断要求也让每个 harness 都能共享同一份权威细节。mtls-configuration 技能在前置元数据中声明了典型触发场景实施零信任网络zero-trust networking加固服务到服务service-to-service通信证书轮换与生命周期管理排查 TLS 握手问题满足合规要求PCI-DSS、HIPAA多集群安全通信docs/agent-skills.md 将其归类为「设计零信任 mTLS 架构与证书管理」类技能在实际调用上它与仓库中的 service-mesh-expert 专家 Agentopus 级以及 istio-traffic-management、linkerd-patterns、service-mesh-observability 等兄弟技能协同共同覆盖服务网格从安全到流量再到可观测的完整闭环。核心概念速览SKILL.md 用一张握手时序图概括了 mTLS 的本质在服务双方的 sidecar 代理之间完成五次交互——ClientHello→ServerHello 证书→客户端证书→双向校验证书→建立加密信道。与传统 TLS 只验证服务器身份不同mTLS 要求两端都出示由受信 CA 签发的证书链路身份由工作负载的 SPIFFE ID 承载。同时它定义了一个清晰的证书层级自签名的长期 Root CA → 集群级 Intermediate CA → 各工作负载证书多集群场景下还有跨集群的 Intermediate CA。理解这个层级是理解后文 cert-manager 与 SPIRE 各司其职的前提。Template 1Istio 网格级 PeerAuthenticationSTRICT 模式完整模板位于 references/details.md按「网格 → 命名空间 → 工作负载 → 端口」四级粒度逐层覆盖# Enable strict mTLS mesh-wide apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT --- # Namespace-level override (permissive for migration) apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: legacy-namespace spec: mtls: mode: PERMISSIVE --- # Workload-specific policy apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: payment-service namespace: production spec: selector: matchLabels: app: payment-service mtls: mode: STRICT portLevelMtls: 8080: mode: STRICT 9090: mode: DISABLE # Metrics port, no mTLS解读要点策略选择器优先级Istio 中的 PeerAuthentication 名称必须为default且不带selector时才会作为命名空间/网格级策略生效。网格级策略放在istio-system命名空间该命名空间受网格信任命名空间级策略覆盖网格级带selector的工作负载级策略优先级最高。端口级控制portLevelMtls当同一工作负载暴露多个端口、而其中只有部分是业务流量时可将指标端口如 Prometheus 拉取的 9090显式置为DISABLE避免为纯遥测流量引入不必要的双向认证负担。PERMISSIVE 用于迁移这是最佳实践「先 PERMISSIVE、后 STRICT」落地的关键机制。PERMISSIVE 模式同时接受明文与 mTLS 流量适合渐进式迁移窗口期等网格内全部端点接入后收紧为 STRICT。Template 2DestinationRule 控制「到目的地」的 TLS 模式如果说 PeerAuthentication 决定「服务端是否强制要求 mTLS」那么 DestinationRule 中的trafficPolicy.tls决定「客户端侧边车出站时以什么 TLS 模式加密」。模板覆盖了网格内、外部明文 TLS、外部双向 TLS 三类出口场景apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: default namespace: istio-system spec: host: *.local trafficPolicy: tls: mode: ISTIO_MUTUAL --- # TLS to external service apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: external-api spec: host: api.external.com trafficPolicy: tls: mode: SIMPLE caCertificates: /etc/certs/external-ca.pem --- # Mutual TLS to external service apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: partner-api spec: host: api.partner.com trafficPolicy: tls: mode: MUTUAL clientCertificate: /etc/certs/client.pem privateKey: /etc/certs/client-key.pem caCertificates: /etc/certs/partner-ca.pem需要特别注意的三种模式差异TLS mode适用对象额外配置ISTIO_MUTUAL网格内服务无需指定证书Istio 自动注入工作负载证书SIMPLE单向 TLS 的外部 APIcaCertificates指向外部 CA 公钥MUTUAL需要双向认证的外部伙伴服务需同时提供clientCertificate、privateKey、caCertificates三件套网格级host: *.localISTIO_MUTUAL的写法配合 Template 1 的 STRICT PeerAuthentication是「全网格强制双向加密」的黄金组合一个约束服务端准入一个约束客户端出站。Template 3用 cert-manager 打通工作负载证书的签发与轮换Istio 自带基于 Citadel/istiod 的 CA 可覆盖大部分网格内场景但当你需要把工作负载证书纳入统一 PKI例如既服务网格内、也服务集群外应用时cert-manager 是更可控的选项。模板给出三层资源# Install cert-manager issuer for Istio apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: istio-ca spec: ca: secretName: istio-ca-secret --- # Create Istio CA secret apiVersion: v1 kind: Secret metadata: name: istio-ca-secret namespace: cert-manager type: kubernetes.io/tls data: tls.crt: base64-encoded-ca-cert tls.key: base64-encoded-ca-key --- # Certificate for workload apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: my-service-cert namespace: my-namespace spec: secretName: my-service-tls duration: 24h renewBefore: 8h issuerRef: name: istio-ca kind: ClusterIssuer commonName: my-service.my-namespace.svc.cluster.local dnsNames: - my-service - my-service.my-namespace - my-service.my-namespace.svc - my-service.my-namespace.svc.cluster.local usages: - server auth - client auth参数设计要点ClusterIssuerca.secretNamecert-manager 直接以自签 CA 的根证书签发证书istio-ca-secret中以tls.crt/tls.key承载 CA 密钥对kubernetes.io/tls类型值需 base64 编码。duration: 24h/renewBefore: 8h工作负载证书建议短生命周期技能最佳实践要求 24h 或更短到期前 8 小时自动续期将「证书过期」从事故源变成例行后台事件。commonName与dnsNamesCN 使用完整 FQDNmy-service.my-namespace.svc.cluster.localSAN 从短名一直覆盖到完整 FQDN确保网格内外按不同寻址方式访问都能校验通过。usages同时声明server auth与client auth这是 mTLS 证书与普通 Web 证书的关键差异——同一张工作负载证书既要证明自己是服务端又要作为客户端身份出示。Template 4SPIFFE/SPIRE 下发动态工作负载身份当安全边界需要跨越集群、甚至跨越 Kubernetes虚机、裸机、多云时SPIRE 通过 SPIFFE 标准提供不依赖固定 ServiceAccount 令牌的短时 X.509 SVID。模板包含 SPIRE Server 配置与 Agent DaemonSet 两部分# SPIRE Server configuration apiVersion: v1 kind: ConfigMap metadata: name: spire-server namespace: spire data: server.conf: | server { bind_address 0.0.0.0 bind_port 8081 trust_domain example.org data_dir /run/spire/data log_level INFO ca_ttl 168h default_x509_svid_ttl 1h } plugins { DataStore sql { plugin_data { database_type sqlite3 connection_string /run/spire/data/datastore.sqlite3 } } NodeAttestor k8s_psat { plugin_data { clusters { demo-cluster { service_account_allow_list [spire:spire-agent] } } } } KeyManager memory { plugin_data {} } UpstreamAuthority disk { plugin_data { key_file_path /run/spire/secrets/bootstrap.key cert_file_path /run/spire/secrets/bootstrap.crt } } } --- # SPIRE Agent DaemonSet (abbreviated) apiVersion: apps/v1 kind: DaemonSet metadata: name: spire-agent namespace: spire spec: selector: matchLabels: app: spire-agent template: spec: containers: - name: spire-agent image: ghcr.io/spiffe/spire-agent:1.8.0 volumeMounts: - name: spire-agent-socket mountPath: /run/spire/sockets volumes: - name: spire-agent-socket hostPath: path: /run/spire/sockets type: DirectoryOrCreate配置中的关键参数含义trust_domainSPIFFE 身份命名空间的根例如example.org最终下发的工作负载 SVID 形如spiffe://example.org/ns/ns/sa/sa。ca_ttl: 168h与default_x509_svid_ttl: 1hServer 自身 CA 的有效期7 天远大于下发给工作负载的 SVID 有效期1 小时保证身份高频轮换、泄露窗口极小。NodeAttestork8s_psat利用 Kubernetes 的 Projected Service Account TokenPSAT作为节点证明机制service_account_allow_list只放行spire:spire-agent这个 SA防止任意 Pod 冒认节点身份。UpstreamAuthoritydiskSPIRE Server 向上游 CA 申请自身证书bootstrap.key/crt是信任链的起点生产环境通常将其替换为与 Vault 等对接的权威上游。Agent DaemonSet以 hostPath 挂载共享 socket 目录/run/spire/socketsAgent 每节点一个通过该 Unix socket 向同节点工作负载下发 SVID因此工作负载无需持有任何静态密钥。Template 5Linkerd 的「零配置」mTLS与 Istio 需要显式编排 PeerAuthentication DestinationRule 不同Linkerd 在注入 sidecar 的同时自动为网格内流量启用 mTLS——它内置的 identity 组件为每个工作负载颁发证书开发者无需编写任何安全策略即可获得全网格双向加密。因此模板的重点放在两个「例外处理」上# Linkerd enables mTLS automatically # Verify with: # linkerd viz edges deployment -n my-namespace # For external services without mTLS apiVersion: policy.linkerd.io/v1beta1 kind: Server metadata: name: external-api namespace: my-namespace spec: podSelector: matchLabels: app: my-app port: external-api proxyProtocol: HTTP/1 # or TLS for passthrough --- # Skip TLS for specific port apiVersion: v1 kind: Service metadata: name: my-service annotations: config.linkerd.io/skip-outbound-ports: 3306 # MySQLServerpolicy.linkerd.io/v1beta1用于声明某个端口的服务端策略与协议配合 ServerAuthorization 可以按服务账号做细粒度放行此处典型场景是把无法参与 mTLS 的外部 API 端口的协议显式声明出来。config.linkerd.io/skip-outbound-ports: 3306Linkerd 默认代理所有 TCP 出站对不支持 TLS 的协议如 MySQL需要用它跳过代理加密否则直连会被链路层握手破坏。验证手段始终是linkerd viz edges deployment -n my-namespace它会列出每条边的tlstrue/false状态。证书轮换操作手册模板库为两条主链路分别提供了轮换手段命令位于 references/details.md# Istio - Check certificate expiry istioctl proxy-config secret deploy/my-app -o json | \ jq .dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes | \ tr -d | base64 -d | openssl x509 -text -noout # Force certificate rotation kubectl rollout restart deployment/my-app # Check Linkerd identity linkerd identity -n my-namespace逐条拆解检视 Istio 证书有效期istioctl proxy-config secret导出 Envoy 动态密钥状态用jq取首个动态密钥的证书链 base64 负载base64 -d还原 DER 后再交给openssl x509输出明文证书信息即可读到 Not Before / Not After 字段用于判断是否需要人工干预轮换。强制轮换由于 Istio 证书绑定工作负载 Podkubectl rollout restart deployment/my-app重启后新 Pod 会从 istiod 请求全新的短期证书——这也从侧面印证了「短证书 重启即换新」的零信任运维模式。Linkerd identity 校验linkerd identity直接展示当前工作负载的 SPIFFE 身份与证书链快速确认注入与身份签发是否正常。调试 mTLS 问题的命令集当流量不通、握手失败或策略未生效时模板按「Istio 双向认证链」与「Linkerd 可视化」给出了成体系的排查路径# Istio - Check if mTLS is enabled istioctl authn tls-check my-service.my-namespace.svc.cluster.local # Verify peer authentication kubectl get peerauthentication --all-namespaces # Check destination rules kubectl get destinationrule --all-namespaces # Debug TLS handshake istioctl proxy-config log deploy/my-app --level debug kubectl logs deploy/my-app -c istio-proxy | grep -i tls # Linkerd - Check mTLS status linkerd viz edges deployment -n my-namespace linkerd viz tap deploy/my-app --to deploy/my-backend排查思路建议按以下顺序推进策略是否生效istioctl authn tls-check会对目标服务名给出当前生效的 mTLS 模式与依据策略随后用kubectl get列出全集群的 PeerAuthentication 与 DestinationRule重点检查是否存在高优先级策略覆盖了你以为生效的宽松/严格配置对应 Template 1 的四级选择器规则。握手是否失败把 istio-proxy 日志级别打到debug并 grep TLS 关键字定位握手在哪个阶段中断证书不信任、SNI 不匹配还是客户端证书缺失。链路可视化Linkerd 一侧则用linkerd viz edges看全链路每一条边的 mTLS 启用状态用linkerd viz tap实时抓取my-app到my-backend之间的流量做行为级确认。落地建议与反模式将 details.md 与 SKILL.md 的最佳实践合并得到可直接作为团队基线的一组 Do/Dont应当遵循Dos从 PERMISSIVE 起步先放行明文 mTLS 并存度量升级影响后再收紧为 STRICT避免一次性切换导致全网断连。监控证书到期为工作负载证书与 CA 建立到期告警配合 Template 3 的renewBefore。使用短生命周期证书工作负载证书控制在 24 小时以内Istio 默认即约 24hSPIRE 示例中 SVID 仅 1 小时缩短泄露后的可利用窗口。周期性轮换 CA提前规划 Root/Intermediate CA 的轮换流程避免 CA 临近过期时才被动处理。记录 TLS 错误日志既服务排障也是合规审计的证据来源。务必避免Donts不为运维便利在生产环境关闭 mTLS——那将把整个零信任模型打回「网络信任」。不忽视证书到期——轮换必须自动化人工盯守必然遗漏。不使用自签名证书替代正规 CA 层级——回到 SKILL.md 中 Root CA → Intermediate CA → Workload Cert 的结构化设计。不跳过完整证书链校验——服务端证书即便受信也必须校验证书链每一环与身份绑定。延伸阅读本模板库是 cloud-infrastructure 插件服务网格安全能力的一环如需继续深入可查看同仓库中以下材料mtls-configuration 技能入口 SKILL.md——mTLS 握手流程、证书层级图与技能触发条件service-mesh-expert 专家 Agent——负责 mTLS 策略设计、证书管理与网格拓扑编排的 opus 级 Agentistio-traffic-management 技能——与 mTLS 配套的 VirtualService、DestinationRule 流量编排模板linkerd-patterns 技能——Linkerd 注入、Server/ServerAuthorization 与多集群的完整模式service-mesh-observability 技能——对 mesh 流量与身份做可观测性收尾docs/agent-skills.md 与 docs/agents.md——技能与 Agent 的全量索引【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agents 插件仓库 mTLS 配置技能实战：Istio、Linkerd 与 SPIFFE 模板及运维命令全解
agents 插件仓库 mTLS 配置技能实战Istio、Linkerd 与 SPIFFE 模板及运维命令全解【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南以 agents 仓库中 cloud-infrastructure 插件的 mtls-configuration 技能 所附的 references/details.md 为骨架展开它是实现零信任服务间通信时直接可复制的模板库与运维手册。读完你将掌握如何用 Istio PeerAuthentication/DestinationRule 逐步收紧 mTLS、用 cert-manager 托管工作负载证书、集成 SPIFFE/SPIRE 下发动态身份以及 Linkerd 下零配置启用 mTLS 的完整命令集。这份 reference 文档在技能体系中的定位本仓库将技能内容拆分为「导航 深度细节」两层详见 docs/authoring.mdSKILL.md负责说明技能何时触发与核心概念真正的大段模板与完整示例放在references/details.md中由 Agent 在需要具体配置时按需读取——这既能满足 Codex 等 harness 对 SKILL.md 正文 8 KB 的硬性截断要求也让每个 harness 都能共享同一份权威细节。mtls-configuration 技能在前置元数据中声明了典型触发场景实施零信任网络zero-trust networking加固服务到服务service-to-service通信证书轮换与生命周期管理排查 TLS 握手问题满足合规要求PCI-DSS、HIPAA多集群安全通信docs/agent-skills.md 将其归类为「设计零信任 mTLS 架构与证书管理」类技能在实际调用上它与仓库中的 service-mesh-expert 专家 Agentopus 级以及 istio-traffic-management、linkerd-patterns、service-mesh-observability 等兄弟技能协同共同覆盖服务网格从安全到流量再到可观测的完整闭环。核心概念速览SKILL.md 用一张握手时序图概括了 mTLS 的本质在服务双方的 sidecar 代理之间完成五次交互——ClientHello→ServerHello 证书→客户端证书→双向校验证书→建立加密信道。与传统 TLS 只验证服务器身份不同mTLS 要求两端都出示由受信 CA 签发的证书链路身份由工作负载的 SPIFFE ID 承载。同时它定义了一个清晰的证书层级自签名的长期 Root CA → 集群级 Intermediate CA → 各工作负载证书多集群场景下还有跨集群的 Intermediate CA。理解这个层级是理解后文 cert-manager 与 SPIRE 各司其职的前提。Template 1Istio 网格级 PeerAuthenticationSTRICT 模式完整模板位于 references/details.md按「网格 → 命名空间 → 工作负载 → 端口」四级粒度逐层覆盖# Enable strict mTLS mesh-wide apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT --- # Namespace-level override (permissive for migration) apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: legacy-namespace spec: mtls: mode: PERMISSIVE --- # Workload-specific policy apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: payment-service namespace: production spec: selector: matchLabels: app: payment-service mtls: mode: STRICT portLevelMtls: 8080: mode: STRICT 9090: mode: DISABLE # Metrics port, no mTLS解读要点策略选择器优先级Istio 中的 PeerAuthentication 名称必须为default且不带selector时才会作为命名空间/网格级策略生效。网格级策略放在istio-system命名空间该命名空间受网格信任命名空间级策略覆盖网格级带selector的工作负载级策略优先级最高。端口级控制portLevelMtls当同一工作负载暴露多个端口、而其中只有部分是业务流量时可将指标端口如 Prometheus 拉取的 9090显式置为DISABLE避免为纯遥测流量引入不必要的双向认证负担。PERMISSIVE 用于迁移这是最佳实践「先 PERMISSIVE、后 STRICT」落地的关键机制。PERMISSIVE 模式同时接受明文与 mTLS 流量适合渐进式迁移窗口期等网格内全部端点接入后收紧为 STRICT。Template 2DestinationRule 控制「到目的地」的 TLS 模式如果说 PeerAuthentication 决定「服务端是否强制要求 mTLS」那么 DestinationRule 中的trafficPolicy.tls决定「客户端侧边车出站时以什么 TLS 模式加密」。模板覆盖了网格内、外部明文 TLS、外部双向 TLS 三类出口场景apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: default namespace: istio-system spec: host: *.local trafficPolicy: tls: mode: ISTIO_MUTUAL --- # TLS to external service apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: external-api spec: host: api.external.com trafficPolicy: tls: mode: SIMPLE caCertificates: /etc/certs/external-ca.pem --- # Mutual TLS to external service apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: partner-api spec: host: api.partner.com trafficPolicy: tls: mode: MUTUAL clientCertificate: /etc/certs/client.pem privateKey: /etc/certs/client-key.pem caCertificates: /etc/certs/partner-ca.pem需要特别注意的三种模式差异TLS mode适用对象额外配置ISTIO_MUTUAL网格内服务无需指定证书Istio 自动注入工作负载证书SIMPLE单向 TLS 的外部 APIcaCertificates指向外部 CA 公钥MUTUAL需要双向认证的外部伙伴服务需同时提供clientCertificate、privateKey、caCertificates三件套网格级host: *.localISTIO_MUTUAL的写法配合 Template 1 的 STRICT PeerAuthentication是「全网格强制双向加密」的黄金组合一个约束服务端准入一个约束客户端出站。Template 3用 cert-manager 打通工作负载证书的签发与轮换Istio 自带基于 Citadel/istiod 的 CA 可覆盖大部分网格内场景但当你需要把工作负载证书纳入统一 PKI例如既服务网格内、也服务集群外应用时cert-manager 是更可控的选项。模板给出三层资源# Install cert-manager issuer for Istio apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: istio-ca spec: ca: secretName: istio-ca-secret --- # Create Istio CA secret apiVersion: v1 kind: Secret metadata: name: istio-ca-secret namespace: cert-manager type: kubernetes.io/tls data: tls.crt: base64-encoded-ca-cert tls.key: base64-encoded-ca-key --- # Certificate for workload apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: my-service-cert namespace: my-namespace spec: secretName: my-service-tls duration: 24h renewBefore: 8h issuerRef: name: istio-ca kind: ClusterIssuer commonName: my-service.my-namespace.svc.cluster.local dnsNames: - my-service - my-service.my-namespace - my-service.my-namespace.svc - my-service.my-namespace.svc.cluster.local usages: - server auth - client auth参数设计要点ClusterIssuerca.secretNamecert-manager 直接以自签 CA 的根证书签发证书istio-ca-secret中以tls.crt/tls.key承载 CA 密钥对kubernetes.io/tls类型值需 base64 编码。duration: 24h/renewBefore: 8h工作负载证书建议短生命周期技能最佳实践要求 24h 或更短到期前 8 小时自动续期将「证书过期」从事故源变成例行后台事件。commonName与dnsNamesCN 使用完整 FQDNmy-service.my-namespace.svc.cluster.localSAN 从短名一直覆盖到完整 FQDN确保网格内外按不同寻址方式访问都能校验通过。usages同时声明server auth与client auth这是 mTLS 证书与普通 Web 证书的关键差异——同一张工作负载证书既要证明自己是服务端又要作为客户端身份出示。Template 4SPIFFE/SPIRE 下发动态工作负载身份当安全边界需要跨越集群、甚至跨越 Kubernetes虚机、裸机、多云时SPIRE 通过 SPIFFE 标准提供不依赖固定 ServiceAccount 令牌的短时 X.509 SVID。模板包含 SPIRE Server 配置与 Agent DaemonSet 两部分# SPIRE Server configuration apiVersion: v1 kind: ConfigMap metadata: name: spire-server namespace: spire data: server.conf: | server { bind_address 0.0.0.0 bind_port 8081 trust_domain example.org data_dir /run/spire/data log_level INFO ca_ttl 168h default_x509_svid_ttl 1h } plugins { DataStore sql { plugin_data { database_type sqlite3 connection_string /run/spire/data/datastore.sqlite3 } } NodeAttestor k8s_psat { plugin_data { clusters { demo-cluster { service_account_allow_list [spire:spire-agent] } } } } KeyManager memory { plugin_data {} } UpstreamAuthority disk { plugin_data { key_file_path /run/spire/secrets/bootstrap.key cert_file_path /run/spire/secrets/bootstrap.crt } } } --- # SPIRE Agent DaemonSet (abbreviated) apiVersion: apps/v1 kind: DaemonSet metadata: name: spire-agent namespace: spire spec: selector: matchLabels: app: spire-agent template: spec: containers: - name: spire-agent image: ghcr.io/spiffe/spire-agent:1.8.0 volumeMounts: - name: spire-agent-socket mountPath: /run/spire/sockets volumes: - name: spire-agent-socket hostPath: path: /run/spire/sockets type: DirectoryOrCreate配置中的关键参数含义trust_domainSPIFFE 身份命名空间的根例如example.org最终下发的工作负载 SVID 形如spiffe://example.org/ns/ns/sa/sa。ca_ttl: 168h与default_x509_svid_ttl: 1hServer 自身 CA 的有效期7 天远大于下发给工作负载的 SVID 有效期1 小时保证身份高频轮换、泄露窗口极小。NodeAttestork8s_psat利用 Kubernetes 的 Projected Service Account TokenPSAT作为节点证明机制service_account_allow_list只放行spire:spire-agent这个 SA防止任意 Pod 冒认节点身份。UpstreamAuthoritydiskSPIRE Server 向上游 CA 申请自身证书bootstrap.key/crt是信任链的起点生产环境通常将其替换为与 Vault 等对接的权威上游。Agent DaemonSet以 hostPath 挂载共享 socket 目录/run/spire/socketsAgent 每节点一个通过该 Unix socket 向同节点工作负载下发 SVID因此工作负载无需持有任何静态密钥。Template 5Linkerd 的「零配置」mTLS与 Istio 需要显式编排 PeerAuthentication DestinationRule 不同Linkerd 在注入 sidecar 的同时自动为网格内流量启用 mTLS——它内置的 identity 组件为每个工作负载颁发证书开发者无需编写任何安全策略即可获得全网格双向加密。因此模板的重点放在两个「例外处理」上# Linkerd enables mTLS automatically # Verify with: # linkerd viz edges deployment -n my-namespace # For external services without mTLS apiVersion: policy.linkerd.io/v1beta1 kind: Server metadata: name: external-api namespace: my-namespace spec: podSelector: matchLabels: app: my-app port: external-api proxyProtocol: HTTP/1 # or TLS for passthrough --- # Skip TLS for specific port apiVersion: v1 kind: Service metadata: name: my-service annotations: config.linkerd.io/skip-outbound-ports: 3306 # MySQLServerpolicy.linkerd.io/v1beta1用于声明某个端口的服务端策略与协议配合 ServerAuthorization 可以按服务账号做细粒度放行此处典型场景是把无法参与 mTLS 的外部 API 端口的协议显式声明出来。config.linkerd.io/skip-outbound-ports: 3306Linkerd 默认代理所有 TCP 出站对不支持 TLS 的协议如 MySQL需要用它跳过代理加密否则直连会被链路层握手破坏。验证手段始终是linkerd viz edges deployment -n my-namespace它会列出每条边的tlstrue/false状态。证书轮换操作手册模板库为两条主链路分别提供了轮换手段命令位于 references/details.md# Istio - Check certificate expiry istioctl proxy-config secret deploy/my-app -o json | \ jq .dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes | \ tr -d | base64 -d | openssl x509 -text -noout # Force certificate rotation kubectl rollout restart deployment/my-app # Check Linkerd identity linkerd identity -n my-namespace逐条拆解检视 Istio 证书有效期istioctl proxy-config secret导出 Envoy 动态密钥状态用jq取首个动态密钥的证书链 base64 负载base64 -d还原 DER 后再交给openssl x509输出明文证书信息即可读到 Not Before / Not After 字段用于判断是否需要人工干预轮换。强制轮换由于 Istio 证书绑定工作负载 Podkubectl rollout restart deployment/my-app重启后新 Pod 会从 istiod 请求全新的短期证书——这也从侧面印证了「短证书 重启即换新」的零信任运维模式。Linkerd identity 校验linkerd identity直接展示当前工作负载的 SPIFFE 身份与证书链快速确认注入与身份签发是否正常。调试 mTLS 问题的命令集当流量不通、握手失败或策略未生效时模板按「Istio 双向认证链」与「Linkerd 可视化」给出了成体系的排查路径# Istio - Check if mTLS is enabled istioctl authn tls-check my-service.my-namespace.svc.cluster.local # Verify peer authentication kubectl get peerauthentication --all-namespaces # Check destination rules kubectl get destinationrule --all-namespaces # Debug TLS handshake istioctl proxy-config log deploy/my-app --level debug kubectl logs deploy/my-app -c istio-proxy | grep -i tls # Linkerd - Check mTLS status linkerd viz edges deployment -n my-namespace linkerd viz tap deploy/my-app --to deploy/my-backend排查思路建议按以下顺序推进策略是否生效istioctl authn tls-check会对目标服务名给出当前生效的 mTLS 模式与依据策略随后用kubectl get列出全集群的 PeerAuthentication 与 DestinationRule重点检查是否存在高优先级策略覆盖了你以为生效的宽松/严格配置对应 Template 1 的四级选择器规则。握手是否失败把 istio-proxy 日志级别打到debug并 grep TLS 关键字定位握手在哪个阶段中断证书不信任、SNI 不匹配还是客户端证书缺失。链路可视化Linkerd 一侧则用linkerd viz edges看全链路每一条边的 mTLS 启用状态用linkerd viz tap实时抓取my-app到my-backend之间的流量做行为级确认。落地建议与反模式将 details.md 与 SKILL.md 的最佳实践合并得到可直接作为团队基线的一组 Do/Dont应当遵循Dos从 PERMISSIVE 起步先放行明文 mTLS 并存度量升级影响后再收紧为 STRICT避免一次性切换导致全网断连。监控证书到期为工作负载证书与 CA 建立到期告警配合 Template 3 的renewBefore。使用短生命周期证书工作负载证书控制在 24 小时以内Istio 默认即约 24hSPIRE 示例中 SVID 仅 1 小时缩短泄露后的可利用窗口。周期性轮换 CA提前规划 Root/Intermediate CA 的轮换流程避免 CA 临近过期时才被动处理。记录 TLS 错误日志既服务排障也是合规审计的证据来源。务必避免Donts不为运维便利在生产环境关闭 mTLS——那将把整个零信任模型打回「网络信任」。不忽视证书到期——轮换必须自动化人工盯守必然遗漏。不使用自签名证书替代正规 CA 层级——回到 SKILL.md 中 Root CA → Intermediate CA → Workload Cert 的结构化设计。不跳过完整证书链校验——服务端证书即便受信也必须校验证书链每一环与身份绑定。延伸阅读本模板库是 cloud-infrastructure 插件服务网格安全能力的一环如需继续深入可查看同仓库中以下材料mtls-configuration 技能入口 SKILL.md——mTLS 握手流程、证书层级图与技能触发条件service-mesh-expert 专家 Agent——负责 mTLS 策略设计、证书管理与网格拓扑编排的 opus 级 Agentistio-traffic-management 技能——与 mTLS 配套的 VirtualService、DestinationRule 流量编排模板linkerd-patterns 技能——Linkerd 注入、Server/ServerAuthorization 与多集群的完整模式service-mesh-observability 技能——对 mesh 流量与身份做可观测性收尾docs/agent-skills.md 与 docs/agents.md——技能与 Agent 的全量索引【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考