注册中心Consul使用【集群容器化部署】【ACL使用】

最新推荐文章于 2024-09-11 15:21:29 发布

Happywzy~

最新推荐文章于 2024-09-11 15:21:29 发布

阅读量781

点赞数

分类专栏： consul 文章标签： consul consul acl

原文链接：https://www.consul.io/docs/acl/acl-rules.html

版权

consul 专栏收录该内容

13 篇文章 1 订阅

订阅专栏

ACL规则

Consul提供可选的访问控制列表（ACL）系统，可用于控制对数据和API的访问。要了解有关Consul的ACL的更多信息，请查看ACL系统文档

ACL系统的核心部分是规则语言，用于描述必须强制执行的策略。有两种类型的规则：基于前缀的规则和完全匹配规则。

规则说明

规则由资源，段（对于某些资源区域）和策略处置组成。规则的一般结构是：

<resource> "<segment>" {
  policy = "<policy disposition>"
}

分段资源区域允许运营商更精细地控制对这些资源的访问。请注意，并非所有的资源区域分割，如keyring，operator和acl资源。对于这些规则，他们看起来像：

<resource> = "<policy disposition>"

策略可以有多个控制级别：

read：允许读取资源但不修改资源。
write：允许读取和修改资源。
deny：不允许读取或修改资源。
list：允许访问Consul KV中段下的所有键。请注意，此策略只能与key_prefix资源一起使用，并且acl.enable_key_list_policy必须设置为true。

使用基于前缀的规则时，最具体的前缀匹配决定了该操作。这允许灵活的规则（如空前缀）允许对所有资源进行只读访问，以及允许写访问或拒绝所有访问的某些特定前缀。完全匹配规则仅适用于指定的确切资源。匹配规则的优先顺序是，DENY优先于WRITE或READ，WRITE优先于READ。

我们使用 HashiCorp配置语言（HCL）来指定规则。这种语言是人类可读的并且可以与JSON互操作，因此可以轻松地生成机器。规则可以使用一个或多个策略。

HCL格式的规范如下：

# These control access to the key/value store
key_prefix ""{
  policy ="read"
}
key_prefix "foo/"{
  policy ="write"
}
key_prefix "foo/private/"{
  policy ="deny"
}
# Or for exact key matches
key "foo/bar/secret"{
  policy ="deny"
}

# This controls access to cluster-wide Consul operator information
operator ="read"

这相当于以下JSON输入：

{
  "key_prefix": {
    "": {
      "policy": "read"
    },
    "foo/": {
      "policy": "write"
    },
    "foo/private/": {
      "policy": "deny"
    }
  },
  "key" : {
    "foo/bar/secret" : {
      "policy" : "deny"
    }
  },
  "operator": "read"
}

的ACL API允许使用HCL或JSON被用于定义策略的规则部分的内容。

以下是使用HCL表单的示例请求：

$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}' http://127.0.0.1:8500/v1/acl/policy?token=<token with ACL "write">

这是使用JSON表单的等效请求：

$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "{\"key\":{\"\":{\"policy\":\"read\"},\"foo/\":{\"policy\":\"write\"},\"foo/private\":{\"policy\":\"deny\"}},\"operator\":\"read\"}"
}' http://127.0.0.1:8500/v1/acl/policy?token=<management token>

成功后，将返回该结果：

