第一步：分「連不到」還是「連得到但被拒」

錯誤訊息本身就能分層，不用猜：

• 訊息提到主機名解不出、連線逾時、retrieving file 失敗 → 連不到，往網路 / DNS / mirror 查。
• 訊息提到 database lock、signature、trust、conflicting、partial → 連得到、封包也拿到了，是套件管理器的狀態問題。

判準是問一句：「它到底有沒有成功連上 mirror？」有連上才談得到簽章、相依、db 狀態；連都沒連上，那些都還輪不到。剛裝好的最小系統最常見的是前者——網路設定還沒到位。

連不到那層：從實體介面往上查到域名

網路不通有好幾層，從最底層往上逐層確認，哪一層斷了一目了然。這條鏈跟最小安裝後的驗證裡的網路檢查同源，這裡聚焦在「抓套件失敗」這個症狀上：

1ip -brief a              # 1. 有沒有拿到 IP？介面 UP 且有位址
2ping -c1 8.8.8.8         # 2. IP 層對外通不通？（直接打 IP、跳過 DNS）
3getent hosts archlinux.org   # 3. 域名解得出來嗎？
4timedatectl              # 4. 時間對嗎？（影響下一層的簽章驗證）

第 2 步通、第 3 步不通 = DNS 問題，這是最小安裝最典型的落點：IP 層明明通（ping 8.8.8.8 有回應），但域名解不出來，因為 /etc/resolv.conf 還沒設 nameserver。這時 pacman 會卡在解析 mirror 主機名。修法是給系統一個 resolver——臨時可直接寫 /etc/resolv.conf（nameserver 1.1.1.1）。先看它是什麼（ls -l /etc/resolv.conf）：啟用了 systemd-resolved 或 NetworkManager 的系統上它是那些服務管理的 symlink，手寫會被覆蓋，治本要透過該網路管理服務設定 DNS；裸 Arch 最小安裝若沒啟用這些服務，它通常就是一個普通檔案，手寫即持久生效。

mirror 逾時 / 抓不到：DNS 通了、但某個 mirror 慢或掛了。換 /etc/pacman.d/mirrorlist 到地理近且快的鏡像（實測不同 mirror 速度可差數倍）。這也接回安裝選項判讀裡選 mirror 的決策——裝機當下選錯 mirror，這裡就會慢。

連得到但被拒那層：pacman 自己的狀態

連上 mirror、封包也拿到了卻失敗，問題在 pacman 的本地狀態或簽章驗證。這幾種各有明確徵兆與修法：

database lock：上次沒清乾淨的殘留

error: failed to init transaction (unable to lock database)。pacman 用 /var/lib/pacman/db.lck 這個鎖檔保證同時只有一個 pacman 在動資料庫；上次 pacman 被中斷（斷電、Ctrl+C、當掉）沒清掉鎖檔就會殘留。先確認真的沒有 pacman 在跑（pgrep -x pacman），確認沒有再刪鎖檔：

1pgrep -x pacman && echo "有 pacman 在跑、別刪" || sudo rm /var/lib/pacman/db.lck

先查再刪這個順序重要——盲刪鎖檔時如果真的有另一個 pacman 在跑，兩個同時寫資料庫會弄壞它。

簽章 / keyring 過期：十之八九是時間不對

invalid or corrupted package (PGP signature) 或 signature is unknown trust。pacman 驗證每個套件的 GPG 簽章，驗證失敗最常見的根因是系統時間不對——這正是第一步要 timedatectl 的原因。時間差太多（新裝的 VM、主機板電池沒電的老機器）會讓「簽章的有效期」判斷錯誤，明明有效的簽章被判過期。先校時：

1sudo timedatectl set-ntp true     # 開 NTP 自動校時（SSH 進最小系統無 polkit 互動代理、裸跑會被拒，要 sudo）

時間對了還失敗，才是 keyring 本身的問題（archlinux-keyring 太舊）：sudo pacman -Sy archlinux-keyring 更新 keyring，必要時 sudo pacman-key --refresh-keys。順序是先校時再動 keyring，因為時間不對時連 keyring 都更新不了。

partial upgrade：只同步不升級造成的相依斷裂

