AgentMesh 在 AWS 上从集群到生产的完整部署实战EKS、IRSA、KMS 与 CloudWatch 一体化落地【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文基于 agent-governance-toolkit 仓库中 AgentMesh 的 AWS 部署文档完整讲解如何在 Amazon Web Services 上落地 AgentMesh 多智能体治理平台从 eksctl 创建 EKS 集群、用 IRSA 实现 Pod 级 IAM 身份、KMS 信封加密管理智能体 Ed25519 私钥到 CloudWatch 指标告警与 EventBridge 审计事件转发并给出多可用区高可用拓扑、VPC 网络隔离与成本优化的生产级模式。读完本文你可以复制一套可直接运行的 eksctl / Helm / IAM / KMS 命令与配置并将 AgentMesh 的 Helm Chart 部署到生产级 AWS 环境中。架构总览AgentMesh 在 AWS 上的目标拓扑是EKS 集群承载治理服务本体Server 与 SidecarElastiCacheRedis负责缓存与协调状态RDSPostgreSQL承载审计与信任数据KMS 负责密钥信封加密CloudWatch 负责指标与日志观测。原文档给出的架构图如下┌─────────────────────────────────────────────────┐ │ AWS Region │ │ ┌───────────────────────────────────────────┐ │ │ │ VPC │ │ │ │ ┌─────────────┐ ┌─────────────────────┐│ │ │ │ │ EKS Cluster │ │ ElastiCache (Redis) ││ │ │ │ │ │ └─────────────────────┘│ │ │ │ │ ┌─────────┐ │ ┌─────────────────────┐│ │ │ │ │ │AgentMesh│ │ │ RDS (PostgreSQL) ││ │ │ │ │ │ Server │ │ └─────────────────────┘│ │ │ │ │ ├─────────┤ │ ┌─────────────────────┐│ │ │ │ │ │AgentMesh│ │ │ AWS KMS ││ │ │ │ │ │ Sidecar │ │ └─────────────────────┘│ │ │ │ │ └─────────┘ │ │ │ │ │ └─────────────┘ ┌─────────────────────┐│ │ │ │ │ CloudWatch ││ │ │ │ └─────────────────────┘│ │ │ └───────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘结合仓库中的 Helm Chart 源码可以进一步印证这套架构的组件划分。AgentMesh 的 Helm Chart 实际部署四个核心组件与上图的 AgentMesh Server 一一对应组件职责默认副本服务端口Trust Engine计算与管理智能体信任评分含 IATP 握手28443metrics 9090Policy Server以 YAML 策略评估智能体行为28444metrics 9091Audit Collector不可变审计日志的摄入与保留18445metrics 9092API Gateway外部入口负责限流与 TLS2443metrics 9093从 values.yaml 可以看到这些组件默认开启 Pod 间 TLSglobal.tls.enabled: true证书 Secret 名为agentmesh-tls且每个组件都暴露独立的 Prometheus metrics 端口9090–9093——这正是下文 CloudWatch 监控章节抓取 9090 端口指标的基础。前置条件开始部署前请确认以下工具链就绪AWS CLIv2并已配置有效凭证aws sts get-caller-identity验证eksctlv0.160 或 Terraform用于集群供给kubectl已指向目标 EKS 集群Helm 3.x用于基于 Chart 的部署。另外注意Chart 的 README 声明其最低要求为 Kubernetes 1.24、Helm 3因此下面创建的 K8s 1.29 集群完全满足条件。EKS 集群创建使用 eksctl 创建集群eksctl create cluster \ --name agentmesh-prod \ --region us-east-1 \ --version 1.29 \ --nodegroup-name workers \ --node-type m5.large \ --nodes 3 \ --nodes-min 2 \ --nodes-max 5 \ --managed这里使用托管节点组--managed并将节点规模弹性约束在 2–5 之间与后文多可用区高可用拓扑每个 AZ 至少 1 个工作节点相匹配。推荐节点配置组件实例类型最小节点数说明AgentMesh Serverm5.large2CPU 密集型信任评分计算AgentMesh Sidecar运行在智能体 Pod 内—每个 sidecar 约占 128 MB 内存RedisElastiCachecache.r6g.large2多可用区实现 HAPostgreSQLRDSdb.r6g.large2多可用区并带只读副本节点侧的资源预算要与 Chart 默认值对齐从 values.yaml 看四个组件默认的 requests 均为cpu: 100m / memory: 256Mi、limits 为cpu: 500m / memory: 512Mi。若按 HA 模式将 Trust Engine、Policy Server、API Gateway 各提升到 3 副本见下文m5.large2 vCPU / 8 GB的节点即可轻松容纳而审计数据若改用 RDS 持久化而非 Chart 内 Audit Collector 的 10Gi PVCauditCollector.retentionDays默认 90 天本地节点压力会进一步下降。IAM为 ServiceAccount 绑定 IRSA为了让 AgentMesh 的 Pod 以细粒度 AWS 权限访问 KMS、CloudWatch Logs、EventBridge 而不落地任何静态凭证推荐 IRSAIAM Roles for Service Accounts。整个过程分四步1. 关联 OIDC Providereksctl utils associate-iam-oidc-provider \ --cluster agentmesh-prod \ --region us-east-1 \ --approve2. 创建最小权限 IAM 策略策略只开放三类动作且 Resource 精确到具体的 KMS 密钥、日志组前缀和 EventBridge 事件总线符合最小权限原则{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ kms:Decrypt, kms:Encrypt, kms:GenerateDataKey ], Resource: arn:aws:kms:us-east-1:ACCOUNT_ID:key/KEY_ID }, { Effect: Allow, Action: [ logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents ], Resource: arn:aws:logs:us-east-1:ACCOUNT_ID:log-group:/agentmesh/* }, { Effect: Allow, Action: [ events:PutEvents ], Resource: arn:aws:events:us-east-1:ACCOUNT_ID:event-bus/agentmesh-audit } ] }kms:Decrypt / Encrypt / GenerateDataKey支撑下文 KMS 信封加密与 Secrets Manager 的密钥轮换logs:CreateLogGroup / CreateLogStream / PutLogEvents支撑 CloudWatch 日志与容器指标上报限定在/agentmesh/*日志组前缀下events:PutEvents仅允许写入agentmesh-audit这条事件总线用于审计事件转发。3. 创建带 IRSA 注解的 ServiceAccounteksctl create iamserviceaccount \ --cluster agentmesh-prod \ --namespace agentmesh \ --name agentmesh-sa \ --attach-policy-arn arn:aws:iam::ACCOUNT_ID:policy/AgentMeshPolicy \ --approve4. 在 Helm Values 中引用serviceAccount: create: false name: agentmesh-sa这里有一个与 Chart 源码直接相关的细节serviceaccount.yaml 模板除了create: false分支外还支持serviceAccount.annotations字段——如果你的 ServiceAccount 由 Chart 自行创建create: true可以直接通过serviceAccount: create: true name: agentmesh-sa annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/AgentMeshIRSA把 IRSA 角色 ARN 注解写进去无需额外创建资源两种接入方式可按现有环境二选一。KMS 密钥与机密管理加密智能体 Ed25519 私钥AgentMesh 使用 Ed25519 密钥作为智能体身份签名凭证这一点与仓库 ADR 0001使用 ED25519 作为智能体身份 的决策一致。生产环境中私钥必须在静态状态下加密官方推荐用 AWS KMS 信封加密# 为 AgentMesh 创建 KMS 密钥 aws kms create-key \ --description AgentMesh agent key encryption \ --key-usage ENCRYPT_DECRYPT \ --origin AWS_KMS # 将加密后的密钥存入 Secrets Manager aws secretsmanager create-secret \ --name agentmesh/agent-keys/agent-alpha \ --kms-key-id alias/agentmesh-keys \ --secret-string {private_key: base64-encoded-ed25519-key}Secrets Manager 在写入时会用该 KMS 密钥对 Secret 值做信封加密Pod 侧只通过kms:Decrypt权限按需解密避免明文私钥进入镜像、ConfigMap 或 Git。使用 AWS Secrets Store CSI Driver 挂载通过 SecretProviderClass 声明挂载对象由 CSI 驱动将 Secrets Manager 内容以卷的形式投影到 Pod 内# SecretProviderClass for mounting KMS-encrypted secrets apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: agentmesh-secrets namespace: agentmesh spec: provider: aws parameters: objects: | - objectName: agentmesh/agent-keys/agent-alpha objectType: secretsmanager注意 SecretProviderClass 的读取路径同样受 IAM 约束——除了上文的kms:DecryptPod 所在身份还需要对agentmesh/agent-keys/*的secretsmanager:GetSecretValue权限可按同样方式扩展现有 IAM 策略。CloudWatch 监控与审计事件转发Prometheus 指标接入 CloudWatchAgentMesh 各组件默认开启 Prometheus 注解monitoring.prometheus.enabled: true抓取间隔 15s。在 AWS 上可以使用 CloudWatch Agent 或 ADOTAmazon OpenTelemetryCollector 抓取这些指标并转发到 CloudWatch。关键指标与告警阈值均取自 9090 等 metrics 端口指标来源端口CloudWatch 告警agentmesh_trust_score9090任一智能体低于 300 时告警agentmesh_policy_violations_total9090超过 10 次/分钟时告警agentmesh_anomaly_detections_total9090出现 HIGH 级别异常时告警agentmesh_credential_rotations_total9090轮换失败时提醒agentmesh_handshake_duration_seconds9090p99 超过 500 ms 时告警这些指标名并非凭空而来。仓库自带的 Grafana 告警规则 alerts.yaml 定义了与上述表格同源的三条告警策略违规速率sum(rate(agentmesh_policy_violations_total[1m])) * 60超过 10/min 判为 critical、信任分agentmesh_trust_score低于 0.3 判为 warning、握手延迟histogram_quantile(0.99, rate(agentmesh_handshake_latency_seconds_bucket[5m]))超过 5s 判为 critical。可以推断 AWS 侧的 CloudWatch 告警阈值可以直接参照这套规则校准此外 metrics.py 中定义了agentmesh_trust_score_gauge{agent_did...}、agentmesh_handshake_total{statussuccess|fail}、agentmesh_credential_issued_total等具体序列供按agent_did维度做细粒度排查。审计日志经 CloudEvents 转发到 EventBridgeAgentMesh 的审计链路原生支持 CloudEvents v1.0 封装——audit.py 中的export_cloudevents()会把审计条目逐条转换为 CloudEvents JSON 信封entries → e.to_cloudevent()并支持按时间窗导出。AWS 侧的配置只需将导出目标指向 EventBridge# AgentMesh config audit: export: type: cloudevents target: aws_eventbridge event_bus: agentmesh-audit region: us-east-1这与 IAM 策略中events:PutEvents精确限定到agentmesh-audit总线的设计互为呼应审计事件从 Merkle 链背书的审计库导出为 CloudEvents落到 EventBridge 后即可被下游如 S3 归档、Lambda 分析、跨账户转发消费实现不可篡改审计日志的云上流转。高可用拓扑多可用区部署┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ AZ-1a │ │ AZ-1b │ │ AZ-1c │ │ │ │ │ │ │ │ AgentMesh │ │ AgentMesh │ │ AgentMesh │ │ Server (1) │ │ Server (1) │ │ Server (1) │ │ │ │ │ │ │ │ Redis Primary│ │ Redis Replica│ │ │ │ RDS Primary │ │ RDS Standby │ │ RDS Read │ └──────────────┘ └──────────────┘ └──────────────┘核心原则AgentMesh Server≥ 2 副本跨 AZ 分布并配置 Pod 反亲和RedisElastiCache Multi-AZ自动故障切换PostgreSQLRDS Multi-AZ并加只读副本承接审计查询负载。HA 的 Helm ValuesreplicaCount: 3 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: topology.kubernetes.io/zone labelSelector: matchLabels: app: agentmesh-server resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi由于实际 Chart 是按组件拆分的replicaCount这类全局值应映射为各组件的replicas。Chart README 给出的生产 HA 安装命令可以直接照搬helm install agentmesh ./charts/agentmesh \ --set trustEngine.replicas3 \ --set policyServer.replicas3 \ --set apiGateway.replicas3 \ --set autoscaling.minReplicas3 \ --set autoscaling.maxReplicas20 \ --set podDisruptionBudget.minAvailable2配合--set podDisruptionBudget.minAvailable2节点维护或故障时至少 2 个副本保持可用。跨 AZ 分布则按 Chart README 建议用拓扑反亲和实现topologyKey: topology.kubernetes.io/zone标签app.kubernetes.io/component: trust-engine且可用requiredDuringSchedulingIgnoredDuringExecution做硬性隔离。弹性方面Chart 默认autoscaling.enabled: true、CPU 目标利用率 70%、副本区间 2–10可与上文的autoscaling.minReplicas/maxReplicas覆盖协同工作。网络安全VPC 规划EKS 节点放置在私有子网出网走 NAT GatewayRDS 与 ElastiCache 放在私有子网禁止公网访问对 AWS 服务访问KMS、Secrets Manager、CloudWatch、EventBridge使用VPC 端点让流量留在 AWS 骨干网内。安全组规则组件入站出站AgentMesh Server8080API、9090metrics仅限 VPC 内Redis 6379、RDS 5432、KMS/Secrets Manager 端点AgentMesh Sidecar8081 仅 localhostAgentMesh Server 8080Redis6379来自 AgentMesh 安全组—RDS5432来自 AgentMesh 安全组—Kubernetes NetworkPolicyapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agentmesh-server namespace: agentmesh spec: podSelector: matchLabels: app: agentmesh-server policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: agentmesh-access: true ports: - port: 8080 - port: 9090 egress: - to: - namespaceSelector: {} ports: - port: 6379 - port: 5432补充一点来自 Chart 源码的事实当networkPolicy.enabled: true默认开启时networkpolicy.yaml 会生成一套更细粒度的策略——入站流量仅放行到 API Gateway 的 443 端口API Gateway 的出站仅限 Trust Engine8443、Policy Server8444、Audit Collector8445三个内部组件加 DNS而三个内部组件则只接受来自 API Gateway 的流量出站仅保留 DNSUDP 53与外部 HTTPSTCP 443。上文的手工 NetworkPolicy 可视为对这套默认策略的自定义替代方案两者思路一致把治理平面收敛成外部 → Gateway → 内部组件的单向通道。通用生产模式身份集成通过 IRSA 让 AgentMesh Pod 无静态凭证地访问 AWS 服务并将每个智能体身份映射到独立 IAM 角色实现按智能体的细粒度访问控制AgentMesh DID → K8s ServiceAccount → IAM Role (via IRSA)即AgentMesh 层的去中心化标识DID落在 K8s ServiceAccount 上再经 IRSA 桥接为 AWS IAM 角色形成跨层身份链。机密管理智能体私钥AWS Secrets Manager KMS 信封加密 CSI Driver 挂载Redis / RDS 凭证Secrets Manager 自动轮换TLS 证书对外用 ACMAWS Certificate Manager网格内部用 SPIFFEChart 中global.spiffe.enabled默认关闭开启时信任域默认agentmesh.local。成本优化非关键智能体工作负载使用 Spot 实例按智能体规模对 ElastiCache 与 RDS 做容量右配上文推荐配置中的 r6g.large 是基线审计查询优先用 CloudWatch Logs Insights 按需检索而非全量长周期日志留存。小结本文以仓库中 AWS 部署文档 为主线覆盖了 AgentMesh 在 AWS 上落地的完整闭环eksctl 建集群 → Helm 部署四组件治理平面 → IRSA 无凭证身份 → KMS/Secrets Manager 信封加密私钥 → CloudWatch 指标告警与 CloudEvents 审计转发 → 多 AZ 高可用与 VPC 网络隔离。仓库内 Helm Chart 与 values.yaml、告警规则、审计 CloudEvents 导出实现 均可作为进一步核对参数与实现的入口如需对比其他云平台可参考同目录的 Kubernetes 通用指南、Azure 部署 与 GCP 部署。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AgentMesh 在 AWS 上从集群到生产的完整部署实战：EKS、IRSA、KMS 与 CloudWatch 一体化落地
AgentMesh 在 AWS 上从集群到生产的完整部署实战EKS、IRSA、KMS 与 CloudWatch 一体化落地【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文基于 agent-governance-toolkit 仓库中 AgentMesh 的 AWS 部署文档完整讲解如何在 Amazon Web Services 上落地 AgentMesh 多智能体治理平台从 eksctl 创建 EKS 集群、用 IRSA 实现 Pod 级 IAM 身份、KMS 信封加密管理智能体 Ed25519 私钥到 CloudWatch 指标告警与 EventBridge 审计事件转发并给出多可用区高可用拓扑、VPC 网络隔离与成本优化的生产级模式。读完本文你可以复制一套可直接运行的 eksctl / Helm / IAM / KMS 命令与配置并将 AgentMesh 的 Helm Chart 部署到生产级 AWS 环境中。架构总览AgentMesh 在 AWS 上的目标拓扑是EKS 集群承载治理服务本体Server 与 SidecarElastiCacheRedis负责缓存与协调状态RDSPostgreSQL承载审计与信任数据KMS 负责密钥信封加密CloudWatch 负责指标与日志观测。原文档给出的架构图如下┌─────────────────────────────────────────────────┐ │ AWS Region │ │ ┌───────────────────────────────────────────┐ │ │ │ VPC │ │ │ │ ┌─────────────┐ ┌─────────────────────┐│ │ │ │ │ EKS Cluster │ │ ElastiCache (Redis) ││ │ │ │ │ │ └─────────────────────┘│ │ │ │ │ ┌─────────┐ │ ┌─────────────────────┐│ │ │ │ │ │AgentMesh│ │ │ RDS (PostgreSQL) ││ │ │ │ │ │ Server │ │ └─────────────────────┘│ │ │ │ │ ├─────────┤ │ ┌─────────────────────┐│ │ │ │ │ │AgentMesh│ │ │ AWS KMS ││ │ │ │ │ │ Sidecar │ │ └─────────────────────┘│ │ │ │ │ └─────────┘ │ │ │ │ │ └─────────────┘ ┌─────────────────────┐│ │ │ │ │ CloudWatch ││ │ │ │ └─────────────────────┘│ │ │ └───────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘结合仓库中的 Helm Chart 源码可以进一步印证这套架构的组件划分。AgentMesh 的 Helm Chart 实际部署四个核心组件与上图的 AgentMesh Server 一一对应组件职责默认副本服务端口Trust Engine计算与管理智能体信任评分含 IATP 握手28443metrics 9090Policy Server以 YAML 策略评估智能体行为28444metrics 9091Audit Collector不可变审计日志的摄入与保留18445metrics 9092API Gateway外部入口负责限流与 TLS2443metrics 9093从 values.yaml 可以看到这些组件默认开启 Pod 间 TLSglobal.tls.enabled: true证书 Secret 名为agentmesh-tls且每个组件都暴露独立的 Prometheus metrics 端口9090–9093——这正是下文 CloudWatch 监控章节抓取 9090 端口指标的基础。前置条件开始部署前请确认以下工具链就绪AWS CLIv2并已配置有效凭证aws sts get-caller-identity验证eksctlv0.160 或 Terraform用于集群供给kubectl已指向目标 EKS 集群Helm 3.x用于基于 Chart 的部署。另外注意Chart 的 README 声明其最低要求为 Kubernetes 1.24、Helm 3因此下面创建的 K8s 1.29 集群完全满足条件。EKS 集群创建使用 eksctl 创建集群eksctl create cluster \ --name agentmesh-prod \ --region us-east-1 \ --version 1.29 \ --nodegroup-name workers \ --node-type m5.large \ --nodes 3 \ --nodes-min 2 \ --nodes-max 5 \ --managed这里使用托管节点组--managed并将节点规模弹性约束在 2–5 之间与后文多可用区高可用拓扑每个 AZ 至少 1 个工作节点相匹配。推荐节点配置组件实例类型最小节点数说明AgentMesh Serverm5.large2CPU 密集型信任评分计算AgentMesh Sidecar运行在智能体 Pod 内—每个 sidecar 约占 128 MB 内存RedisElastiCachecache.r6g.large2多可用区实现 HAPostgreSQLRDSdb.r6g.large2多可用区并带只读副本节点侧的资源预算要与 Chart 默认值对齐从 values.yaml 看四个组件默认的 requests 均为cpu: 100m / memory: 256Mi、limits 为cpu: 500m / memory: 512Mi。若按 HA 模式将 Trust Engine、Policy Server、API Gateway 各提升到 3 副本见下文m5.large2 vCPU / 8 GB的节点即可轻松容纳而审计数据若改用 RDS 持久化而非 Chart 内 Audit Collector 的 10Gi PVCauditCollector.retentionDays默认 90 天本地节点压力会进一步下降。IAM为 ServiceAccount 绑定 IRSA为了让 AgentMesh 的 Pod 以细粒度 AWS 权限访问 KMS、CloudWatch Logs、EventBridge 而不落地任何静态凭证推荐 IRSAIAM Roles for Service Accounts。整个过程分四步1. 关联 OIDC Providereksctl utils associate-iam-oidc-provider \ --cluster agentmesh-prod \ --region us-east-1 \ --approve2. 创建最小权限 IAM 策略策略只开放三类动作且 Resource 精确到具体的 KMS 密钥、日志组前缀和 EventBridge 事件总线符合最小权限原则{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ kms:Decrypt, kms:Encrypt, kms:GenerateDataKey ], Resource: arn:aws:kms:us-east-1:ACCOUNT_ID:key/KEY_ID }, { Effect: Allow, Action: [ logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents ], Resource: arn:aws:logs:us-east-1:ACCOUNT_ID:log-group:/agentmesh/* }, { Effect: Allow, Action: [ events:PutEvents ], Resource: arn:aws:events:us-east-1:ACCOUNT_ID:event-bus/agentmesh-audit } ] }kms:Decrypt / Encrypt / GenerateDataKey支撑下文 KMS 信封加密与 Secrets Manager 的密钥轮换logs:CreateLogGroup / CreateLogStream / PutLogEvents支撑 CloudWatch 日志与容器指标上报限定在/agentmesh/*日志组前缀下events:PutEvents仅允许写入agentmesh-audit这条事件总线用于审计事件转发。3. 创建带 IRSA 注解的 ServiceAccounteksctl create iamserviceaccount \ --cluster agentmesh-prod \ --namespace agentmesh \ --name agentmesh-sa \ --attach-policy-arn arn:aws:iam::ACCOUNT_ID:policy/AgentMeshPolicy \ --approve4. 在 Helm Values 中引用serviceAccount: create: false name: agentmesh-sa这里有一个与 Chart 源码直接相关的细节serviceaccount.yaml 模板除了create: false分支外还支持serviceAccount.annotations字段——如果你的 ServiceAccount 由 Chart 自行创建create: true可以直接通过serviceAccount: create: true name: agentmesh-sa annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/AgentMeshIRSA把 IRSA 角色 ARN 注解写进去无需额外创建资源两种接入方式可按现有环境二选一。KMS 密钥与机密管理加密智能体 Ed25519 私钥AgentMesh 使用 Ed25519 密钥作为智能体身份签名凭证这一点与仓库 ADR 0001使用 ED25519 作为智能体身份 的决策一致。生产环境中私钥必须在静态状态下加密官方推荐用 AWS KMS 信封加密# 为 AgentMesh 创建 KMS 密钥 aws kms create-key \ --description AgentMesh agent key encryption \ --key-usage ENCRYPT_DECRYPT \ --origin AWS_KMS # 将加密后的密钥存入 Secrets Manager aws secretsmanager create-secret \ --name agentmesh/agent-keys/agent-alpha \ --kms-key-id alias/agentmesh-keys \ --secret-string {private_key: base64-encoded-ed25519-key}Secrets Manager 在写入时会用该 KMS 密钥对 Secret 值做信封加密Pod 侧只通过kms:Decrypt权限按需解密避免明文私钥进入镜像、ConfigMap 或 Git。使用 AWS Secrets Store CSI Driver 挂载通过 SecretProviderClass 声明挂载对象由 CSI 驱动将 Secrets Manager 内容以卷的形式投影到 Pod 内# SecretProviderClass for mounting KMS-encrypted secrets apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: agentmesh-secrets namespace: agentmesh spec: provider: aws parameters: objects: | - objectName: agentmesh/agent-keys/agent-alpha objectType: secretsmanager注意 SecretProviderClass 的读取路径同样受 IAM 约束——除了上文的kms:DecryptPod 所在身份还需要对agentmesh/agent-keys/*的secretsmanager:GetSecretValue权限可按同样方式扩展现有 IAM 策略。CloudWatch 监控与审计事件转发Prometheus 指标接入 CloudWatchAgentMesh 各组件默认开启 Prometheus 注解monitoring.prometheus.enabled: true抓取间隔 15s。在 AWS 上可以使用 CloudWatch Agent 或 ADOTAmazon OpenTelemetryCollector 抓取这些指标并转发到 CloudWatch。关键指标与告警阈值均取自 9090 等 metrics 端口指标来源端口CloudWatch 告警agentmesh_trust_score9090任一智能体低于 300 时告警agentmesh_policy_violations_total9090超过 10 次/分钟时告警agentmesh_anomaly_detections_total9090出现 HIGH 级别异常时告警agentmesh_credential_rotations_total9090轮换失败时提醒agentmesh_handshake_duration_seconds9090p99 超过 500 ms 时告警这些指标名并非凭空而来。仓库自带的 Grafana 告警规则 alerts.yaml 定义了与上述表格同源的三条告警策略违规速率sum(rate(agentmesh_policy_violations_total[1m])) * 60超过 10/min 判为 critical、信任分agentmesh_trust_score低于 0.3 判为 warning、握手延迟histogram_quantile(0.99, rate(agentmesh_handshake_latency_seconds_bucket[5m]))超过 5s 判为 critical。可以推断 AWS 侧的 CloudWatch 告警阈值可以直接参照这套规则校准此外 metrics.py 中定义了agentmesh_trust_score_gauge{agent_did...}、agentmesh_handshake_total{statussuccess|fail}、agentmesh_credential_issued_total等具体序列供按agent_did维度做细粒度排查。审计日志经 CloudEvents 转发到 EventBridgeAgentMesh 的审计链路原生支持 CloudEvents v1.0 封装——audit.py 中的export_cloudevents()会把审计条目逐条转换为 CloudEvents JSON 信封entries → e.to_cloudevent()并支持按时间窗导出。AWS 侧的配置只需将导出目标指向 EventBridge# AgentMesh config audit: export: type: cloudevents target: aws_eventbridge event_bus: agentmesh-audit region: us-east-1这与 IAM 策略中events:PutEvents精确限定到agentmesh-audit总线的设计互为呼应审计事件从 Merkle 链背书的审计库导出为 CloudEvents落到 EventBridge 后即可被下游如 S3 归档、Lambda 分析、跨账户转发消费实现不可篡改审计日志的云上流转。高可用拓扑多可用区部署┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ AZ-1a │ │ AZ-1b │ │ AZ-1c │ │ │ │ │ │ │ │ AgentMesh │ │ AgentMesh │ │ AgentMesh │ │ Server (1) │ │ Server (1) │ │ Server (1) │ │ │ │ │ │ │ │ Redis Primary│ │ Redis Replica│ │ │ │ RDS Primary │ │ RDS Standby │ │ RDS Read │ └──────────────┘ └──────────────┘ └──────────────┘核心原则AgentMesh Server≥ 2 副本跨 AZ 分布并配置 Pod 反亲和RedisElastiCache Multi-AZ自动故障切换PostgreSQLRDS Multi-AZ并加只读副本承接审计查询负载。HA 的 Helm ValuesreplicaCount: 3 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: topology.kubernetes.io/zone labelSelector: matchLabels: app: agentmesh-server resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi由于实际 Chart 是按组件拆分的replicaCount这类全局值应映射为各组件的replicas。Chart README 给出的生产 HA 安装命令可以直接照搬helm install agentmesh ./charts/agentmesh \ --set trustEngine.replicas3 \ --set policyServer.replicas3 \ --set apiGateway.replicas3 \ --set autoscaling.minReplicas3 \ --set autoscaling.maxReplicas20 \ --set podDisruptionBudget.minAvailable2配合--set podDisruptionBudget.minAvailable2节点维护或故障时至少 2 个副本保持可用。跨 AZ 分布则按 Chart README 建议用拓扑反亲和实现topologyKey: topology.kubernetes.io/zone标签app.kubernetes.io/component: trust-engine且可用requiredDuringSchedulingIgnoredDuringExecution做硬性隔离。弹性方面Chart 默认autoscaling.enabled: true、CPU 目标利用率 70%、副本区间 2–10可与上文的autoscaling.minReplicas/maxReplicas覆盖协同工作。网络安全VPC 规划EKS 节点放置在私有子网出网走 NAT GatewayRDS 与 ElastiCache 放在私有子网禁止公网访问对 AWS 服务访问KMS、Secrets Manager、CloudWatch、EventBridge使用VPC 端点让流量留在 AWS 骨干网内。安全组规则组件入站出站AgentMesh Server8080API、9090metrics仅限 VPC 内Redis 6379、RDS 5432、KMS/Secrets Manager 端点AgentMesh Sidecar8081 仅 localhostAgentMesh Server 8080Redis6379来自 AgentMesh 安全组—RDS5432来自 AgentMesh 安全组—Kubernetes NetworkPolicyapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agentmesh-server namespace: agentmesh spec: podSelector: matchLabels: app: agentmesh-server policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: agentmesh-access: true ports: - port: 8080 - port: 9090 egress: - to: - namespaceSelector: {} ports: - port: 6379 - port: 5432补充一点来自 Chart 源码的事实当networkPolicy.enabled: true默认开启时networkpolicy.yaml 会生成一套更细粒度的策略——入站流量仅放行到 API Gateway 的 443 端口API Gateway 的出站仅限 Trust Engine8443、Policy Server8444、Audit Collector8445三个内部组件加 DNS而三个内部组件则只接受来自 API Gateway 的流量出站仅保留 DNSUDP 53与外部 HTTPSTCP 443。上文的手工 NetworkPolicy 可视为对这套默认策略的自定义替代方案两者思路一致把治理平面收敛成外部 → Gateway → 内部组件的单向通道。通用生产模式身份集成通过 IRSA 让 AgentMesh Pod 无静态凭证地访问 AWS 服务并将每个智能体身份映射到独立 IAM 角色实现按智能体的细粒度访问控制AgentMesh DID → K8s ServiceAccount → IAM Role (via IRSA)即AgentMesh 层的去中心化标识DID落在 K8s ServiceAccount 上再经 IRSA 桥接为 AWS IAM 角色形成跨层身份链。机密管理智能体私钥AWS Secrets Manager KMS 信封加密 CSI Driver 挂载Redis / RDS 凭证Secrets Manager 自动轮换TLS 证书对外用 ACMAWS Certificate Manager网格内部用 SPIFFEChart 中global.spiffe.enabled默认关闭开启时信任域默认agentmesh.local。成本优化非关键智能体工作负载使用 Spot 实例按智能体规模对 ElastiCache 与 RDS 做容量右配上文推荐配置中的 r6g.large 是基线审计查询优先用 CloudWatch Logs Insights 按需检索而非全量长周期日志留存。小结本文以仓库中 AWS 部署文档 为主线覆盖了 AgentMesh 在 AWS 上落地的完整闭环eksctl 建集群 → Helm 部署四组件治理平面 → IRSA 无凭证身份 → KMS/Secrets Manager 信封加密私钥 → CloudWatch 指标告警与 CloudEvents 审计转发 → 多 AZ 高可用与 VPC 网络隔离。仓库内 Helm Chart 与 values.yaml、告警规则、审计 CloudEvents 导出实现 均可作为进一步核对参数与实现的入口如需对比其他云平台可参考同目录的 Kubernetes 通用指南、Azure 部署 与 GCP 部署。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考