{
    "CreateIndex": 7,
    "Hash": "UMG6QEbV40Gs7Cgi6l/ZjYWUwRS0pIxxusFKyKOt8qI=",
    "ID": "5f423562-aca1-53c3-e121-cb0eb2ea1cd3",
    "ModifyIndex": 7,
    "Name": "my-app-policy",
    "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}

现在可以在创建令牌时按名称或ID指定创建的策略。这将授予提供给该令牌持有者的规则。

以下是每种规则类型的细分。

ACL资源规则

在acl资源控制对ACL操作中 ACL API。

ACL规则如下所示：

acl = "write"

每个策略只允许一个acl规则，其值设置为其中一个策略处置。在上面的示例中，可以读取或写入ACL，包括发现任何令牌的秘密ID。acl = "write" 由于所有令牌机密都包含在快照中，因此快照还需要权限。

Agent规则

该agent和agent_prefix资源控制访问的公用事业运营代理API，如加入和离开。所有与目录相关的操作都由nodeornode_prefix 和/ service或service_prefix策略覆盖。

agent规则如下所示：

agent_prefix "" {
  policy = "read"
}
agent "foo" {
  policy = "write"
}
agent_prefix "bar" {
  policy = "deny"
}

代理规则由它们适用的节点名称键控。在上面的示例中，规则允许通过使用空前缀，对具有确切名称的节点的读写访问来对任何节点名称进行只读访问foo，并拒绝对以任何名称开头的任何名称进行所有访问bar。

由于在将代理加入群集之前或者在Consul服务器或ACL数据中心中断期间可能需要Agent API实用程序操作，因此可以配置特殊令牌acl.tokens.agent_master以允许对这些操作的写访问，即使没有ACL解析功能也是如此可用。

事件规则

该event和event_prefix资源控制访问事件的操作事件的API，如触发事件和上市活动。

事件规则如下所示：

event_prefix "" {
  policy = "read"
}
event "deploy" {
  policy = "write"
}

事件规则按其应用的事件名称进行细分。在上面的示例中，规则允许对任何事件进行只读访问，并触发“部署”事件。

该consul exec命令在操作期间使用带有“_rexec”前缀的事件，因此要在启用了ACL的Consul环境中启用此功能，除了配置disable_remote_exec到之外，还需要为代理提供对此事件前缀具有访问权限的令牌 false。

键/值规则

该key和key_prefix资源控制访问键/值存储操作在KV API。关键规则如下所示：

key_prefix "" {
  policy = "read"
}
key "foo" {
  policy = "write"
}
key "bar" {
  policy = "deny"
}

关键规则按其适用的密钥名称进行细分。在上面的示例中，规则允许对具有空前缀规则的任何键名进行只读访问，允许对“foo”键进行读写访问，并拒绝访问“bar”键。

List Policy for Keys

Consul 1.0引入了一个新list的密钥策略，只有在通过boolean config参数“acl.enable_key_list_policy”选择时才会强制执行。list控制对递归列表条目和键的访问，并启用更细粒度的策略。使用“acl.enable_key_list_policy”，通过KV API以403中的无效标记结果进行递归读取。示例：

key_prefix "" {
 policy = "deny"
}

key_prefix "bar" {
 policy = "list"
}

key_prefix "baz" {
 policy = "read"
}

在上面的示例中，规则允许读取键“baz”，并且只允许对前缀“bar”进行递归读取。

write对前缀具有list访问权限的令牌也具有访问权限。list对前缀具有read访问权限的令牌也可以访问其所有后缀。

Sentinel集成

Consul Enterprise支持Sentinel集成的密钥写入策略的其他可选字段。具有Sentinel代码策略的示例关键规则如下所示：

key "foo" {
  policy = "write"
  sentinel {
      code = <<EOF
import "strings"
main = rule { strings.has_suffix(value, "bar") }
EOF
      enforcementlevel = "hard-mandatory"
  }
}

有关更多详细信息，请参阅Consul Sentinel文档。

密钥环规则

该keyring资源控制对Keyring API中密钥环操作的访问。

密钥环规则如下所示：

keyring = "write"

每个规则集只允许一个密钥环策略，其值设置为其中一个策略处置。在上面的示例中，可以读取和更新密钥环。

节点规则

该node和node_prefix资源控制节点级注册和读取访问目录API，服务发现与健康API，并且过滤的结果，在代理API 一样获取集群成员列表操作。

节点规则如下所示：

node_prefix "" {
  policy = "read"
}
node "app" {
  policy = "write"
}
node "admin" {
  policy = "deny"
}

节点规则按其应用的节点名称进行分段。在上面的示例中，规则允许对具有空前缀的任何节点名进行只读访问，允许对“app”节点进行读写访问，并拒绝对“admin”节点的所有访问。

需要为代理配置acl.tokens.agent 至少对其自己的节点名称具有“写入”权限，以便将其信息注册到目录，例如节点元数据和标记的地址。如果配置不正确，代理会在尝试将其状态与目录同步时向控制台输出错误。

Consul的DNS接口也受节点规则限制的影响。如果 acl.token.default代理使用的对给定节点没有“读取”访问权限，则DNS接口在查询时将不返回任何记录。

从目录中读取或从运行状况端点检索信息时，节点规则用于过滤查询结果。这允许令牌可以访问给定服务名称的配置，但仅允许在允许的节点名称子集上。

使用Agent API注册节点级别检查时，节点规则起作用。代理将在注册检查时在本地检查令牌，并且Consul还执行定期反熵同步，这可能需要ACL令牌才能完成。为了适应这种情况，Consul提供了两种配置ACL令牌以用于注册事件的方法：

使用acl.tokens.default配置指令。这允许全局配置单个令牌，并在所有检查注册操作期间使用。
在注册时提供带有服务和检查定义的ACL令牌。这允许更大的灵活性并允许在同一代理上使用多个令牌。这种情况的示例可用于服务和检查。也可以将令牌传递给 HTTP API以进行需要它们的操作。

除了ACL之外，在Consul 0.9.0及更高版本中，必须使用enable_script_checksset to 配置代理 true以启用脚本检查。

运算规则

除Keyring API之外，该operator资源控制对Operator API中的集群级操作的访问。

运算符规则如下所示：

operator = "read"

每个规则集只允许一个运算符规则，其值设置为其中一个策略处置。在上面的示例中，令牌可用于查询运营商端点以进行诊断，但不进行任何更改。

查询规则

该query和query_prefix资源控制访问创建，更新和删除中准备的查询准备好的查询API。执行查询受node/ node_prefix和service/ service_prefix 策略约束，如下所述。

查询规则如下所示：

query_prefix "" {
  policy = "read"
}
query "foo" {
  policy = "write"
}

查询规则按其应用的查询名称进行细分。在上面的示例中，规则允许对具有空前缀的任何查询名称进行只读访问，并允许对名为“foo”的查询进行读写访问。这允许基于ACL委托控制查询命名空间。

将ACL与准备好的查询一起使用时会有一些变化，每个查询都使用以下两种方式之一的ACL：打开，受不可识别的ID保护或关闭，由ACL策略管理。这里介绍了这些变化，并举例说明：

没有Name定义的静态查询不受任何ACL策略的控制。这些类型的查询意味着是短暂的，不会与不受信任的客户端共享，只有在准备好的查询ID已知时才能访问它们。由于这些ID是使用与ACL令牌相同的随机ID方案生成的，因此猜测它们是不可行的。列出所有准备好的查询时，只有管理令牌才能看到这些类型，尽管客户端可以读取具有ID的实例。此类型的一个示例用途是由启动脚本构建的查询，绑定到会话，并写入配置文件以供通过DNS使用的进程。
具有已Name定义的静态查询由 ACL资源query和query_prefixACL资源控制。客户端需要具有ACL权限才能访问该查询名称。客户端可以根据其前缀列出或读取他们已“读取”访问权限的查询，类似地，他们可以更新他们具有“写入”访问权限的任何查询。此类型的示例用途是具有众所周知的名称（例如prod-master-customer-db）的查询，许多客户端使用该名称来为数据库提供地理故障转移行为。
模板查询查询的工作方式类似于已Name定义的静态查询，除了具有空的catch-all模板Name需要可以写入任何查询前缀的ACL令牌。

当通过DNS查找或HTTP请求执行准备好的查询时，将对要查询的服务运行ACL检查，类似于ACL如何与其他服务查找一起使用。有多种方法可以为此检查选择ACL令牌：

如果在定义准备好的查询时捕获了ACL令牌，则它将用于执行服务查找。这允许查询由具有较少甚至没有ACL令牌的客户端执行，因此应谨慎使用。
如果未捕获ACL令牌，则客户端的ACL令牌将用于执行服务查找。
如果未捕获ACL令牌且客户端没有ACL令牌，则将使用匿名令牌执行服务查找。

在通常情况下，调用者的ACL令牌用于测试查找服务的能力。如果Token在创建准备好的查询时指定了a ，则行为会更改，现在查找服务时将使用查询定义者设置的捕获ACL令牌。

服务规则

该service和service_prefix资源控制服务水平注册和读取访问目录API 和服务发现与健康API。

服务规则如下所示：

service_prefix "" {
  policy = "read"
}
service "app" {
  policy = "write"
}
service "admin" {
  policy = "deny"
}

服务规则按其应用的服务名称进行细分。在上面的示例中，规则允许对具有空前缀的任何服务名称进行只读访问，允许对“app”服务进行读写访问，并拒绝对“admin”服务的所有访问。

Consul的DNS接口受服务规则限制的影响。如果 acl.tokens.default代理使用的对给定服务没有“读取”访问权限，则DNS接口在查询时将不返回任何记录。

从目录中读取或从运行状况端点检索信息时，将使用服务规则来过滤查询结果。

使用Agent API注册服务或检查时，服务规则会发挥作用。代理将在本地检查令牌作为服务或检查是否已注册，并且Consul还执行定期反熵同步，这可能需要ACL令牌才能完成。为了适应这种情况，Consul提供了两种配置ACL令牌以用于注册事件的方法：

使用acl.tokens.default配置指令。这允许全局配置单个令牌，并在所有服务和检查注册操作期间使用。
在注册时提供带有服务和检查定义的ACL令牌。这允许更大的灵活性并允许在同一代理上使用多个令牌。这种情况的示例可用于服务和检查。也可以将令牌传递给HTTP API以进行需要它们的操作。注意：传递给代理的所有令牌都保留在本地磁盘上，以允许从重新启动中恢复。有关保护访问权限的说明，请参阅-data-dir标记文

除了ACL之外，在Consul 0.9.0及更高版本中，必须为代理配置 enable_script_checks或 enable_local_script_checks 设置true为启用脚本检查。

会话规则

该session和session_prefix资源控制访问会话API操作。

会话规则如下所示：

session_prefix "" {
  policy = "read"
}
session "app" {
  policy = "write"
}
session "admin" {
  policy = "deny"
}

会话规则按其应用的节点名称进行分段。在上面的示例中，规则允许对具有空前缀的节点名称上的会话进行只读访问，允许在名为“app”的节点上创建会话，并拒绝对“admin”节点上的任何会话的所有访问。

Happywzy~

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录