譯者 | 李睿

審校 | 重樓?

本文解釋了如何使用HashiCorp的堆棧構(gòu)建一個安全的平臺；許多步驟都有良好的文檔記錄。我們將詳細強調(diào)最關(guān)鍵的部分，解釋在哪里發(fā)現(xiàn)問題以及如何解決問題，并在官方教程中保留參考資料，以防止本文過長且難以理解。?

物理架構(gòu)

如下圖所示，我們想要實現(xiàn)的物理架構(gòu)由五個節(jié)點的Consul和Nomad集群組成：其中三個是配置為高可用性(HA)的控制平臺節(jié)點，其余兩個是數(shù)據(jù)平臺節(jié)點。 ?

考慮到我們處于邊緣環(huán)境，安裝集群服務(wù)器的最終位置至關(guān)重要：?

• 控制平臺節(jié)點(服務(wù)器)分布在展會展館或安裝在主樓的專用機柜上。 ?
• 數(shù)據(jù)平臺節(jié)點(客戶端)位于每個展館。 ?

在默認情況下，服務(wù)器的角色是維護集群的狀態(tài)，而客戶機則為物理上位于群集附近的用戶提供服務(wù)。?

基本要求及節(jié)點部署

在自動化和虛擬化時代，繼續(xù)前進的方法是創(chuàng)建一個“測試并銷毀”的虛擬化環(huán)境，以便在進入生產(chǎn)環(huán)境之前嘗試配置，并在物理基礎(chǔ)設(shè)施上部署所有內(nèi)容。?

DevOps工具箱由Ansible、Terraform和Git等工具組成，在構(gòu)建如此復(fù)雜的環(huán)境的過程中，它一直是一個嚴格的配置和流程要求。Ansible Vault是我們的選擇，以確保與特定環(huán)境相關(guān)的敏感內(nèi)容(如密碼、密鑰、配置變量和引導(dǎo)令牌或TLS證書)受到保護和加密，而不是以純文本形式從我們存儲用于構(gòu)建基礎(chǔ)設(shè)施的代碼的Git存儲庫中可見。 ?

我們首先創(chuàng)建五臺虛擬機。對于測試使用了以下規(guī)范：?

• 操作系統(tǒng)：Ubuntu 22.04 LTS?
• 磁盤：20GB ?
• 內(nèi)存：2GB ?
• vCPU：2?

用戶可以選擇其喜歡的公共云提供商，在那里部署大量的虛擬機與Terraform。或者，為了加快部署過程，可以使用VirtualBox和Vagrant在他們的筆記本電腦上創(chuàng)建它們，但最終，將得到一個與此類似的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集群

在這個引導(dǎo)階段，開源Ansible社區(qū)提供了一個經(jīng)過廣泛測試的、安全的公共劇本。得益于Ansible Galaxy實用程序，我們可以提取兩個角色的代碼，分別部署Consul和Nomad。 ?

我們將上述角色制作成一個專有的劇本，首先，使用虛擬網(wǎng)絡(luò)接口配置和設(shè)置服務(wù)器網(wǎng)絡(luò)。該接口映射到保留IP地址169.254.1.1，用于解析集群中的*.consol域名，我們稱其為dummy0接口。我們依靠Ansible在目標節(jié)點上配置它，最后，我們將在每臺服務(wù)器上有以下文件：/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

此外，公共劇本還在服務(wù)器上配置了一些基本的自定義，比如更新操作系統(tǒng)、設(shè)置節(jié)點用戶導(dǎo)入相關(guān)的SSH authorized_keys、安裝容器運行時以及一些調(diào)試CLI工具。 ?

最后，應(yīng)該通過設(shè)置適當?shù)腁nsible變量來注意配置Consul和Nomad角色。它們的大多數(shù)名稱是不言自明的，但是必須指定consul_version和nomad_version(在本例中分別為1.12.2和1.2.8)。三個客戶機節(jié)點應(yīng)該使用consul_node_role和nomad_node_role變量，而其他節(jié)點應(yīng)該使用服務(wù)器變量。另一個需要設(shè)置的有用變量是nomad_cni_enable:true，否則，將不得不人工在任何Nomad節(jié)點上安裝CNI。?

通過這種方式，我們還能夠以最小的工作量支持不同環(huán)境庫存的快速供應(yīng)和部署，從生產(chǎn)裸服務(wù)器或邊緣的cloudlet到在云中開發(fā)和測試虛擬機。?

