如何使用Hashicorp工具创建安全的边缘基础设施-51CTO.COM

译者 | 李睿

审校 | 重楼

本文解释了如何使用HashiCorp的堆栈构建一个安全的平台；许多步骤都有良好的文档记录。我们将详细强调最关键的部分，解释在哪里发现问题以及如何解决问题，并在官方教程中保留参考资料，以防止本文过长且难以理解。

物理架构

如下图所示，我们想要实现的物理架构由五个节点的Consul和Nomad集群组成：其中三个是配置为高可用性(HA)的控制平台节点，其余两个是数据平台节点。

考虑到我们处于边缘环境，安装集群服务器的最终位置至关重要：

控制平台节点(服务器)分布在展会展馆或安装在主楼的专用机柜上。
数据平台节点(客户端)位于每个展馆。

在默认情况下，服务器的角色是维护集群的状态，而客户机则为物理上位于群集附近的用户提供服务。

基本要求及节点部署

在自动化和虚拟化时代，继续前进的方法是创建一个“测试并销毁”的虚拟化环境，以便在进入生产环境之前尝试配置，并在物理基础设施上部署所有内容。

DevOps工具箱由Ansible、Terraform和Git等工具组成，在构建如此复杂的环境的过程中，它一直是一个严格的配置和流程要求。Ansible Vault是我们的选择，以确保与特定环境相关的敏感内容(如密码、密钥、配置变量和引导令牌或TLS证书)受到保护和加密，而不是以纯文本形式从我们存储用于构建基础设施的代码的Git存储库中可见。

我们首先创建五台虚拟机。对于测试使用了以下规范：

操作系统：Ubuntu 22.04 LTS
磁盘：20GB
内存：2GB
vCPU：2

用户可以选择其喜欢的公共云提供商，在那里部署大量的虚拟机与Terraform。或者，为了加快部署过程，可以使用VirtualBox和Vagrant在他们的笔记本电脑上创建它们，但最终，将得到一个与此类似的Ansible清单：

YAML
 all:
 children:
 cluster_role_server:
 hosts:
 node-1:
 node-2:
 node-3:
 cluster_role_client:
 hosts:
 node-4:
 vars: 
 placement: "pavilion-1"
 node-5:
 vars: 
 placement: "pavilion-2"

配置Consul和Nomad集群

在这个引导阶段，开源Ansible社区提供了一个经过广泛测试的、安全的公共剧本。得益于Ansible Galaxy实用程序，我们可以提取两个角色的代码，分别部署Consul和Nomad。

我们将上述角色制作成一个专有的剧本，首先，使用虚拟网络接口配置和设置服务器网络。该接口映射到保留IP地址169.254.1.1，用于解析集群中的*.consol域名，我们称其为dummy0接口。我们依靠Ansible在目标节点上配置它，最后，我们将在每台服务器上有以下文件：/etc/systemd/network/dummy0.network:：

Shell
[Match]
 Name=dummy0

 [Network]
 Address=169.254.1.1/32
 
 # We want these domains
 Domains=~consul.

 # To go to the consul DNS server we'll bind to this address
 DNS=169.254.1.1

此外，公共剧本还在服务器上配置了一些基本的自定义，比如更新操作系统、设置节点用户导入相关的SSH authorized_keys、安装容器运行时以及一些调试CLI工具。

最后，应该通过设置适当的Ansible变量来注意配置Consul和Nomad角色。它们的大多数名称是不言自明的，但是必须指定consul_version和nomad_version(在本例中分别为1.12.2和1.2.8)。三个客户机节点应该使用consul_node_role和nomad_node_role变量，而其他节点应该使用服务器变量。另一个需要设置的有用变量是nomad_cni_enable:true，否则，将不得不人工在任何Nomad节点上安装CNI。

通过这种方式，我们还能够以最小的工作量支持不同环境库存的快速供应和部署，从生产裸服务器或边缘的cloudlet到在云中开发和测试虚拟机。

