ACL系统

1.4.0及更高版本：本指南仅适用于Consul 1.4.0及更高版本。 旧版ACL系统的文档在这里。

Consul提供了一个可选的访问控制列表（ACL）系统，可用于控制对数据和API的访问。ACL是基于能力的(系统的安全模型之一)，依靠与策略相关联的令牌来确定可以应用哪些细粒度的规则。Consul的基于能力的ACL系统与AWS IAM的设计非常相似。

要了解如何在现有Consul数据中心上设置ACL系统，请使用Bootstrapping ACL System教程。

ACL系统概览

ACL系统的设计是为了便于使用和快速执行，同时提供管理方面的能力。宏观来看，ACL系统有两个主要组成部分：

  • ACL策略 - 策略允许将一组规则分组为一个逻辑单元，该逻辑单元可以重复使用并与许多令牌链接。

  • ACL令牌 - 对Consul的请求是通过使用不记名令牌授权的。每个ACL令牌都有一个公共的Accessor ID，用来命名令牌，还有一个Secret ID，作为向Consul提出请求的不记名令牌。

对于许多场景来说，政策和令牌就足够了，但更高级的设置可能会受益于ACL系统中的其他组件。

  • ACL角色 - 角色允许将一组策略和服务标识归为一个可重复使用的较高级实体，可应用于许多令牌。(在Consul 1.5.0中添加)

  • ACL服务标识 - 服务标识是一种策略模板，用于表达适合在Consul Connect中使用的策略链接。在授权时，这就像附加了一个额外的策略，其内容将在下面进一步描述。这些都是直接附加到令牌和角色上的，而不是独立配置的。(在Consul 1.5.0中添加)

  • ACL节点身份 - 节点身份是一个策略模板，用于表达一个适合作为Consul代理令牌使用的策略链接。在授权时，这就像附加了一个额外的策略，其内容将在下面进一步描述。这些都是直接附加到令牌和角色上的，而不是独立配置的。(在Consul 1.8.1中添加)

  • ACL 认证方法和绑定规则 - 要了解更多关于这些主题的内容，请参见认证方法文档页。

ACL令牌、策略、角色、授权方法和绑定规则由Consul操作员通过Consul的ACL API、ACL CLI或HashiCorp的Vault等系统进行管理。

如果ACL系统无法使用，您可以在任何时候遵循重置程序。

ACL 策略

一个ACL策略是一个命名的规则集，由以下元素组成。

  • ID - 策略的自动生成的公共标识符。

  • Name - 策略的唯一有意义的名称。

  • Description - -策略的可读描述。(可选)

  • Rules - 授予或拒绝权限的一组规则。请参阅规则规范文档了解更多详情。

  • Datacenters - 策略有效的数据中心列表。

  • Namespace - 企业版本，这个策略所在的命名空间。(在Consul Enterprise 1.7.0中添加)

Consul Enterprise 命名空间 - 策略中定义的规则在除缺省之外的任何命名空间中都将被限制为能够授予整体权限的一个子集，并且只影响该单一命名空间。

内置策略

  • 全局管理 - 授予任何使用它的令牌不受限制的权限。创建时，它将被命名为 global-management，并将被分配保留的 ID 00000000-0000-0000-0000-0000-00000001。该策略可以重新命名，但其他任何东西的修改，包括规则集和数据中心范围，都将被Consul阻止。

  • 命名空间管理 -

    （企业版本） - 每个创建的命名空间都会有一个策略，注入名称为namespace-management。这个策略会被注入一个随机的UUID，并且可以像其他用户定义的策略一样在命名空间中进行管理。(在Consul Enterprise 1.7.0中添加)

ACL服务标识

Consul 1.5.0增加。

ACL服务标识是一个ACL策略模板，用于表达适合在Consul Connect中使用的策略链接。它们既可用于令牌。

  • Service Name - 服务名称

  • Datacenters - 策略有效的数据中心列表。 (可选参数)

参与服务网格的服务将需要特权来发现， 并且发现其他健康的服务实例。合适的策略往往看起来都几乎相同，所以服务标识是一个策略模板，以帮助避免创建模板策略。

在授权过程中，将使用以下预配置的ACL规则自动将配置的服务标识作为策略应用：

# Allow the service and its sidecar proxy to register into the catalog.
service "<Service Name>" {
    policy = "write"
}
service "<Service Name>-sidecar-proxy" {
    policy = "write"
}

# Allow for any potential upstreams to be resolved.
service_prefix "" {
    policy = "read"
}
node_prefix "" {
    policy = "read"
}

这篇用于角色的API文档有一些身份标识的例子。