配置Vault群集

此時，我們已經(jīng)為Consul+Nomad集群做好了準備，應(yīng)該能夠訪問各自的用戶界面（UI）并啟動一些測試工作負載。如果一切正常，那么就是配置Vault集群的時候了。為了簡單起見，它將被安裝在運行Nomad和Consul控制平臺的高可用性（HA）服務(wù)器節(jié)點上。 ?

如果是Vault初學(xué)者，可以從這里開始進行嘗試，然后可以移動到Ansible Vault角色來安裝這個組件，但是在進入劇本之前，需要一些人工步驟來為我們的Vault集群引導(dǎo)PKI。 ?

如果企業(yè)提供現(xiàn)有的PKI配置，可以依賴它。這里，我們將從頭開始，創(chuàng)建根證書(CA)頒發(fā)機構(gòu)和證書。 ?

首先，創(chuàng)建根密鑰(這是CA私鑰，可用于簽署證書請求)，然后使用根密鑰創(chuàng)建需要分發(fā)給所有必須信任客戶端的根證書，可以根據(jù)需要調(diào)整-days標志的值。 ?

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

必須在提示符上自定義字段，例如，使用如下內(nèi)容：C=IT, O=CompanyName, CN=company.com/emailAddress=example@company.com，并可選地檢查根CA證書:?

Shell 
 openssl x509 -in rootCA.crt -text

此時，我們需要為每個服務(wù)器、設(shè)備或應(yīng)用程序創(chuàng)建證書，這些服務(wù)器、設(shè)備或應(yīng)用程序需要通過CA信任的證書公開TLS加密的服務(wù)。在本例中，我們將把該證書分配給Vault集群，因此將在每個Vault節(jié)點上使用相同的證書。?

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)創(chuàng)建一個extfile；在本例中，使用每個Vault節(jié)點的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

除其他次要文件外，現(xiàn)在應(yīng)確保在當前工作文件夾中包含以下生成的文件：?

rootCA.crt 
vault.crt 
vault.key

PKI文件必須通過專用變量傳遞給Ansible角色以及下面建議的一些其他配置，然后通過將Vault角色分配給服務(wù)器節(jié)點來啟動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，還需要一個步驟：必須將其復(fù)制并安裝到每個節(jié)點中，可以通過以下方法輕松完成此任務(wù)：?

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

最后，初始化Vault集群，打開它，使用初始化階段返回的令牌登錄，并檢查它的狀態(tài);如果一切正常，那么轉(zhuǎn)到下一個陷阱：在新的集群上啟用和配置TLS。?

Shell 
 vault operator init
 vault operator unseal
 vault login
 vault status

配置TLS

在本節(jié)中，將詳細介紹為在集群中運行的基礎(chǔ)設(shè)施組件(例如Consul和Nomad代理)和應(yīng)用程序容器啟用安全集群通信的過程。因此，我們將在mTLS驗證之上，使用TLS加密和服務(wù)驗證來保護Consul Agent通信。這可以使用從Vault集群生成的證書來完成；此外，在本例中，證書將在服務(wù)器上通過Consul Template分發(fā)，在客戶端通過自動加密方法分發(fā)。 ?

需求

所有與證書更新和Consul、Nomad代理以及Vault之間的輪換相關(guān)的秘訣都掌握在Consul Template所需的組件中。可以分享一下GitHub頁面的參考，并簡要地給一些關(guān)于如何安裝和配置它的提示，因為到目前為止，在網(wǎng)上找不到完整的指南： ?

在每個集群節(jié)點的主節(jié)點中下載并解壓縮二進制文件?

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的每個節(jié)點上創(chuàng)建單元文件：?

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下的系統(tǒng)服務(wù)，并為consul-template配置文件創(chuàng)建一個文件夾。?

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模板的主框架現(xiàn)在準備好了。在接下來的步驟中，需要做的就是為每個請求證書輪換的服務(wù)創(chuàng)建配置文件和模板文件。?

配置Consul TLS和Consul Connect

可以很容易地遵循下面的循序漸進的教程，這些教程非常詳細，只需要針對具體情況進行微小而明顯的調(diào)整：?

• 配置Vault的PKI機密引擎。 ?
• 配置Vault為Consul的CA，在每個節(jié)點上安裝Consul中間CA。?
• 生成服務(wù)器證書。?

