Consul Access Control(ACLS)

2,541 阅读3分钟

Consul使用Access Control Lists (ACLs)来保护UI、API、CLI、服务间通信和agent间通信。ACL的核心是将规则分组到策略中,然后将一个或多个策略与一个Token关联起来。

ACL system

Consul ACL可以用来控制数据和接口的访问。

ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them.

在最高级别,ACL有两个主要组件:

  • ACL Policies - 策略允许将一组规则分组为逻辑单元,该逻辑单元可以重用并与许多Token关联。
  • ACL Tokens - 访问Consul的请求用携带的Token进行认证。每个ACL Token对应一个Accessor ID和一个Secret ID。Accessor ID被用来命名Token,Secret ID用于携带请求Consul的Token。

对比许多场景,Policy和Token已经足够了。但在更高级的场景下需要其他组件:

  • ACL Roles - 规则允许将一组策略和服务标识分组到更高级别的实体中,这些可用于许多令牌。
  • ACL Service Identities - 服务标识是一种策略模板,表示一个适用于Consul连接的链接。
  • ACL Auth Methods and Binding Rules

ACL Policies

一组ACL规则称为策略,由以下元素组成:

  • ID - 自动分配的公共标识。
  • Name - 唯一的有意义的名称。
  • Description - 描述(可选)。
  • Rules - 授予或是拒绝的规则集。
  • Datacenters - 生效的数据中心。

Builtin Policies(内置策略)

  • Global Management - 获取不受限制的权限。

ACL Service Identities

服务标识可用于Token和role,由以下元素组成:

  • Service Name - 服务的名称。
  • Datacenters - 生效的数据中心。

参与服务网格的服务将需要服务发现和被发现的privileges。适合的策略往往看起来几乎相同,因此服务标识是一种策略模板,避免制定样板策略。

在授权过程中,配置的服务标识将自动应用为有以下预配置的 ACL rules:

// 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"
}

ACL Tokens

ACL Token被用于识别调用者是否有权执行一个动作。由以下元素组成:

  • Accessor ID - Token的公共标识。
  • Secret ID - 请求Consul时携带的Token。
  • Description - 描述。
  • Policy Set - 策略集合。
  • Role Set - 角色集合。
  • Service Identity Set - 服务标识(策略模板)。
  • Locality -
  • Expiration Time - Token失效时间。

Builtin Tokens(内置Token)

  • Anonymous Token - 匿名Token被用于标识不带Token的Consul请求。
  • Master Token - 内置的Global Management对应的Token。Secret ID设置为配置实体的值。

ACl Rules

ACL System核心的一部分是rule language,rule被用于描述必须强制执行的策略。由以下元素组成:

  • resource -
  • segment -
  • policy disposition -

一般结构如下:

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

策略有多种控制级别:

  • read
  • write
  • deny
  • list:容许访问segment下的所有k/v key。注意:此策略只能与key_prefix资源一起使用,并且acl.enable_key_list_policy必须设置为true。

我们使用HashiCorp Configuration Language (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"

ACL API 支持HCL和JSON定义策略的规则内容:

$ 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">

如果执行成功,返回值:

{
    "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\""
}

ACL Auth Methods

Auth Methods是Consul组件,对信任的外部方法进以在本地数据中心创建可用的ACL Token进行认证。

The only supported type of auth method in Consul 1.5.0 is kubernetes.