Consul
  • Consul中文文档
  • Consul介绍
    • Consul与其他软件对比
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
  • Consul 架构
    • 反熵
    • 共识协议
    • Gossip协议
    • Japsen测试
    • 网络候选人
  • Consul安全模型
    • 访问控制(ACLs)
      • ACL系统
      • ACL规则
      • ACL Auth Methods组件
    • 加密
  • 服务网格
  • 开始使用
    • 启用数据中心
由 GitBook 提供支持
在本页
  • »Gossip Encryption
  • »Configuring Gossip Encryption on an existing cluster
  • »RPC Encryption with TLS
  • »Configuring TLS on an existing cluster

这有帮助吗?

  1. Consul安全模型

加密

上一页ACL Auth Methods组件下一页服务网格

最后更新于4年前

这有帮助吗?

The Consul agent supports encrypting all of its network traffic. The exact method of encryption is described on the . There are two separate encryption systems, one for gossip traffic and one for RPC.

To configure the encryption systems on a new cluster, review this following tutorials to and .

Gossip Encryption

Enabling gossip encryption only requires that you set an encryption key when starting the Consul agent. The key can be set via the encrypt parameter.

WAN Joined Datacenters Note: If using multiple WAN joined datacenters, be sure to use the same encryption key in all datacenters.

The key must be 32-bytes, Base64 encoded. As a convenience, Consul provides the command to generate a cryptographically suitable key:

$ consul keygen
pUqJrVyVRj5jsiYEkM/tFQYfWyJIv4s3XkvDwy7Cu5s=

With that key, you can enable encryption on the agent. If encryption is enabled, the output of will include "Encrypt: true":

$ cat encrypt.json
{"encrypt": "pUqJrVyVRj5jsiYEkM/tFQYfWyJIv4s3XkvDwy7Cu5s="}

$ consul agent -data-dir=/tmp/consul -config-file=encrypt.json
==> WARNING: LAN keyring exists but -encrypt given, using keyring
==> WARNING: WAN keyring exists but -encrypt given, using keyring
==> Starting Consul agent...
==> Starting Consul agent RPC...
==> Consul agent running!
         Node name: 'Armons-MacBook-Air.local'
        Datacenter: 'dc1'
            Server: false (bootstrap: false)
       Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: -1, DNS: 8600, RPC: 8400)
      Cluster Addr: 10.1.10.12 (LAN: 8301, WAN: 8302)
    Gossip encrypt: true, RPC-TLS: false, TLS-Incoming: false
...

All nodes within a Consul cluster must share the same encryption key in order to send and receive cluster information.

Certificates need to be created with x509v3 extendedKeyUsage attributes for both clientAuth and serverAuth since Consul uses a single cert/key pair for both server and client communications.

TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP and is secured using a symmetric key. See above for enabling gossip encryption.

Configuring Gossip Encryption on an existing cluster

As of version 0.8.4, Consul supports upshifting to encrypted gossip on a running cluster through the following process. Review this to encrypt gossip on an existing cluster.

RPC Encryption with TLS

Consul supports using TLS to verify the authenticity of servers and clients. To enable this, Consul requires that all clients and servers have key pairs that are generated by a single Certificate Authority. This can be a private CA, used only internally. The CA then signs keys for each of the agents, as in .

TLS can be used to verify the authenticity of the servers or verify the authenticity of clients. These modes are controlled by the , , and options, respectively.

If is set, agents verify the authenticity of Consul for outgoing connections. Server nodes must present a certificate signed by a common certificate authority present on all agents, set via the agent's and options. All server nodes must have an appropriate key pair set using and .

If is set, then outgoing connections perform hostname verification. All servers must have a certificate valid for server.. or the client will reject the handshake. This is a new configuration as of 0.5.1, and it is used to prevent a compromised client from being able to restart in server mode and perform a MITM (Man-In-The-Middle) attack. New deployments should set this to true, and generate the proper certificates, but this is defaulted to false to avoid breaking existing deployments.

If is set, the servers verify the authenticity of all incoming connections. All clients must have a valid key pair set using and . Servers will also disallow any non-TLS connections. To force clients to use TLS, must also be set.

Configuring TLS on an existing cluster

As of version 0.8.4, Consul supports migrating to TLS-encrypted traffic on a running cluster without downtime. This process assumes a starting point with no TLS settings configured and involves an intermediate step in order to get to full TLS encryption. Review the for the step-by-step process to configure TLS on a new or existing cluster. Note the call outs there for existing cluster configuration.

step-by-step tutorial
this tutorial on generating both a CA and signing keys
verify_outgoing
verify_server_hostname
verify_incoming
verify_outgoing
ca_file
ca_path
cert_file
key_file
verify_server_hostname
verify_incoming
cert_file
key_file
verify_outgoing
Securing RPC Communication with TLS Encryption tutorial
encryption internals page
enable gossip encryption
TLS encryption for agent communication
consul keygen
consul agent
»
»
»
»