conflicting dependencies 或裝完某個套件後系統行為異常。根因是在 rolling 發行版上只做了 pacman -Sy（同步資料庫）就裝新套件，卻沒 -u（升級既有套件）——新套件依賴新版函式庫，但系統還是舊的，相依對不上。Arch 只支援 full upgrade：一律 pacman -Syu，永遠不要單獨 -Sy 之後裝東西。這條規則救掉這一整類故障。

stale db 404：裝機當下的資料庫已經過期

error: failed retrieving file '...' 404，而且換好幾個 mirror 都一樣。這是 rolling 發行版特有的時序陷阱：Arch 的 mirror 不保留舊版檔案，你裝機時 ISO 內建的套件資料庫指向的檔名，可能幾天內就被輪替掉了——資料庫說有這個檔、mirror 上已經沒有。修法跟上一條同源：pacman -Syu 先把資料庫同步到最新，檔名對上了就抓得到。這也是為什麼「一律 -Syu」是 Arch 的鐵律，而不只是建議。

判讀總表

下一步

• 這幾步用到的網路驗證，完整版在最小安裝後的工具驗證與補足。
• 裝機時選 mirror / locale / 時區的決策，見Linux 安裝選項判讀。
• 跨發行版時「這個套件名 / 這個旗標在別的發行版叫什麼」的差異判讀，見平台與發行版差異的判讀地圖。
• 套件抓下來了、但 bootstrap 腳本本身失敗要 debug，見可除錯的 bootstrap。
• 系統跑起來後才出的套件問題（AUR 建置失敗、-bin 包 soname 斷裂等），屬除錯範疇，見Linux 除錯與診斷。

Route 53 Hosted Zone

Hosted zone 是 Route 53 用來管理某個網域的 DNS 記錄集合。建立 zone 後，Route 53 會分配一組 NS（Name Server）記錄，網域的 DNS 解析就由這組 NS 負責。

Public vs Private Zone

Public hosted zone 對應的是可從網際網路解析的網域（如 example.com），用於對外服務的 A / CNAME / MX 記錄。Private hosted zone 只在指定的 VPC 內可解析，用於內部服務發現（如 db.internal.example.com 解析到 RDS 的 private IP）。多數專案兩者都需要：public zone 給對外流量、private zone 給內部服務互連。

 1resource "aws_route53_zone" "public" {
 2  name = "example.com"
 3  tags = { Environment = "production" }
 4}
 5
 6resource "aws_route53_zone" "private" {
 7  name = "internal.example.com"
 8
 9  vpc {
10    vpc_id = aws_vpc.main.id
11  }
12
13  tags = { Environment = "production" }
14}

子網域 delegation

當 dev / staging / prod 各用獨立帳號時，每個帳號建自己的 hosted zone 管理子網域（如 dev.example.com）。父網域的 zone 需要加一組 NS 記錄指向子網域的 zone，這個動作叫 delegation。

1resource "aws_route53_record" "dev_ns" {
2  zone_id = aws_route53_zone.public.zone_id
3  name    = "dev.example.com"
4  type    = "NS"
5  ttl     = 300
6  records = aws_route53_zone.dev.name_servers
7}

delegation 的 NS 記錄指向子帳號 zone 的 name server。子帳號內的所有 DNS 記錄（如 api.dev.example.com）由子帳號的 zone 管理，父帳號不需要逐條設定。跨帳號 delegation 需要兩邊的 Terraform 各自管理自己的 zone，NS 記錄在父帳號的 state 裡。

判讀設定是否正確：用 dig dev.example.com NS 查回的 name server 應該是子帳號 zone 的 NS，不是父帳號的。如果查回父帳號的 NS，代表 delegation 沒生效，子網域的 DNS 記錄不會被解析。

ACM 憑證申請與 DNS 驗證

AWS Certificate Manager（ACM）提供免費的 TLS 憑證，條件是透過 DNS 或 email 驗證網域所有權。DNS 驗證是 IaC 友善的方式——ACM 要求在指定網域下建一條 CNAME 記錄，記錄值由 ACM 提供，驗證通過後憑證自動簽發。

 1resource "aws_acm_certificate" "main" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = ["*.example.com"]
 4  validation_method         = "DNS"
 5
 6  lifecycle {
 7    create_before_destroy = true
 8  }
 9
10  tags = { Environment = "production" }
11}

