乐闻世界logo
5月27日 20:24

Consul 的 ACL（访问控制列表）如何工作？如何配置和管理 ACL 策略

Consul 的 ACL 基于令牌（Token）实现访问控制。核心流程是：先定义 Policy（策略规则），再将 Policy 绑定到 Token，请求携带 Token 即获得对应权限。

Consul ACL 的核心组件有哪些？

四个核心组件：Token（身份凭证）、Policy（权限规则）、Role（策略集合，方便批量授权）、Auth Method（外部认证集成，如 K8s ServiceAccount）。

权限判定顺序：先匹配精确规则，再匹配前缀规则，未匹配则走 default_policy。

如何启用和初始化 ACL？

在 consul.hcl 中启用：

hcl
acl = {
  enabled = true
  default_policy = "deny"
  down_policy = "extend-cache"
  enable_token_persistence = true
}

启用后必须先执行 consul acl bootstrap 生成 Management Token，后续所有策略和令牌的创建都依赖此 Token。default_policy = "deny" 意味着未显式授权的操作一律拒绝，这是生产环境必须的配置。

追问：down_policy 设为 extend-cache 是什么意思？——当 ACL Server 不可用时，Agent 使用本地缓存的 Token 继续工作，避免因 Server 故障导致服务中断。

Token 有哪几种类型？分别什么权限？

  • Management Token：全局管理权限，等同于 root，仅在初始化和紧急维护时使用
  • Client Token：绑定具体 Policy 的普通令牌，服务日常使用
  • Anonymous Token：未携带 Token 时的默认身份，通常只给最小读权限

追问：Anonymous Token 能做什么？——取决于你给它绑定的 Policy。生产环境建议只给 service_prefix "" 的 read 权限，甚至完全 deny。

Policy 怎么写？权限级别有哪些？

Policy 用 HCL 语法定义，三个权限级别：deny > write > read（deny 优先级最高，无论其他规则如何都拒绝）。

hcl
service "web" {
  policy = "write"
}
key_prefix "config/web" {
  policy = "read"
}
node_prefix "" {
  policy = "read"
}

service "web" 精确匹配 web 服务，service_prefix "web" 匹配 web 前缀的所有服务，service_prefix "" 匹配全部服务。优先级：精确匹配 > 前缀匹配 > default_policy。

如何与 Kubernetes 集成做服务级认证？

通过 Auth Method 对接 K8s ServiceAccount：

bash
consul acl auth-method create -name kubernetes -type kubernetes   -config @k8s-config.json

K8s 中的 Pod 通过 ServiceAccount JWT 自动获取 Consul Token，无需手动分发。Binding Rule 将 K8s 的 namespace/serviceaccount 映射为 Consul 的 Policy 和 Role。

生产环境有哪些必须注意的实践？

  • 最小权限：每个服务只授权自己需要的资源，禁止 service_prefix "" 的 write
  • Token 轮换：定期重建 Token 并淘汰旧的，防止泄露后长期有效
  • ACL Replication：多数据中心场景下，secondary 数据中心需配置 replication token 同步策略
  • 审计日志：开启 audit sink 记录所有 ACL 操作，便于追溯

追问：Token 泄露了怎么办？——立即 consul acl token delete 删除，重建新 Token 并更新应用配置。如果有审计日志，排查泄露期间的异常操作。

标签：Consul