Consul Enterprise Namespacing - 服务标识规则的范围将限于相应ACL令牌或角色所在的单个命名空间。

ACL节点标识

在Consul 1.8.1中新增。

ACL节点标识是ACL策略模板，用于表达指向适合用作Consul代理令牌的策略的链接。 它们在令牌和角色上均可用，并且由以下元素组成：

  • Node Name - 授权访问的节点名称

  • Datacenter - 节点所在的数据中心

在授权过程中，配置的节点标识将自动应用为具有以下预配置 ACL 规则策略：

# Allow the agent to register its own node in the Catalog and update its network coordinates
node "<Node Name>" {
  policy = "write"
}

# Allows the agent to detect and diff services registered to itself. This is used during
# anti-entropy to reconcile difference between the agents knowledge of registered
# services and checks in comparison with what is known in the Catalog.
service_prefix "" {
  policy = "read"
}

Consul Enterprise Namespacing -节点标识只能应用于默认名称空间中的令牌和角色。综合策略规则允许对所有名称空间中的所有服务赋予service：read权限。

ACL角色

Consul 1.5.0 增加

An ACL role is a named set of policies and service identities and is composed of the following elements:

一个ACL角色是一组命名的策略和服务标识，由以下元素组成：

  • ID - 角色自动生成的公共标识符

  • Name - 角色的唯一有意义的名称

  • Description - 对角色可读描述. (可选)

  • Policy Set - 角色包含策略列表

  • Service Identity Set - 角色包含的服务标识.

  • Namespace ENTERPRISE - 策略所在的命名空间 (Consul 企业版本 1.7.0增加)

Consul Enterprise Namespacing - 角色只能链接到在与角色本身相同的名称空间中定义的策略。

ACL 令牌

ACL令牌被用于判断调用者是否有权执行响应的操作。 一个ACL令牌由以下元素组成：

  • Accessor ID - 令牌公共的身份标识；

  • Secret ID - 请求Consul时不记名令牌；

  • Description - 可读的不记名令牌描述；(可选)

  • Policy Set - 令牌适用的策略集合；

  • Role Set - 令牌适用的角色列表；（Consul 1.5.0增加)

  • Service Identity Set - 令牌适用的服务标识集合. (Consul 1.5.0增加)

  • Locality - 令牌是在本地数据中心内创建的，还是在主数据中心创建并全局复制的。

  • Expiration Time - Token失效时间 (可选; Consul 1.5.0增加)

  • Namespace ENTERPRISE - The namespace this policy resides within. (Added in Consul Enterprise 1.7.0)

Consul Enterprise Namespacing - 令牌只能链接到在与临牌本身相同的名称空间中定义的策略和角色。

内置令牌

在集群启动期间，当启用ACL时，特殊的anonymous(匿名)和 master(主) 令牌都将被注入。

  • 匿名令牌 - 当向Consul发出请求而未指定承载令牌时，将使用匿名令牌。匿名令牌的描述和策略可能会更新，但是Consul将阻止该令牌的删除。创建后，00000000-0000-0000-0000-000000000002将作为匿名令牌的 Accessor ID，anonymous 作为Secret ID。

  • 主令牌 - 当Consul配置中存在主令牌时，将创建该主令牌并将其与内置的全局管理策略链接，从而赋予其不受限制的特权。创建主令牌时，会将Secret ID设置为配置条目的值。

授权

令牌秘密ID与每个RPC请求一起传递到服务器。 Consul的HTTP端点可以通过令牌查询字符串参数，X-Consul-Token请求Header或RFC6750授权承载令牌接受令牌。 Consul的CLI命令可以通过token参数或CONSUL_HTTP_TOKEN环境变量接受令牌。 CLI命令还可以接受带有token-file参数或CONSUL_HTTP_TOKEN_FILE环境变量的文件中存储的令牌值。

如果没有为HTTP请求提供令牌，那么Consul将使用默认的ACL令牌（如果已配置）。如果未配置默认ACL令牌

ACL规则和范围

来自与令牌关联的所有策略、角色和服务标识的规则被合并以形成该令牌的有效规则集。根据acl_default_policy的配置, 策略规则可以定义成允许列表或拒绝列表模式。如果默认策略是“拒绝”访问所有资源，则可以将策略规则设置为允许列表访问特定资源。相反，如果默认策略为“允许”，则可以使用策略规则显式拒绝对资源的访问。

下表总结了可用于构造规则的ACL资源：

资源资源

范围

acl

管理ACL系统ACL API的操作

agent

代理API中的实用程序操作（服务和检查注册除外）