配置Vault群集

此时，我们已经为Consul+Nomad集群做好了准备，应该能够访问各自的用户界面（UI）并启动一些测试工作负载。如果一切正常，那么就是配置Vault集群的时候了。为了简单起见，它将被安装在运行Nomad和Consul控制平台的高可用性（HA）服务器节点上。

如果是Vault初学者，可以从这里开始进行尝试，然后可以移动到Ansible Vault角色来安装这个组件，但是在进入剧本之前，需要一些人工步骤来为我们的Vault集群引导PKI。

如果企业提供现有的PKI配置，可以依赖它。这里，我们将从头开始，创建根证书(CA)颁发机构和证书。

首先，创建根密钥(这是CA私钥，可用于签署证书请求)，然后使用根密钥创建需要分发给所有必须信任客户端的根证书，可以根据需要调整-days标志的值。

Shell 
 openssl genrsa -aes256 -out rootCA.key 4096
 openssl req -x509 -new -key rootCA.key -sha256 -days 1024 -out rootCA.crt

必须在提示符上自定义字段，例如，使用如下内容：C=IT, O=CompanyName, CN=company.com/emailAddress=example@company.com，并可选地检查根CA证书:

Shell 
 openssl x509 -in rootCA.crt -text

此时，我们需要为每个服务器、设备或应用程序创建证书，这些服务器、设备或应用程序需要通过CA信任的证书公开TLS加密的服务。在本例中，我们将把该证书分配给Vault集群，因此将在每个Vault节点上使用相同的证书。

Shell
 openssl genrsa -out vault.key 4096
 # create the Certificate Signing Request (csr)
 openssl req -new -sha256 \
 -key vault.key \
 -subj "/C=IT/ST=TN/O=Tofane/CN=vault.service.consul" \
 -out vault.csr
 # finally verify the CSR's content
 openssl req -in vault.csr -noout -text

要完成这一过程，使用所有可选名称(可以是URL或IP)创建一个extfile；在本例中，使用每个Vault节点的IP，然后使用CSR和密钥以及CA根密钥生成证书。

Shell 
echo "subjectAltName=DNS:*.vault.service.consul,IP:10.231.0.72,IP:10.231.0.71,IP:10.231.0.73" >> extfile.cnf
 # optionally, if you want to use the csr also for authentication
 echo extendedKeyUsage = serverAuth >> extfile.cnf
 openssl x509 -req -in vault.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out vault.crt -extfile extfile.cnf -days 365 -sha256
 # verify the certificate content
 openssl x509 -in vault.crt -text -noout

除其他次要文件外，现在应确保在当前工作文件夹中包含以下生成的文件：

rootCA.crt 
vault.crt 
vault.key

PKI文件必须通过专用变量传递给Ansible角色以及下面建议的一些其他配置，然后通过将Vault角色分配给服务器节点来启动Vault配置。

YAML 
 vault_backend: consul
 vault_consul: 169.254.1.1:8500
 vault_iface: "{{ ansible_default_ipv4.interface }}"
 vault_listener_localhost_enable: true
 vault_tls_disable: 0
 vault_tls_src_files: "ANSIBLE_RELATIVE_PATH_TO_YOUR_CERT_FILES"
 vault_tls_cert_file: "vault.crt"
 vault_tls_key_file: "vault.key"
 vault_tls_ca_file: "rootCA.crt"

如果使用自签名CA，还需要一个步骤：必须将其复制并安装到每个节点中，可以通过以下方法轻松完成此任务：

Shell
 sudo cp rootCA.crt /usr/local/share/ca-certificates/
 sudo update-ca-certificates

最后，初始化Vault集群，打开它，使用初始化阶段返回的令牌登录，并检查它的状态;如果一切正常，那么转到下一个陷阱：在新的集群上启用和配置TLS。

Shell 
 vault operator init
 vault operator unseal
 vault login
 vault status

配置TLS

