用Consul做配置中心，应用配置会被管理端写到Consul中，并通过ACL对资源进行保护。如图所示：部署应用的服务器会启动一个Consul Client和一个Confd。本地的Consul Client配置的ACL Token拥有应用的配置key的读权限key "app1" {policy = "read"}。Consul Client作为Confd的后台。当配置更新，Confd会去请求Consul Client拉取最新的配置。
我的疑惑：
ACL作为资源的保护机制，ACL绝对的对请求方进行认证，不管请求是从何处转发过来的。例如：小A和小B是好朋友，两人无话不谈。现在小B的邻居小C想找小B打听关于小A的消息。由于协议叫八卦协议小B就把知道的小A的事情毫无保留的告诉邻居小C？
为了解释这个现象，我认为需要理解一下几点：
- Gossip协议；
- Consul集群中数据存储的机制；
- ACL；
Gossip协议
Consul使用gossip协议去管理和广播消费给集群中的成员。gossip协议是一种去中心化的利用随机的方式在节点之间进行信息交换的协议。
Gossip in Consul
- Consul提供两个不同的gossip池，LAN和WAN。单个数据中心的所有Client和Server作为LAN pool的成员。LAN pool被用于服务发现，提供可靠和快速的事件广播。
- WAN被用于数据中心间的服务发现，每个数据中心的所有的server是WAN pool的成员。
共识协议 - Raft
Raft相关术语：
-
log - Raft系统中的主要工作单元。一致性问题可以分解为日志复制。一条日志有序的
Entries序列，Entries包括了一些集群的变动：增加节点、增加服务、新的kv键值对，等。如果所有成员认同entries及其顺序，就认为日志是一致的。 -
FSM - (Finite State Machine)有限状态机。一个
FSM是有限状态间转换的集合。当新日志被应用时，FSM被允许状态之间的转换。同一应用中相同序列的logs必须导致相同的结果，意味行为必须是明确的。 -
Peer set - 参与日志服务的成员集。所有本地数据中心的节点都在对等集中。The peer set is the set of all members participating in log replication.
-
Quorum - A quorum is a majority of members from a peer set: for a set of size n, quorum requires at least (n/2)+1 members.
-
Committed Entry - 当
entry被存储到法定数量的节点上，那么认定为该entry已提交。 -
Leader - 在给定的时间内（任期），Leader的职责是：负责摄取新的
log entries，同步给followers，以及管理entry何时被提交。
Raft in Consul
- 只有Consul Server节点参与Raft是
Peer set的成员。所有的Client节点转发请求给servers。这么做主要是防止集群数量大导致Quorum变大，等待log entry被确认提交的性能问题。 - 当启动时，一个Consul Sever会转变为
bootstrap的模式，允许将自己选举为Leader。这么做是为了保证一致性和安全性。 - 当一个请求被打倒非主节点的server，这个请求会被转发给leader。如果这个请求是个
query类型（只读），那么这个leader将基于当前的FSM的状态获取结果。如果这个请求是transaction类型(修改状态)，那么leader会获取一个新log entry并且通过Raft应用它，一旦log entry被提交到FSM，表示修改事务完成。 - 由于Raft复制的本质，对网络延迟特别敏感。每个数据中心会选举一个独立的leader。当接收到一个远程数据中心的请求，这个请求会被转发给正确的leader。
小结
log作为Consul主要的工作单元，也是存储单元。FSM可以更具当前的状态+新的更新操作生成新的log，并将log同步给follower节点，当同步的节点数达到Quorum法定数量及表示此次transaction完成。
ACL
Consul的安全机制旨在提供：机密性、完整性、和身份验证。Cosul依赖轻量级的gossip机制和一个rpc系统提供多个功能。
Serf - serf使用一个对称秘钥或共享密码，密码系统。how to enable Serf's gossip encryption in Consul
RPC System - 支持用支持端到端的可选的身份验证系统的TLS。
Secure Configuration
- ACLs enabled with default deny. Consul must be configured to use ACLs with a whitelist (default deny) approach. This forces all requests to have explicit anonymous access or provide an ACL token.
- Encryption enabled. TCP and UDP encryption must be enabled and configured to prevent plaintext communication between Consul agents. At a minimum, verify_outgoing should be enabled to verify server authenticity with each server having a unique TLS certificate. verify_server_hostname is also required to prevent a compromised agent restarting as a server and being given access to all secrets.
Threat Model
The following are parts of the Consul threat model:
- 对传输(TCP&UDP)进行加密保证Consul agent之间的通信是安全的，不会被窃听。
- 通过配置证书保证Consul Server之间的通信始终是加密的。
- 防止数据篡改。
- 启动了默认deny模式的ACL支持无需身份验证或授权即可访问数据。
- 丢失格式错误的消息。
- 所有服务器必须加入集群（具有适当的身份验证和授权），才能通过TLS进行Raft数据进行传输。
- 防止针对节点的DoS攻击。
The following are not part of the Consul threat model for Consul server agents:
- 所有的Consul Server都会将真个Consul的状态持久化到数据目录。这些数据包括：所有kv、服务注册、ACL令牌、CA配置等。允许攻击者读取或者篡改本地的数据。
- Consul可以通过ACL系统进行控制。攻击者可以通过修改配置并通过禁用ACL系统获取Consul的所有数据。
- 可以通过检查正在运行的Consul服务代理内存状态，泄漏Consul的加密性。
The following are not part of the Consul threat model for Consul client agents:
- Consul client会使用数据目录缓存本地状态，包括：本地的服务、获取的ACL Tokens、TLS连接证书以及更多。
- Consul client配置文件包含services的地址和端口、获取的缺省ACL Token以及更多。可以通过修改配置注册新的服务。
- 服务和感知代理之间的通信通常是未加密的。
- 连接代理或是本地集成的服务必须提供有效的端证书。
总结：
具体原因还是未知
