Consul的使用四之加密和代理

ACL

Consul使用ACL来保护UI, API, CLI, 以及service之间， agent之间的通信。工作原理是一个ACL policy关联一系列ACL规则，然后把ACL token和policy关联起来。

ACL中的Policy和Rule可以通过ACL API和ACL CLI进行配置。

Consul中的ACL主要有以下两个主要部分：

ACL Policies: Acl rules的逻辑分组，使得acl规则可重用。

ACL Tokens: 每个ACL token有一个Accessor ID用来命名这个token，一个Secret ID用来作为bearer token进行授权验证。

ACL Policy

ACL Policy是一组acl规则的集合，可配置的属性如下：

Name

Description

Rules: 一组规则，授权或者拒绝

Datacenters: 适用的数据中心

Namespace: 命令空间（只对企业版有用)

另外有两个内置的策略：

Global Management: 包含任何权限，有个默认的名字global-management, 以及ID00000000-0000-0000-0000-000000000001，只能被重命名，其他不能修改。

Namespace Management: 没创建一个命名空间就会有一个命名空间policy被创建，名称为namespace-management，可以修改。

ACL Tokens

ACL token决定调用者是否有相应的权限，每个ACL token由以下元素组成：

Accessor ID: token的唯一公开标识码

Secret ID：用于鉴权的token

Description: 描述

Policy Set: 使用的policy列表

Service Identity Set

Locality: 是否只适用于当前数据中心，还是所有数据中心

Expiration Time: 过期时间

Namespace

当集群启用ACL时集群会生成两个token：

Anonnymous Token: 匿名token，当请求没有指定token时使用这个token。这个token的描述和policy可以改，但不能删除，新建时它的Accessor ID是00000000-0000-0000-0000-000000000002， Secret ID是anonymous。

Master Token: 关联Global Management Policy，拥有所有权限，值在配置项中指定。

具体的配置查看https://www.consul.io/docs/acl/acl-system.html#configuring-acls

ACL Rules

一条ACL规则由资源，部分和策略组成，结构如下：

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

Policy可以为：

read: 可读不可改
write: 可读可改
deny: 不可读不可改
list: 允许列表显示Consul KV中的指定键值下的内容

ACL资源规则：

通过resource可以指定限制的各种资源。

agent和agent_prefix限制Agent API中的操作。

event和event_prefix限制Event API中的操作。

key和key_prefix限制KV API中的操作。

list，当开启acl.enabe_key_list_policy时限制递归显示列表的权限。

keyring限制Keyring API的操作。

node和node_prefix限制Catalog API中的节点注册及读权限等。

operator限制集群的Operator API的操作，除了Keyring API。

query和query_prefix限制对于Prepared Query API的操作。

service和service_prefix限制Catalog API的服务注册及读取等权限，以及Health API。

session和session_prefix限制对于Session API的操作权限。

namespace和namespace_prefix限制对于命名空间的操作权限。

创建policy步骤详见：https://learn.hashicorp.com/consul/day-0/acl-guide

Connect

Consul Connect提供了service之间通信的连接加密（通过TLS)及授权（通过connect intention)。

在Consul中可以通过sidecar proxies为每个service配置一个proxy，自动处理进来和出去的连接。

如果sidecar proxies对应用程序的性能造成了影响，则可以使用Native proxy。所谓Native proxy即是由应用程序自己处理加密的链接（获取TLS证书，验证证书，验证连接等等），目前Consul只为Go提供了库方便处理加密链接。

当然也可以把proxy配置成一个单独的服务。

如果想要所有链接都是加密的，可以使service监听本地地址，让Connect中的proxy来处理外部请求.

Connect的配置

如果需要启用Connect，加入如下配置：

connect {
  enabled = true
}

Connect会配置使用内置CA来创建和管理证书，当然也可以指定其他的外部的证书管理系统。

可以通过配置项来配置全局的默认的proxy配置。

Consul可以使用内置的proxy来测试和开发https://www.consul.io/docs/connect/proxies/built-in.html

也可以和第三方proxy集成：https://www.consul.io/docs/connect/proxies/envoy.html

Intentions

Connect中的授权即是通过intention来实现的。当一个service通过connect请求建立连接时，首先验证TLS证书是否合法，然后调用authoriza API来验证intention配置是否允许建立连接。

默认的intention行为受默认的ACL Poliy影响，如果ACL Policy默认允许所有链接则intention默认允许所有链接，如果policy默认拒绝所有链接，则intention默认拒绝所有链接。

Intention可以通过API, CLI和UI来管理。

示例配置：

consul intention create -deny web db

拒绝从web service 到db service的连接。

还可以使用通配符：

consul intention create -deny web \'*\'

以及元数据：

consul intention create \
  -deny \
  -meta description=\'Hello there\' \
  web db

元数据在Consul中没有作用，不过可以被外部系统使用。

Intention的权限

ACL也可以保护Intention。Intention的权限是基于目标service的。授权service:read或者service:write的时候，默认会隐式地授予intentions:read 的权限，因为service需要知道是否需要授权给进来的连接。

以下会隐式授予读权限：

service "web" {
  policy = "write"
}

也可以显示配置intention的权限，如下：

service "web" {
  policy = "read"
  intentions = "deny"
}

秒客网