在本节中，将详细介绍为在集群中运行的基础设施组件(例如Consul和Nomad代理)和应用程序容器启用安全集群通信的过程。因此，我们将在mTLS验证之上，使用TLS加密和服务验证来保护Consul Agent通信。这可以使用从Vault集群生成的证书来完成；此外，在本例中，证书将在服务器上通过Consul Template分发，在客户端通过自动加密方法分发。

需求

所有与证书更新和Consul、Nomad代理以及Vault之间的轮换相关的秘诀都掌握在Consul Template所需的组件中。可以分享一下GitHub页面的参考，并简要地给一些关于如何安装和配置它的提示，因为到目前为止，在网上找不到完整的指南：

在每个集群节点的主节点中下载并解压缩二进制文件

Shell 
  ansible all -m shell -a 'sudo apt-get install unzip; CT_V=0.29.0; \
 curl -O https://releases.hashicorp.com/consul-template/${CT_V}/consul-template_${CT_V}_linux_amd64.zip; \
 unzip consul-template_${CT_V}_linux_amd64.zip; \
 sudo mv consul-template /usr/local/bin/'

在systemd的每个节点上创建单元文件：

Shell 
 ansible all -m shell -a "sudo bash -c 'cat <<EOF > /etc/systemd/system/consul-template.service
 [Unit]
 Descriptinotallow=consul-template
 Documentatinotallow=https://github.com/hashicorp/consul-template
 Wants=network-online.target
 After=network-online.target

 [Service]
 Envirnotallow=/etc/environment
 ExecStart=/usr/local/bin/consul-template -config /etc/consul-template.d
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=process
 KillSignal=SIGINT
 Restart=on-failure
 RestartSec=42s

 [Install]
 WantedBy=multi-user.target

 EOF '"

最后，将其提升为systemd下的系统服务，并为consul-template配置文件创建一个文件夹。

Shell 
 ansible all -m shell -a "sudo systemctl daemon-reload"
 ansible all -m shell -a \
 'sudo mkdir -p /etc/consul-template.d; \
 sudo chgrp consul /etc/consul-template.d'

Consul模板的主框架现在准备好了。在接下来的步骤中，需要做的就是为每个请求证书轮换的服务创建配置文件和模板文件。

配置Consul TLS和Consul Connect

可以很容易地遵循下面的循序渐进的教程，这些教程非常详细，只需要针对具体情况进行微小而明显的调整：

配置Vault的PKI机密引擎。
配置Vault为Consul的CA，在每个节点上安装Consul中间CA。
生成服务器证书。

现在，在继续Consul配置之前，我们需要启用和配置Consul Connect功能，为此，我们首先需要启用Vault作为Consul Connect认证机构提供商：Consul Connect创建的服务网格网络中使用的证书将由Vault生成和管理。跳转到以下教程，并确保选择“自我管理”选项卡下的说明：Vault作为领事服务网格认证机构提供商。

此时，需要通过以下方式配置Consul：首先在/opt/consult/agent certs/下的客户端和服务器上分发引导证书，然后使用update-ca-certificates实用程序将Consul中间CA安装到每个节点中，其方法与我们在上一节中对Vault CA所做的类似。对于这些步骤，可以轻松地遵循Configure Consul教程。

现在已经在节点上分发了引导证书，可以通过将Consul配置分别放置在/etc/Consul中的服务器和客户端上。首先在服务器上启用TLS，然后在客户端上启用TLS。d/folder并重新启动Consul代理。

enable-tls-server.hcl
YAML 
 1 verify_incoming = true
2 verify_outgoing = true
3 verify_server_hostname = true
4 ca_file = "/opt/consul/agent-certs/ca.crt"
5 cert_file = "/opt/consul/agent-certs/agent.crt"
6 key_file = "/opt/consul/agent-certs/agent.key"
7
8 auto_encrypt {
9 allow_tls = true
10 }enable-tls-client.hcl 
enable-tls-client.hcl