subject_alternative_names 加 *.example.com 讓同一張憑證涵蓋所有子網域（如 api.example.com、admin.example.com），省去為每個子網域各申請一張。

DNS 驗證記錄

ACM 簽發後會產出一組驗證用的 CNAME 記錄。用 Terraform 自動在 Route 53 建立這些記錄，讓驗證流程不需要手動操作：

 1resource "aws_route53_record" "cert_validation" {
 2  for_each = {
 3    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
 4      name   = dvo.resource_record_name
 5      record = dvo.resource_record_value
 6      type   = dvo.resource_record_type
 7    }
 8  }
 9
10  zone_id = aws_route53_zone.public.zone_id
11  name    = each.value.name
12  type    = each.value.type
13  ttl     = 300
14  records = [each.value.record]
15
16  allow_overwrite = true
17}
18
19resource "aws_acm_certificate_validation" "main" {
20  certificate_arn         = aws_acm_certificate.main.arn
21  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
22}

aws_acm_certificate_validation 資源會等到 ACM 確認驗證通過才算 apply 成功。如果 DNS 記錄設錯或 zone 的 NS delegation 有問題，這個資源會卡住直到 timeout——排查方向是先確認驗證 CNAME 記錄能被公網 DNS 解析。

create_before_destroy

lifecycle { create_before_destroy = true } 在憑證需要替換時（如增加 SAN、更換網域），讓 Terraform 先建新憑證、再刪舊憑證。沒有這個設定，預設行為是先刪後建——刪除的瞬間 ALB listener 失去憑證，HTTPS 連線全部中斷直到新憑證驗證通過（可能要幾分鐘到幾十分鐘）。

ALB HTTPS Listener

憑證驗證通過後，把它掛到 ALB 的 HTTPS listener：

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate_validation.main.certificate_arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.app.arn
11  }
12}

ssl_policy 決定 TLS 版本與加密套件。ELBSecurityPolicy-TLS13-1-2-2021-06 支援 TLS 1.2 和 1.3、停用已知不安全的舊版協定。選型判準是相容性與安全性的平衡——TLS 1.3-only policy 最安全但可能排除舊版客戶端，多數場景用 1.2+1.3 的組合。

certificate_arn 引用的是 aws_acm_certificate_validation 而非直接引用 aws_acm_certificate，確保 listener 只在憑證驗證通過後才建立。

HTTP → HTTPS 重導

同時建立一個 HTTP listener，把所有 80 埠流量重導到 443：

 1resource "aws_lb_listener" "http_redirect" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 80
 4  protocol          = "HTTP"
 5
 6  default_action {
 7    type = "redirect"
 8    redirect {
 9      port        = "443"
10      protocol    = "HTTPS"
11      status_code = "HTTP_301"
12    }
13  }
14}

301 永久重導讓瀏覽器記住後續直接走 HTTPS。security group 仍然需要開放 80 埠入站，否則重導不會發生——client 連 80 埠被擋、收到的是連線失敗而非重導回應。

多網域與 SAN 憑證

一張 ACM 憑證最多支援 10 個 SAN（Subject Alternative Name）。多數場景用主網域 + wildcard（example.com + *.example.com）就夠用。如果有多個不同根網域（如 example.com 和 example-app.com），可以加進同一張憑證：

 1resource "aws_acm_certificate" "multi_domain" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = [
 4    "*.example.com",
 5    "example-app.com",
 6    "*.example-app.com",
 7  ]
 8  validation_method = "DNS"
 9
10  lifecycle {
11    create_before_destroy = true
12  }
13}

每個 SAN 網域都需要獨立的 DNS 驗證記錄。如果不同網域在不同的 hosted zone 裡，驗證記錄的建立要分別指向各自的 zone。

當 SAN 數量超過 10、或不同網域的憑證需要獨立管理（不同 team 負責不同網域），改用 aws_lb_listener_certificate 額外掛載：

1resource "aws_lb_listener_certificate" "additional" {
2  listener_arn    = aws_lb_listener.https.arn
3  certificate_arn = aws_acm_certificate.other_domain.arn
4}

ALB 會根據 SNI（Server Name Indication）自動選擇匹配的憑證。

穩定的 DNS 別名記錄

