Consul Connect是HashiCorp Consul提供的服务网格能力，核心目标是在动态基础设施中建立零信任的服务间通信。传统网络模型习惯在边界放防火墙，内部服务默认互信，这在容器与自动扩缩容场景下极脆弱。Connect将身份绑定到服务而非节点，每次连接都要验证对方身份并加密流量，从根本上消除平面网络内的横向移动风险。
身份签发与SPIFFE标准的落地方式
Connect为每个注册服务分配一个符合SPIFFE规范的身份，格式通常为spiffe://trust-domain/ns/namespace/svc/service-name。Consul的CA模块负责签发短期X.509证书，默认有效期仅几天，并且支持自动轮转。这种机制让服务身份和底层IP解耦，当容器被调度到新节点时，只要服务名不变，身份就延续，通信授权策略也不用重写。
在落地时，Consul agent通过本地令牌向服务端申请证书，存放于内存或磁盘加密区。下面的配置展示了如何为服务启用Connect并指定代理类型：
services {
name = "api"
port = 8080
connect {
sidecar_service {}
}
}
上述HCL中connect块告知Consul该服务参与网格，sidecar_service会自动生成边车代理定义。相比手动维护证书，这种方式把运维复杂度降到最低，同时避免了开发者把私钥硬编码进应用镜像的常见错误。
基于意图的授权模型与默认拒绝机制
Connect的访问控制不依赖网络层ACL，而是使用Intentions（意图）来表达“哪个服务可以访问哪个服务”。意图分为allow和deny两种，系统对所有未显式允许的流量执行默认拒绝。例如只允许web访问api，其他服务即便能路由到api也会被拒。
创建意图可以通过命令行或HTTP API完成，下面的例子用CLI允许web到api：
consul intention create -allow web api
这种模型对安全团队很友好，因为策略语义清晰且能版本化。当服务拆分或合并时，只需调整意图而非防火墙规则。下表对比了传统ACL与Connect意图的差异：
| 维度 | 传统网络ACL | Consul Connect意图 |
|---|---|---|
| 控制对象 | 源IP、端口 | 服务身份 |
| 动态适应 | 差，需手动改规则 | 好，身份随服务移动 |
| 默认策略 | 常为基础允许 | 默认拒绝 |
从表格可见，意图模型把安全边界收拢到服务级别，配合零信任原则，即使攻击者进入集群内网，也无法伪装成合法服务调用敏感接口。
数据面代理模式与流量加密实践
Connect支持两种数据面：一是Envoy边车，功能完整且性能高；二是Consul内置代理，轻量但能力有限。应用本身不需要懂mTLS，流量进出都被代理拦截并加解密。以下Go片段演示服务如何通过标准HTTP调用对端，而加密由边车透明完成：
package main
import (
"fmt"
"net/http"
"io/ioutil"
)
func main() {
// 实际请求发往localhost边车监听端口，由代理转发至api服务
resp, err := http.Get("http://localhost:8080/health")
if err != nil {
panic(err)
}
defer resp.Body.Close()
body, _ := ioutil.ReadAll(resp.Body)
fmt.Println(string(body))
}
在该模式下，业务代码零改造，安全能力完全下沉。若使用Envoy，还可启用流量镜像、重试与熔断等高级特性。需要注意的是，内置代理不支持L7路由，仅做TCP隧道，因此在多版本灰度场景应优先选Envoy。
当旧系统暂无法接入边车时，Connect提供网关模式，将网格外请求经特定代理验证后引入，逐步实现迁移。这种渐进式路径降低了零信任落地门槛，也让运维可以按业务优先级分批启用加密与授权。
Consul_Connectservice_meshzero_trust修改时间：2026-08-15 20:32:27