YAML 
 verify_incoming = false
 verify_outgoing = true
 verify_server_hostname = true
 ca_file = "/opt/consul/agent-certs/ca.crt"
 auto_encrypt {
 tls = true
 ip_san = ["169.254.1.1"]
 }

在每个节点上重新启动Consul代理，TLS上的API应位于https://169.254.1.1:8501，但仍然需要通过Consul模板配置证书续订，并设置mTLS身份验证。

配置Consul模板页面将指导设置模板文件，这里应该注意一个小细节：鉴于在我们的集群中，Consul代理正在监听特殊的dummy0接口，我们需要通过模板机制创建适当的证书，在每个模板文件中添加自定义的ip_sans。为方便起见，以下是服务器代理证书的模板示例：

Plain Text 
{{ with secret "pki_consul_int/issue/consul-tofane" "common_name=server.tofane.consul" "ttl=24h" "alt_names=localhost" "ip_sans=169.254.1.1"}}
{{ .Data.certificate }}
{{ end }}

最后，只需要创建一个consul-template配置文件，这里唯一的建议是对服务器节点使用address="http://localhost:8200"和address="https://active.vault.service。Consul:客户节点为8200英寸。通过这种方式，服务器将拥有更稳定的配置，因为在Consul无法工作和DNS解析不可用的情况下，与Vault的通信也可以工作。

要执行最终检查TLS证书轮换是否按预期工作，应该等待24小时，等待在Vault中创建证书时选择的TTL。测试每个节点上已覆盖的证书可以用这个相当简单的Ansible命令完成。

Shell 
 Ansibleall-mshell-a'sudols-la/opt/consul/agent-certs/'

此外，还可以使用OpenSSL，检查RPC或API端口上使用的证书。

Shell 
 openssl s_client -connect $CONSUL_NODE_LAN_IP:8300 2>/dev/null | less
 openssl s_client -connect 169.254.1.1:8501 2>/dev/null | less

最后，尝试使用来自服务器节点的正确证书在API上进行连接。

Shell 
 consul members -http-addr="https://169.254.1.1:8501" \
 -ca-file="/opt/consul/agent-certs/ca.crt" \
 -client-cert="/opt/consul/agent-certs/agent.crt" \
 -client-key="/opt/consul/agent-certs/agent.key"

配置Nomad TLS

将Nomad配置为使用TLS的过程非常简单，因为我们需要执行与Consul配置相同的步骤。供参考的官方教程是使用Vault为Nomad生成mTLS证书，我们将在下面描述一些将省去一些麻烦的调整。

首先，就像我们为Consul所做的那样，在Consul模板中，我们需要添加ip_sans，但在这种情况下，我们还需要添加127.0.0.1，因为Nomad也将在该接口上从服务(例如:Nomad Autoscaler)联系。以下是我们的例子：

Plain Text
{{ with secret "pki_nomad_int/issue/nomad-cluster" "common_name=server.global.nomad" "ttl=24h" "alt_names=localhost" "ip_sans=127.0.0.1,169.254.1.1"}}
{{ .Data.certificate }}
{{ end }}

值得注意的是，Nomad的Consul模板配置可以附加到现有的配置文件中，因为我们已经将其用于Consul了。

假设Consul Template将用于从不同的Vault路径检索Consul和Nomad证书，最好创建一个新策略，并创建一个具有这两种权限的新令牌。

Shell 
 vault token create -policy=nomad -policy=connect-ca

当然，这个令牌必须在每个节点上的Consul Template配置文件中替换。

就像我们为Consul所做的那样，为了方便，我们共享了应该放在/etc/nomad中的文件。d/以便在服务器节点上启用NomadTLS。对于客户机节点，只需删除最后一行。