現(xiàn)在，在繼續(xù)Consul配置之前，我們需要啟用和配置Consul Connect功能，為此，我們首先需要啟用Vault作為Consul Connect認證機構(gòu)提供商：Consul Connect創(chuàng)建的服務(wù)網(wǎng)格網(wǎng)絡(luò)中使用的證書將由Vault生成和管理。跳轉(zhuǎn)到以下教程，并確保選擇“自我管理”選項卡下的說明：Vault作為領(lǐng)事服務(wù)網(wǎng)格認證機構(gòu)提供商。?

此時，需要通過以下方式配置Consul：首先在/opt/consult/agent certs/下的客戶端和服務(wù)器上分發(fā)引導(dǎo)證書，然后使用update-ca-certificates實用程序?qū)onsul中間CA安裝到每個節(jié)點中，其方法與我們在上一節(jié)中對Vault CA所做的類似。對于這些步驟，可以輕松地遵循Configure Consul教程。?

現(xiàn)在已經(jīng)在節(jié)點上分發(fā)了引導(dǎo)證書，可以通過將Consul配置分別放置在/etc/Consul中的服務(wù)器和客戶端上。首先在服務(wù)器上啟用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"]
 }

在每個節(jié)點上重新啟動Consul代理，TLS上的API應(yīng)位于https://169.254.1.1:8501，但仍然需要通過Consul模板配置證書續(xù)訂，并設(shè)置mTLS身份驗證。

配置Consul模板頁面將指導(dǎo)設(shè)置模板文件，這里應(yīng)該注意一個小細節(jié)：鑒于在我們的集群中，Consul代理正在監(jiān)聽特殊的dummy0接口，我們需要通過模板機制創(chuàng)建適當?shù)淖C書，在每個模板文件中添加自定義的ip_sans。為方便起見，以下是服務(wù)器代理證書的模板示例：?

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 }}

最后，只需要創(chuàng)建一個consul-template配置文件，這里唯一的建議是對服務(wù)器節(jié)點使用address="http://localhost:8200"和address="https://active.vault.service。Consul:客戶節(jié)點為8200英寸。通過這種方式，服務(wù)器將擁有更穩(wěn)定的配置，因為在Consul無法工作和DNS解析不可用的情況下，與Vault的通信也可以工作。 ?

要執(zhí)行最終檢查TLS證書輪換是否按預(yù)期工作，應(yīng)該等待24小時，等待在Vault中創(chuàng)建證書時選擇的TTL。測試每個節(jié)點上已覆蓋的證書可以用這個相當簡單的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

最后，嘗試使用來自服務(wù)器節(jié)點的正確證書在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的過程非常簡單，因為我們需要執(zhí)行與Consul配置相同的步驟。供參考的官方教程是使用Vault為Nomad生成mTLS證書，我們將在下面描述一些將省去一些麻煩的調(diào)整。?

首先，就像我們?yōu)镃onsul所做的那樣，在Consul模板中，我們需要添加ip_sans，但在這種情況下，我們還需要添加127.0.0.1，因為Nomad也將在該接口上從服務(wù)(例如:Nomad Autoscaler)聯(lián)系。以下是我們的例子：?

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模板配置可以附加到現(xiàn)有的配置文件中，因為我們已經(jīng)將其用于Consul了。?

假設(shè)Consul Template將用于從不同的Vault路徑檢索Consul和Nomad證書，最好創(chuàng)建一個新策略，并創(chuàng)建一個具有這兩種權(quán)限的新令牌。?

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

當然，這個令牌必須在每個節(jié)點上的Consul Template配置文件中替換。 ?

就像我們?yōu)镃onsul所做的那樣，為了方便，我們共享了應(yīng)該放在/etc/nomad中的文件。d/以便在服務(wù)器節(jié)點上啟用NomadTLS。對于客戶機節(jié)點，只需刪除最后一行。 ?

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
 }

當?shù)谝淮沃匦录虞dNomad代理時，記住在服務(wù)器節(jié)點上將rpc_upgrade_mode選項更改為false，以便Nomad服務(wù)器將只接受TLS連接，然后再次重新啟動服務(wù)。?

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)測試是否一切都按預(yù)期工作。 ?

啟用TLS時，為了訪問Web-UI，需要在服務(wù)器上將verify_https_client設(shè)置為false，并重新啟動nomad服務(wù)。要了解更多信息，發(fā)現(xiàn)這篇文章非常有用。?

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'

