Consul命名空间如何实现多租户服务隔离？

Question

在Consul 1.11+引入命名空间（Namespaces）特性后，多租户隔离成为可能，但实践中常遇一个典型问题：**启用命名空间后，服务注册与发现未自动绑定到指定命名空间，导致跨租户服务意外互通或查询失败**。具体表现为：服务通过API或Agent配置注册时未显式指定`namespace`参数，或Consul CLI/SDK默认使用`default`命名空间；ACL策略未按命名空间粒度精细化配置，致使租户A的服务能意外发现或注销租户B的实例；此外，DNS接口（如`service.service-name.namespace.consul`）未正确解析，或gRPC/HTTP客户端未透传命名空间上下文。这些问题根源在于命名空间非“开箱即用”的强制隔离机制——它依赖服务注册方主动声明、ACL策略严格约束、客户端显式指定及工具链（如Nomad、K8s CSI）适配支持。若忽略任一环节，逻辑隔离即失效，违背多租户安全边界设计初衷。

Answer 1

```html

一、现象层：命名空间“看似启用”却未生效的典型症状

• 服务注册后在 consul catalog services 中仅出现在 default 命名空间，而非预期租户命名空间（如 tenant-a）
• DNS 查询 service.web.tenant-a.consul 返回 NXDOMAIN 或空响应，而 service.web.default.consul 可解析
• ACL token 具备 service:read 权限，却能跨命名空间发现 tenant-b/web 实例（违反最小权限原则）
• Consul UI 中切换命名空间后，服务列表为空，但 CLI 调用未指定 -namespace 时却可见全部服务

二、机制层：命名空间非强制隔离的设计本质

Consul 命名空间是逻辑分区容器，而非网络/进程级沙箱。其隔离依赖三重契约：

契约维度	默认行为	失效风险点
注册侧	Agent 配置或 API 请求中 Namespace 字段为可选	遗漏 "Namespace": "tenant-a" → 注册至 default
策略侧	ACL 规则若未显式声明 Namespace = "tenant-a"，将继承全局作用域	规则 service "web" { policy = "read" } 允许跨所有命名空间读取

三、链路层：全栈上下文透传缺失导致的断点

graph LR
A[服务实例] -->|HTTP POST /v1/agent/service/register| B(Consul Agent)
B --> C{是否携带 X-Consul-Namespace?}
C -->|否| D[路由至 default NS]
C -->|是| E[路由至指定 NS]
E --> F[ACL 策略引擎校验]
F -->|策略未限定 NS| G[允许跨 NS 操作]
F -->|策略含 namespace=“tenant-a”| H[严格隔离]

四、实践层：五步闭环加固方案

1. 注册强制化：在 Consul Agent 的 services 配置块中统一注入 "Namespace": "{{ env "TENANT_NS" }}"，结合 Nomad job 模板或 K8s InitContainer 注入环境变量
2. ACL 策略原子化：为每个租户生成专属 token，策略模板示例：
   

   namespace "tenant-a" {
     service "web" {
       policy = "read"
     }
     node_prefix "" {
       policy = "read"
     }
   }

3. DNS 解析标准化：在 CoreDNS 或 dnsmasq 中配置泛域名转发规则：
   consul { forward . 127.0.0.1:8600 }，确保 *.tenant-a.consul 请求携带 ns=tenant-a 查询参数
4. 客户端 SDK 统一封装：基于 consul-api 封装 ConsulClient(namespace string) 构造器，强制所有 Health().Service() 调用附加 QueryOptions.Namespace
5. CI/CD 级卡点：在 Helm Chart 或 Terraform 模块中加入命名空间合规性检查脚本，验证 service.name 与 namespace 字段一致性

五、演进层：面向云原生多租户的架构收敛

当 Consul 与 Kubernetes 深度集成时，需通过 Consul Namespaces + K8s Namespaces + ServiceMesh（如 Consul Connect） 三层对齐：

• K8s ServiceAccount Token 映射为 Consul ACL Token，并绑定到同名租户命名空间
• Consul Connect 的 DestinationRule 必须声明 namespaceSelector 字段，实现服务网格层的命名空间感知路由
• 使用 consul-k8s 控制器 v1.4+ 的 NamespacePropagation 特性，自动同步 K8s Namespace Annotation 到 Consul 命名空间元数据

```