enable-tls-server.hcl
YAML
 tls {
 http = true
 rpc = true

 ca_file = "/opt/nomad/agent-certs/ca.crt"
 cert_file = "/opt/nomad/agent-certs/agent.crt"
 key_file = "/opt/nomad/agent-certs/agent.key"

verify_server_hostname = true
 verify_https_client = true

rpc_upgrade_mode = true
 }

当第一次重新加载Nomad代理时，记住在服务器节点上将rpc_upgrade_mode选项更改为false，以便Nomad服务器将只接受TLS连接，然后再次重新启动服务。

Shell
 ansible core_cluster_role_server -m shell -a \ 'sudo sed -i "s/rpc_upgrade_mode = true/rpc_upgrade_mode = false/g" /etc/nomad.d/enable-tls-server.hcl'
 ansible core_cluster_role_server -m shell -a \ 'sudo systemctl restart nomad'

只需要几个步骤就可以完全完成Nomad配置:i)允许访问webUI,ii)启用边车使用TLS，以及iii)测试是否一切都按预期工作。

启用TLS时，为了访问Web-UI，需要在服务器上将verify_https_client设置为false，并重新启动nomad服务。要了解更多信息，发现这篇文章非常有用。

Shell
 ansible core_cluster_role_server -m shell -a \
 'sudo sed -i "s/verify_https_client = true/verify_https_client = false/g" /etc/nomad.d/enable-tls-server.hcl; \
 sudo systemctl restart nomad'

现在应该能够连接到https://localhost:4646/ui，但是要记住的是，对于生产环境，应该使用Vault根CA配置其浏览器，以便提供受支持的对等身份验证。

第二步是让边车使用Consul connect提供的TLS保护网格：为了初始化TLS保护网格中的通道，Nomad需要与Consul通信，并在边车中注入正确的证书，以建立受保护的连接。

为此，更新/etc/nomad.d/base.中的Nomad配置并允许Nomad通过TLS与Consul API通信，添加以下行：

Shell 
 address = "169.254.1.1:8501"
 ssl = true ca_file = "/opt/consul/agent-certs/ca.crt"
 cert_file = ""
 key_file = ""

希望是到了最后的测试阶段。实际上，如果输入了nomad status命令，会收到一个错误消息，因为需要正确配置CLI。

导出端点和证书变量：

Shell
 export NOMAD_ADDR=https://localhost:4646
 export NOMAD_CACERT="/opt/nomad/agent-certs/ca.crt"
 export NOMAD_CLIENT_CERT="/opt/nomad/cli-certs/cli.crt"
 export NOMAD_CLIENT_KEY="/opt/nomad/cli-certs/cli.key"

最后，通过TLS再次检查状态，nomadstatus命令现在应该无缝工作了。

配置Consul ACL

下面的最后一步将在我们的集群上启用Consul访问控制列表系统。该任务的主要参考资料是HashiCorp关于引导ACL系统的教程。

启用ACL

在启用ACL系统的过程中，遇到了一个小问题，如果多个节点同时处于活动状态，则无法引导它。小问题可以用简单的解决方案解决：为什么不在启用ACL之前暂时将集群缩小到一个节点?作为“懒惰的开发人员”，所以一个粗糙但有效的bash循环和SSH帮助我们做到了这一点：