ALB 重建後 DNS 名稱會改變，對外服務不應該直接用 ALB 的 DNS 名稱。用 Route 53 的 alias record 把穩定的網域名指向 ALB：

 1resource "aws_route53_record" "app" {
 2  zone_id = aws_route53_zone.public.zone_id
 3  name    = "api.example.com"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.main.dns_name
 8    zone_id                = aws_lb.main.zone_id
 9    evaluate_target_health = true
10  }
11}

alias record 不收費（一般的 A/CNAME 記錄每百萬次查詢 $0.40，alias 到 AWS 資源免費），且支援 zone apex（如 example.com，一般 CNAME 不支援 zone apex）。evaluate_target_health = true 讓 Route 53 在 ALB 不健康時停止回應該記錄，配合 failover routing 使用。

憑證續期監控

ACM 的 DNS 驗證憑證會自動續期——條件是驗證用的 CNAME 記錄仍然存在且可解析。只要那條記錄沒被刪掉，憑證到期前 60 天 ACM 會自動續期。

自動續期失敗的常見原因：驗證 CNAME 記錄被手動刪除、hosted zone 的 NS delegation 失效、或 zone 本身被刪除重建導致 NS 改變。用 CloudWatch alarm 監控憑證到期日，在自動續期失敗時提前收到通知：

 1resource "aws_cloudwatch_metric_alarm" "cert_expiry" {
 2  alarm_name          = "acm-cert-expiry-${aws_acm_certificate.main.domain_name}"
 3  comparison_operator = "LessThanThreshold"
 4  evaluation_periods  = 1
 5  metric_name         = "DaysToExpiry"
 6  namespace           = "AWS/CertificateManager"
 7  period              = 86400
 8  statistic           = "Minimum"
 9  threshold           = 30
10  alarm_actions       = [aws_sns_topic.oncall.arn]
11
12  dimensions = {
13    CertificateArn = aws_acm_certificate.main.arn
14  }
15}

這個 alarm 在憑證距離到期不足 30 天時觸發。正常情況下 ACM 在到期前 60 天就會完成續期，收到 30 天警報代表自動續期失敗了、需要人工介入確認驗證記錄。

跨分類引用

• → 入口上 IaC — ALB：ALB listener、target group、健康檢查的完整設定
• → 模組三：網路地基：ALB 所在的 public subnet 與 security group 設計
• → 模組七：infra 走 PR 流程：憑證與 DNS 變更走 PR review

Internal DNS：內部名稱解析

斷網環境沒有公開 DNS 可用。內部服務之間的互相引用（GitLab 連 PostgreSQL、Harbor 連 storage backend）如果靠 IP 位址，每次 IP 變動都要改一輪設定。內部 DNS 讓服務用 hostname（gitlab.internal、harbor.internal）互相引用，IP 變動只改 DNS zone 一處。

CoreDNS vs BIND

多數斷網環境用 CoreDNS 就夠——zone 檔案放在磁碟上、Corefile 幾行就能啟動。

最小設定

 1# Corefile
 2internal:53 {
 3    file /etc/coredns/zones/internal.zone
 4    log
 5    errors
 6}
 7
 8.:53 {
 9    forward . /dev/null
10    log
11}

第一個 block 處理 internal 域名的查詢、從 zone 檔案回應。第二個 block 攔截所有其他查詢——斷網環境不能轉發到上游 DNS，forward . /dev/null 讓非內部域名直接返回 NXDOMAIN 而非 timeout。

 1; /etc/coredns/zones/internal.zone
 2$ORIGIN internal.
 3@       IN SOA  ns1.internal. admin.internal. (
 4        2026062601 ; serial
 5        3600       ; refresh
 6        600        ; retry
 7        86400      ; expire
 8        60         ; minimum
 9)
10        IN NS   ns1.internal.
11ns1     IN A    10.0.1.10
12gitlab  IN A    10.0.1.20
13harbor  IN A    10.0.1.21
14vault   IN A    10.0.1.22
15nexus   IN A    10.0.1.23
16prom    IN A    10.0.1.24
17grafana IN A    10.0.1.25
18ntp     IN A    10.0.1.11

新增服務時加一行 A record、重載 CoreDNS（kill -SIGUSR1 $(pidof coredns) 或重啟 container）。serial 號遞增讓變更可追蹤。

客戶端設定

每台機器的 /etc/resolv.conf 指向 CoreDNS 的 IP：

