微服务架构将单体应用拆分为多个独立部署的进程，服务之间的通信从进程内调用变成网络调用，安全边界也随之从单一入口扩展到服务网格内部的每一次请求。传统安全运维习惯在南北向流量入口部署防火墙、WAF 和 API 网关，但微服务真正敏感的数据往往在服务之间的东西向流量中传输。如果这些内部调用没有加密和身份校验，攻击者一旦突破某个低权限服务，就能横向移动到数据库、用户中心或支付服务。微服务安全运维的核心不是堆叠更多设备，而是把身份、证书、策略和审计能力下沉到每个服务实例。
微服务安全运维的核心挑战与边界变化
单体应用通常可以依靠数据中心防火墙、网络隔离区和主机安全软件形成相对清晰的边界，但微服务架构把这种边界拆散了。服务之间通过 HTTP、gRPC 或消息队列通信，这些流量可能在 Kubernetes 集群内部不同节点之间流动，也可能跨多个可用区甚至多个云厂商。传统防火墙只能看到源 IP 和目标 IP，无法识别请求来自哪个服务账户、携带了哪种身份凭证，更无法判断某个服务是否应该访问另一张数据表。攻击者只要控制了一个存在漏洞的中间服务，就可能在内部网络中自由移动，而不触发任何南北向安全设备的告警。
除了流量管控失效，微服务还带来密钥和配置的爆炸式增长。一个单体应用可能只需要维护一个数据库连接串和几个 API 密钥，但微服务拆成几十个甚至上百个组件后，每个服务都可能需要独立的数据库凭证、消息队列账号、第三方服务密钥和 TLS 证书。这些敏感信息如果分散在配置文件、环境变量、启动脚本甚至代码仓库中，就很难统一轮换和审计。更麻烦的是，容器编排平台本身还引入了新的攻击面，例如 kubelet 端口暴露、etcd 未授权访问、镜像仓库被投毒等。安全运维团队必须从边界防御转向纵深防御，让每个服务实例都具备自己的身份和访问控制能力。
因此，微服务安全运维不能只关注某个单点工具，而需要建立一套覆盖开发、构建、部署、运行和响应的完整链路。所谓纵深防御，就是假设任何一层防护都可能被突破，通过多层独立的校验机制降低单点失效风险。下面几节将分别从东西向流量加密、密钥配置管理、镜像与运行时安全、以及零信任授权策略几个角度展开，说明如何把这些机制真正落地到日常运维中。
东西向流量管控：mTLS 与服务网格策略
东西向流量是微服务安全中最容易被忽略但风险最高的一环。因为内部服务之间往往不经过 API 网关，很多团队会默认集群内部网络是可信的，进而关闭 TLS 或仅依赖简单的 Token。这种假设在容器环境中非常危险：同一个节点上可能运行多个不同租户的 Pod，节点被攻破后所有明文流量都会被监听。解决这个问题的基础是 mTLS，即双向 TLS。与普通 HTTPS 只验证服务端身份不同，mTLS 会让客户端和服务端互相出示证书，双方都确认对方身份后才建立加密连接。这样即使攻击者劫持了某个 Pod 的网络，也无法冒充其他服务。
在微服务规模较大时，手工为每个服务签发、分发和更新证书几乎不可维护，因此通常引入服务网格来管理证书生命周期。以 Istio 为例，它的控制平面会为每个 Envoy 代理自动下发短期证书，证书有效期默认只有 24 小时，并通过 SPIFFE 标准定义服务身份。SPIFFE 身份格式通常形如 spiffe://trust-domain/ns/production/sa/payment，其中包含了信任域、命名空间和服务账户信息。下游服务在收到请求时，Envoy 会验证对端证书是否由可信 CA 签发，同时检查证书中的 SPIFFE ID 是否符合授权策略。这样授权判断就不依赖 IP 地址、端口或网络位置，而是直接绑定到服务的逻辑身份。
下面是一个 Istio AuthorizationPolicy 的配置示例。它只允许来自 checkout 命名空间的服务向 payment 服务发送 POST 请求到 /v1/charge 路径，其他来源和操作全部拒绝。这种策略可以由安全团队统一维护，也可以由各个服务团队在自己的命名空间中自定义。
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: payment-allow-checkout
namespace: production
spec:
selector:
matchLabels:
app: payment
action: ALLOW
rules:
- from:
- source:
namespaces: ["checkout"]
to:
- operation:
methods: ["POST"]
paths: ["/v1/charge"]
除了 mTLS 和授权策略，服务网格还能提供流量加密的可观测性。运维人员可以通过 Envoy 的访问日志和指标判断哪些服务之间仍然存在明文流量，及时补全 TLS 配置。需要注意的是，开启 mTLS 本身会增加少量延迟和 CPU 开销，但相比明文传输带来的风险，这个代价通常可以接受。对于性能敏感的场景，可以选择在集群内部使用更高效的证书缓存和会话复用机制，而不是直接关闭加密。
密钥与配置安全管理
微服务中的密钥管理常常处于失控状态。开发人员为了方便调试，可能把数据库密码写到 application.yml 里并提交到 Git 仓库；运维人员为了快速部署，可能把第三方 API 密钥写进 Kubernetes ConfigMap；测试环境中的密钥可能和生产环境相同，甚至共享同一个管理后台。这些问题一旦暴露，就会导致整个集群的凭据泄露。因此，安全运维必须把密钥和普通配置严格分离，并且为密钥建立独立的存储、注入和轮换机制。
主流方案是使用专门的密钥管理服务，例如 Vault、云厂商的 KMS 或者 Kubernetes 原生的 Secret 配合外部加密。Vault 可以动态生成数据库账号，每个服务实例启动时通过身份认证获取一次性租约，租约到期后数据库凭据自动失效。Kubernetes 原生的 Secret 虽然使用方便，但默认只是 base64 编码存储，并不加密，需要额外开启 etcd 静态加密或使用 CSI 驱动把 Secret 指向外部 KMS。配置中心如 Apollo、Nacos 或 Consul 则应避免直接存放明文密码，可以只保存密钥的引用标识，由应用在运行时从密钥管理服务拉取真实值。
下面展示一种基于 Vault Agent 注入密钥的思路。Pod 定义中通过注解声明需要注入的 Vault 路径，Vault Agent 会以 sidecar 方式运行，在应用启动前把密钥写入共享内存卷，应用只需要读取统一目录即可。这种方式不需要修改业务代码，也避免了把密钥暴露在环境变量或日志中。
apiVersion: v1
kind: Pod
metadata:
name: payment-service
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/role: "payment-role"
vault.hashicorp.com/agent-inject-secret-db.txt: "database/creds/payment"
spec:
containers:
- name: app
image: payment:1.4.2
volumeMounts:
- name: vault-secrets
mountPath: /vault/secrets
readOnly: true
密钥轮换同样不能依赖人工。至少要为数据库凭据、云厂商 AccessKey、JWT 签名密钥和 TLS 证书建立自动轮换流程。短期证书可以通过服务网格自动续期，数据库凭据可以通过 Vault 动态租约实现小时级回收，静态密钥则需要定期触发轮换并同步更新所有依赖方。轮换过程中要保证服务无中断，常见做法是先发布新密钥，再灰度切换读取路径，最后统一销毁旧密钥。所有轮换操作都必须记录审计日志，便于事后追溯。
镜像供应链与运行时安全
很多团队只关注运行中的流量和配置，却忽略了镜像本身就是微服务供应链中最大的攻击面之一。攻击者可以通过向公开基础镜像植入后门、篡改依赖包版本、或在 CI 过程中替换构建产物来控制最终运行的容器。因此，安全运维需要从镜像构建开始执行严格的扫描和签名策略。构建流水线中应自动运行镜像扫描工具，检查操作系统包漏洞、语言依赖漏洞、硬编码密钥和恶意文件。镜像扫描结果应作为发布门禁，高危漏洞未修复则禁止推送到生产仓库。
除了扫描，还应该为镜像生成软件物料清单，记录所有依赖的版本和来源。当某个组件被披露存在漏洞时，运维团队可以快速定位哪些服务使用了受影响版本，而不必逐台检查。镜像签名可以防止镜像在仓库中被篡改，例如使用 Cosign 或 Notation 对镜像摘要进行签名，运行时准入控制器只允许拉取通过签名的镜像。基础镜像应尽量选择 distroless 或 Alpine 等最小化版本，减少不必要的软件包和攻击面。
cosign sign --key cosign.key myregistry.com/payment:1.4.2 cosign verify --key cosign.pub myregistry.com/payment:1.4.2
运行时安全则是最后一道防线。即使镜像通过了扫描，运行后的容器仍可能因为漏洞、配置错误或恶意行为被利用。可以通过 Falco 这类工具监控容器运行时的系统调用，检测异常行为，例如在容器内执行 shell、访问敏感文件、发起外部连接等。还可以结合 seccomp、AppArmor 或 SELinux 限制容器可以使用的系统调用和文件路径。Kubernetes 的 Pod Security Standards 也可以控制容器是否允许以 root 运行、是否允许特权模式、是否允许挂载宿主目录等。下面是一个简单的 Falco 规则，用于检测容器内启动交互式 shell。
- rule: Terminal shell in container
desc: Detect interactive shell spawned in a container
condition: >
spawned_process and container and
proc.name in (bash, sh, ash, zsh)
output: Shell opened in container (user=%user.name container=%container.name)
priority: WARNING
运行时告警需要和日志系统、告警平台打通，否则安全事件发生后可能长时间无人处理。建议将 Falco 的输出发送到集中式日志平台，并与工单系统联动。对于高危规则，可以配置自动响应动作，例如立即隔离 Pod、阻断网络连接或触发容器重启。自动响应的策略要经过演练验证，避免误报导致业务中断。
零信任策略与审计响应闭环
微服务架构天然适合落地零信任理念。零信任不再默认任何内部网络或内部服务是可信的，而是对每一次请求都进行身份验证、授权判断和风险检查。具体到微服务运维中，这意味着服务 A 访问服务 B 时，必须出示有效的 SPIFFE 身份或 JWT 令牌，由策略引擎根据服务身份、请求路径、HTTP 方法和调用链上下文做出允许或拒绝的决定。即使两个服务在同一个命名空间、同一个节点上，也不能跳过校验。
零信任策略的落地需要一个统一的策略决策点和策略执行点。在服务网格中，Envoy 作为执行点拦截所有进出流量，控制平面或外部 OPA 作为决策点处理授权规则。规则可以写得非常细粒度，例如只允许 inventory 服务的 GET /items 请求访问 catalog 服务，其他方法一律拒绝。对于需要传递最终用户身份的调用链，可以使用 JWT 透明代理，让下游服务在不需要直接解析用户凭证的情况下也能获得用户身份信息。这样每一跳都能保持完整的审计上下文。
审计是零信任体系能够持续运行的关键。运维团队需要收集 API 网关的访问日志、服务网格中的 Envoy 访问日志、Kubernetes 审计日志、镜像仓库操作日志和密钥访问记录，并统一关联到同一条调用链上。这样当出现安全告警时，可以快速还原攻击路径。例如，某个 Pod 在凌晨两点从外部下载了可疑脚本，随后访问了内部数据库，又向外部域名发送了数据，这条链路上的每一步都应该能够通过日志和追踪系统串联起来。OpenTelemetry 可以在业务代码无侵入的情况下传播 trace 上下文，帮助安全分析人员高效定位异常调用。
最后，应急响应不能停留在纸面上。需要定期模拟服务被攻破、密钥泄露、恶意镜像注入等场景，验证检测、隔离、恢复和复盘流程是否顺畅。每次演练后应记录响应耗时和遗漏环节，并反向更新监控规则和访问策略。微服务安全运维是一个持续迭代的过程，只有把身份、流量、配置、镜像、运行时和审计都纳入统一体系，才能在保持交付速度的同时，将安全风险控制在一个可接受的范围内。