Shell
 # server nodes
 S_L="node-1 node-2 node-3"
 # client nodes
 C_L="node-4 node-5"

 for i in ${S_L#* } $C_L;
 do echo "R $i"
 ssh -t $i consul leave
 done

现在复制以下Consul HCL配置文件，然后将ACL引导到单节点Consul集群中：

enable-acl.hcl
YAML
 acl = {
 enabled = true
 #default_policy = "deny"
 default_policy = "allow"
 enable_token_persistence = true
 }

Shell
1 FIRST=node-1
2 echo "R $FIRST"
3 scp enable-acl.hcl $FIRST:/var/tmp/enable-acl.hcl
4 ssh $FIRST sudo install --owner consul --group consul /var/tmp/enable-acl.hcl /etc/consul.d/enable-acl.hcl
5 ssh -t $FIRST sudo systemctl restart consul.service

Consul将回复一条成功的消息，并允许我们继续保存Consul引导令牌，并通过重新启动Consul代理将其他节点重新加入原始集群。

Shell
# save consul bootstrap token
 sudo consul acl bootstrap -format json 2>&1 | tee consul-acl-bootstrap.token CONSUL_HTTP_TOKEN=$(cat consul-acl-bootstrap.token | jq -r '.SecretID') export CONSUL_HTTP_TOKEN

 # restore cluster nodes
 for i in ${S_L#* } $C_L; do
 echo "R $i"
 scp enable-acl.hcl $i:/var/tmp/enable-acl.hcl
 ssh $i sudo install --owner consul --group consul /var/tmp/enable-acl.hcl /etc/consul.d/enable-acl.hcl 
 ssh -t $i sudo systemctl restart consul.service
 done

此时，如果集群中只有服务器节点可用(使用:consul成员进行检查)，并且看到Vault、Consul和Nomad代理不再工作；这很正常，因为它们没有适当的ACL策略和相对令牌。按照下面的步骤，将修复它。

ACL与Vault集成

与Vault的集成非常简单。只需要从适当的Consul策略生成一个令牌，并再次运行Ansible Vault角色，在设置一个额外的Ansible额外变量后，一次更新所有的节点：

YAML 
vault_consul_token: "YOUR_TOKEN_HERE"

与Consul和Nomad代理集成ACL

与其他组件的集成可以遵循官方教程按照以下顺序轻松完成。

（1）为Consul节点和代理创建规则、策略和令牌。

（2）为用户界面（UI）创建规则、策略和令牌。

（3）为DNS创建规则、策略和令牌；为简单起见，我们只是将这个策略与点1)处的策略合并，并为下面模板开始的每个节点生成：

JSON
node "NODE-NAME" {
 policy = "write"
 }
 service_prefix "" {
 policy = "read"
 }
 node_prefix "" {
 policy = "read"
 }
 service_prefix "" {
 policy = "read"
 }
 query_prefix "" {
 policy = "read"
 }
 agent "NODE-NAME" {
 policy = "write"
 }

（4）为Nomad创建规则、策略和令牌

ACL策略完全启用

现在强制ACL在默认情况下拒绝通信，最后在每个节点上重新启动Consul。

Shell
 ansible all -m shell -a "\ sudo sed -i \
 's/default_policy = \"allow\"/#default_policy = \"allow\"/g' /etc/consul.d/enable-acl.hcl"
 ansible all -m shell -a "\ sudo sed -i \
 's/#default_policy = \"deny\"/default_policy = \"deny\"/g' /etc/consul.d/enable-acl.hcl"
 ansible all -m shell -a "sudo systemctl restart consul"

结论

此时，基于HashiCorp产品的“安全边缘基础设施”应该已经启动并运行，可以开始安装首选的工作负载。在这个例子中，在这个部署上安装了一层中间件，支持负载平衡、监视和自动扩展等特性。为了实现最后一个目标，我们分别使用Traefik、Prometheus和Nomad自动扩展器，可以想象，为了让这些工具在完整的TLS基础设施上正常工作，还需要额外的配置，但这将是另一篇文章的主题。

总之，我们分享这项工作的可能演变，我们认为这是很自然的：鉴于在跨组件的通信和身份验证方面，基础设施被认为是相当安全的，为什么不将其用作构建混合基础设施的支柱，其中控制平台节点位于所选择的云中，而数据平台服务器位于边缘?

有了这样的架构，将拥有一个毫无疑问的优势，即能够通过一个控制平台来控制多个边缘站点，从而消除开销，并实现企业的规模经济。当然，应该对系统进行适当的分区，以支持多租户，这肯定是下一个令人兴奋的项目。

原文标题：How To Use Hashicorp Tools To Create a Secured Edge Infrastructure，作者：Daniele Santoro