1nameserver 10.0.1.10
2search internal

如果環境有 DHCP server，在 DHCP option 裡配 DNS server 位址，新加入的機器自動取得。沒有 DHCP 就靠 provisioning 腳本或 Ansible playbook 推送。

NTP：內部時間同步

時間不同步在斷網環境會引發三類問題：log 的時間戳錯亂讓事故排查無法跨機器對齊、TLS 憑證的有效期判斷出錯導致合法憑證被拒絕、以及 Kerberos 等時間敏感的認證協定直接失敗。正常環境從 pool.ntp.org 取得時間，斷網環境需要自己的時間源。

chrony 作為 NTP server

chrony 比傳統的 ntpd 更適合網路不穩或隔離的環境——它的時鐘修正演算法在長時間無外部時間源時仍能保持較準確的漂移補償。

1# /etc/chrony.conf（NTP server 端）
2# 斷網環境：沒有上游 NTP、用本機時鐘作為最後手段
3local stratum 10
4allow 10.0.0.0/8
5driftfile /var/lib/chrony/drift

local stratum 10 宣告「我自己是時間源、但 stratum 很低（精度不高）」。其他機器的 chrony 設定指向這台 server：

1# /etc/chrony.conf（客戶端）
2server ntp.internal iburst
3makestep 1.0 3

iburst 讓開機時快速同步、makestep 1.0 3 允許前三次校正時跳大步（修正啟動時的大偏差）。

高精度需求

如果環境對時間精度有要求（金融交易、工控系統），NTP server 需要硬體時間源——GPS 接收器或原子鐘模組。GPS 天線不需要網路連線、只需要看得到衛星的位置（屋頂或窗邊）。chrony 支援 PPS（Pulse Per Second）輸入、可以達到微秒級精度。

多數斷網環境不需要這個精度——毫秒級一致（chrony 預設行為）對 log 對齊和 TLS 驗證已經足夠。

Internal CA：內部憑證簽發

斷網環境的每個內部 HTTPS 服務都需要 TLS 憑證。Let’s Encrypt 的 ACME challenge 需要連網驗證，在斷網環境無法使用。替代方案是建立內部 CA（Certificate Authority），自己簽發憑證。

step-ca（Smallstep）

step-ca 是一個輕量的 CA server，支援 ACME 協定——內部服務可以用跟 Let’s Encrypt 相同的流程自動申請和續期憑證，只是 ACME server 是內網的 step-ca 而非 Let’s Encrypt。

1# 初始化 CA
2step ca init --name="Internal CA" --dns="ca.internal" \
3  --address=":443" --provisioner="admin"
4
5# 啟動 CA server
6step-ca $(step path)/config/ca.json

初始化會產生 root CA 和 intermediate CA 的 key pair。root CA 的私鑰是整個信任鏈的根——它的保護等級要最高（離線儲存、存取紀錄）。

憑證簽發流程

服務用 ACME client 向 step-ca 申請憑證：

1# 用 step CLI 申請憑證（手動方式）
2step ca certificate "gitlab.internal" gitlab.crt gitlab.key
3
4# 用 ACME 自動續期（搭配 certbot 或 step 的 renewal daemon）
5step ca renew --daemon gitlab.crt gitlab.key

certbot 也能配合 step-ca 使用——把 ACME server URL 從 Let’s Encrypt 改成 https://ca.internal/acme/acme/directory。已有 certbot 自動續期腳本的服務只要改一行設定。

Root CA 分發

每台機器和每個服務都要信任內部 CA 的 root certificate：

1# Debian/Ubuntu
2cp root_ca.crt /usr/local/share/ca-certificates/internal-ca.crt
3update-ca-certificates
4
5# RHEL/CentOS
6cp root_ca.crt /etc/pki/ca-trust/source/anchors/internal-ca.crt
7update-ca-trust

Docker daemon 也需要信任內部 CA（否則 docker pull harbor.internal/image 會報 TLS 錯誤）：

1mkdir -p /etc/docker/certs.d/harbor.internal
2cp root_ca.crt /etc/docker/certs.d/harbor.internal/ca.crt
3systemctl restart docker

Ansible playbook 批量推送 root CA 到所有機器，是初始部署的標準做法。

cfssl 作為替代

