Consul使用ACL來保護UI, API, CLI, 以及service之間， agent之間的通信。工作原理是一個ACL policy關聯一系列ACL規則， 然后把ACL token和policy關聯起來。
Consul中的ACL主要有以下兩個主要部分：
ACL Policies: Acl rules的邏輯分組， 使得acl規則可重用。
ACL Tokens: 每個ACL token有一個Accessor ID用來命名這個token， 一個Secret ID用來作為bearer token進行授權驗證。
ACL Policy
ACL Policy是一組acl規則的集合， 可配置的屬性如下：
ID
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"
}