event

列出和触发事件API中的事件

key

KV Store API中的键/值存储操作

keyring

Keyring API中的密钥环操作

node

Catalog API，Health API，Prepared Query API，Network Coordinate API和Agent API中的节点级目录操作

operator

除了Keyring API之外，Operator API中的集群级操作

query

准备查询API中的准备查询操作

service

Catalog API，Health API，Prepared Query API和Agent API中的服务级别目录操作

session

会话API中的会话操作

由于Consul快照实际上包含ACL令牌，因此Snapshot API 要求ACL系统具有“写”特权的令牌。

ACL策略未涵盖以下资源：

  1. 该状态API所使用的服务器，正在启动并公开基本IP以及有关服务器端口信息时，不允许任何状态的修改。

  2. Catalog API的数据中心列表操作， 类似查询已知Consul数据中心的名称，不允许修改任何状态。

  3. 该Connect CA roots endpoint仅公开了其他系统可以使用它来验证与Consul TLS连接公共TLS证书。

在“ ACL规则”页面上详细介绍了根据这些策略构造规则 。

Consul Enterprise命名空间-除了直接链接的策略，角色和服务标识之外，Consul Enterprise将包括在Namespaces定义中定义的ACL策略和角色。（在Consul Enterprise 1.7.0中添加）

配置ACL

使用多个不同的配置选项配置ACL。这些配置是区分它们是在服务端，客户端还是两者上设置。

配置选项

Servers

Clients

作用

acl.enabled

REQUIRED

REQUIRED

控制是否启用ACL

acl.default_policy

OPTIONAL

N/A

确定允许列表或拒绝列表模式

acl.down_policy

OPTIONAL

OPTIONAL

确定在远程令牌或策略解析失败时该怎么办

acl.role_ttl

OPTIONAL

OPTIONAL

确定缓存的ACL角色的生存时间

acl.policy_ttl

OPTIONAL

OPTIONAL

确定缓存的ACL策略的生存时间

acl.token_ttl

OPTIONAL

OPTIONAL

确定缓存的ACL令牌的生存时间

还可以配置许多特殊令牌，这些令牌允许启动ACL系统或在特殊情况下访问Consul：

特殊令牌

伺服器

客户群

目的

acl.tokens.agent_master

OPTIONAL

OPTIONAL

远程承载令牌解析失败时可用于访问Agent API的特殊令牌；用于设置集群（例如执行初始加入操作），请参阅“ ACL代理主令牌”部分以了解更多详细信息

acl.tokens.agent

OPTIONAL

OPTIONAL

用于代理程序内部操作的特殊令牌，有关更多详细信息，请参见“ ACL代理程序令牌”部分

acl.tokens.master

OPTIONAL

N/A

用于启动ACL系统的特殊令牌，请查看Bootstrapping ACL教程以获取更多详细信息

acl.tokens.default

OPTIONAL

OPTIONAL

在没有提供令牌的情况下用于客户端请求的默认令牌；通常将其配置为具有对服务的只读访问权限，以在代理上启用DNS服务发现

除令牌外，所有这些令牌master都可以通过/v1/agent/token API引入或更新。

ACL Agent Master Tokern

由于acl.tokens.agent_master旨在在Consul服务器不可用时使用，因此，其策略是在代理上本地管理的，不需要通过ACL API在Consul服务器上定义令牌。设置后，它暗中具有与之关联的以下策略

agent "<node name of agent>" {
  policy = "write"
}
node_prefix "" {
  policy = "read"
}

ACL Agent Token

该acl.tokens.agent是用于代理的内部操作的特殊标记。它不会直接用于任何用户启动的操作（例如）acl.tokens.default，但是如果acl.tokens.agent_token未配置，acl.tokens.default则会使用。ACL代理令牌由代理用于以下操作：

  1. 使用目录API更新代理的节点条目，包括更新其节点元数据，标记的地址和网络坐标

  2. 执行反熵同步，尤其是读取在目录中注册的节点元数据和服务

  3. _rexec执行consul exec命令时读写KV存储区的特殊部分

这是一个示例策略，足以对称为的节点完成上述操作mynode：

node "mynode" {
  policy = "write"
}
service_prefix "" {
  policy = "read"
}
key_prefix "_rexec" {
  policy = "write"
}

该service_prefix策略需要可以在代理上注册的任何服务的读取访问权限。如果将remote exec禁用为默认值，则key_prefix可以省略该策略。

下一步

使用引导ACL系统教程设置ACL或继续阅读有关ACL规则的信息。

上一页访问控制（ACLs）下一页ACL规则

最后更新于