cfssl（Cloudflare 的 PKI 工具組）比 step-ca 更簡單但沒有 ACME 自動化——每張憑證要手動簽發。適合只有 5-10 個服務、不需要自動續期的小規模環境。

Secret Management：HashiCorp Vault

資料庫密碼、API token、TLS 私鑰這些機密值需要一個集中的安全儲存。斷網環境不能用 AWS Secrets Manager 或 GCP Secret Manager，HashiCorp Vault 是最常見的自建選項。

斷網環境的 Vault 初始化

Vault 的初始化（unsealing）在雲端環境通常用 AWS KMS 或 GCP Cloud KMS 自動 unseal。斷網環境沒有雲端 KMS，退回 Shamir’s Secret Sharing——初始化時產生 N 個 unseal key、啟動時需要 M 個 key 才能解鎖（典型設定：5 個 key、3 個即可 unseal）。

1# 初始化 Vault（5 key shares、3 threshold）
2vault operator init -key-shares=5 -key-threshold=3
3
4# Unseal（需要 3 次、每次用不同的 key）
5vault operator unseal <key-1>
6vault operator unseal <key-2>
7vault operator unseal <key-3>

5 個 unseal key 分別交給不同的人保管。任何單一個人都無法獨自解鎖 Vault——這是刻意的安全設計。Vault 重啟後需要重新 unseal，所以 unseal key 的保管和取用流程要事先演練。

機器身分認證

服務從 Vault 讀取 secret 時需要認證自己的身分。雲端環境用 IAM role，斷網環境用 AppRole——每個服務拿到一組 role_id + secret_id、用它們換取短期 token。

 1# 建立 AppRole
 2vault auth enable approle
 3vault write auth/approle/role/gitlab \
 4  token_ttl=1h \
 5  token_max_ttl=4h \
 6  policies=gitlab-secrets
 7
 8# 服務端取得 token
 9vault write auth/approle/login \
10  role_id="$ROLE_ID" \
11  secret_id="$SECRET_ID"

secret_id 本身也是 secret——初次部署時由 Vault admin 手動提供給服務、或透過 Ansible 的 encrypted variable 推送。

儲存後端

Vault 需要一個持久化的儲存後端。雲端用 DynamoDB 或 Consul，斷網環境用：

部署順序的相互依賴

四個服務之間有依賴鏈：

1DNS → NTP → CA → Vault
2 ↑_________________↓（Vault 的 FQDN 要 DNS 解析）

DNS 先啟動（其他服務靠它解析 hostname）→ NTP 跟著（CA 簽發憑證時需要準確的時間、否則 notBefore/notAfter 判斷會出問題）→ CA 啟動（Vault 的 HTTPS 需要 TLS 憑證）→ Vault 最後（依賴 DNS 和 TLS）。

DNS 跟 CA 之間有一個循環依賴：CA 簽發憑證時需要 DNS 解析（ACME challenge 或 CSR 裡的 SAN），但 DNS server 本身要不要 TLS？解法是 DNS 第一次啟動時用明文（不走 HTTPS），CA 啟動後回頭替 DNS 簽一張憑證、再切到 DNS-over-TLS。多數內網環境 DNS 維持明文即可——DNS 查詢在內網不加密是常見做法，風險可控。

時程與維護

四個服務合計約 1.5-2 個工作天完成初始部署。部署完成後的日常維護負擔集中在 Vault（unseal key 管理和 policy 維護）和 DNS zone 更新。CA 的憑證續期如果用 ACME 自動化就接近零維護。

向管理層溝通時的框架：「這四個服務是所有其他服務的地基——沒有它們，其他服務要麼找不到彼此（DNS）、時間對不上（NTP）、通訊不加密（CA）、密碼寫在設定檔裡（Vault）。部署一次、之後幾乎自動運作。」

跨分類引用

• → 斷網環境的通用原則：content ferry 和離線套件管理的通用操作模式
• → 斷網環境的 IaC：Vault 作為 Terraform 的 secret backend
• → 斷網環境的容器與映像管理：Harbor 依賴 DNS 和 TLS、映像拉取需要信任內部 CA
• → 模組二：身分與憑證地基：Vault 的角色跟雲端的 Secrets Manager 對應
• → 模組八：治理好習慣：Secret 不進 code 的原則在斷網環境用 Vault 落地