現(xiàn)在應(yīng)該能夠連接到https://localhost:4646/ui，但是要記住的是，對于生產(chǎn)環(huán)境，應(yīng)該使用Vault根CA配置其瀏覽器，以便提供受支持的對等身份驗證。?

第二步是讓邊車使用Consul connect提供的TLS保護網(wǎng)格：為了初始化TLS保護網(wǎng)格中的通道，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。?

導(dǎo)出端點和證書變量：?

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再次檢查狀態(tài)，nomadstatus命令現(xiàn)在應(yīng)該無縫工作了。 ?

配置Consul ACL

下面的最后一步將在我們的集群上啟用Consul訪問控制列表系統(tǒng)。該任務(wù)的主要參考資料是HashiCorp關(guān)于引導(dǎo)ACL系統(tǒng)的教程。 ?

啟用ACL

在啟用ACL系統(tǒng)的過程中，遇到了一個小問題，如果多個節(jié)點同時處于活動狀態(tài)，則無法引導(dǎo)它。小問題可以用簡單的解決方案解決：為什么不在啟用ACL之前暫時將集群縮小到一個節(jié)點?作為“懶惰的開發(fā)人員”，所以一個粗糙但有效的bash循環(huán)和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

現(xiàn)在復(fù)制以下Consul HCL配置文件，然后將ACL引導(dǎo)到單節(jié)點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將回復(fù)一條成功的消息，并允許我們繼續(xù)保存Consul引導(dǎo)令牌，并通過重新啟動Consul代理將其他節(jié)點重新加入原始集群。?

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

此時，如果集群中只有服務(wù)器節(jié)點可用(使用:consul成員進行檢查)，并且看到Vault、Consul和Nomad代理不再工作；這很正常，因為它們沒有適當?shù)腁CL策略和相對令牌。按照下面的步驟，將修復(fù)它。 ?

ACL與Vault集成

與Vault的集成非常簡單。只需要從適當?shù)腃onsul策略生成一個令牌，并再次運行Ansible Vault角色，在設(shè)置一個額外的Ansible額外變量后，一次更新所有的節(jié)點：?

YAML 
vault_consul_token: "YOUR_TOKEN_HERE"

與Consul和Nomad代理集成ACL

與其他組件的集成可以遵循官方教程按照以下順序輕松完成。?

（1）為Consul節(jié)點和代理創(chuàng)建規(guī)則、策略和令牌。 ?

（2）為用戶界面（UI）創(chuàng)建規(guī)則、策略和令牌。 ?

（3）為DNS創(chuàng)建規(guī)則、策略和令牌；為簡單起見，我們只是將這個策略與點1)處的策略合并，并為下面模板開始的每個節(jié)點生成： ?

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創(chuàng)建規(guī)則、策略和令牌?

ACL策略完全啟用

現(xiàn)在強制ACL在默認情況下拒絕通信，最后在每個節(jié)點上重新啟動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"

結(jié)論

此時，基于HashiCorp產(chǎn)品的“安全邊緣基礎(chǔ)設(shè)施”應(yīng)該已經(jīng)啟動并運行，可以開始安裝首選的工作負載。在這個例子中，在這個部署上安裝了一層中間件，支持負載平衡、監(jiān)視和自動擴展等特性。為了實現(xiàn)最后一個目標，我們分別使用Traefik、Prometheus和Nomad自動擴展器，可以想象，為了讓這些工具在完整的TLS基礎(chǔ)設(shè)施上正常工作，還需要額外的配置，但這將是另一篇文章的主題。 ?

總之，我們分享這項工作的可能演變，我們認為這是很自然的：鑒于在跨組件的通信和身份驗證方面，基礎(chǔ)設(shè)施被認為是相當安全的，為什么不將其用作構(gòu)建混合基礎(chǔ)設(shè)施的支柱，其中控制平臺節(jié)點位于所選擇的云中，而數(shù)據(jù)平臺服務(wù)器位于邊緣? ?

有了這樣的架構(gòu)，將擁有一個毫無疑問的優(yōu)勢，即能夠通過一個控制平臺來控制多個邊緣站點，從而消除開銷，并實現(xiàn)企業(yè)的規(guī)模經(jīng)濟。當然，應(yīng)該對系統(tǒng)進行適當?shù)姆謪^(qū)，以支持多租戶，這肯定是下一個令人興奮的項目。

原文標題：??How To Use Hashicorp Tools To Create a Secured Edge Infrastructure??，作者：Daniele Santoro