Packer+Terraform在DigitalOcean上自动化部署Vault服务

1. 项目概述：为什么要在 DigitalOcean 上用 Packer + Terraform 快速搭建 Vault 服务

Hashicorp Vault 不是普通密码管理器，它是企业级密钥生命周期管理中枢——能动态生成数据库凭证、轮转云服务访问密钥、加密任意敏感字段、审计每一次密钥读取行为。我第一次在客户现场部署 Vault 时，用的是手动配置的 Ubuntu 虚拟机：装依赖、改配置、启服务、调策略，光环境准备就花了 3 小时；结果第二天发现 TLS 证书过期，Vault 启动失败，整个 CI/CD 流水线卡死。后来我们彻底重构了交付方式：把 Vault 服务器本身变成“可版本化、可测试、可回滚”的基础设施代码产物。这就是本项目的核心逻辑——不部署一个 Vault 实例，而是构建一套可复现、可审计、可批量交付的 Vault 基础设施流水线。

标题里三个关键词就是这条流水线的三段式引擎：Packer 负责“造镜像”，Terraform 负责“铺底座”，DigitalOcean 是轻量高效、API 友好、按秒计费的落地方。Quickstart 不是指“点几下就完事”，而是指从零到生产就绪 Vault 服务的最小可行路径：跳过高可用集群、跳过外部存储后端（先用内置 Raft）、跳过 LDAP 集成（先用本地用户），但保留所有安全基线——TLS 强制启用、监听地址严格绑定、初始 root token 安全导出、策略最小权限预置。它适合三类人直接抄作业：刚接触 Vault 的 DevOps 新手想快速验证核心能力；中小团队需要一套干净、无历史包袱的密码管理起点；SaaS 创业公司要为每个客户环境自动化部署隔离 Vault 实例。你不需要懂 Go 语言，不需要研究 Vault 内部 Raft 协议，只需要理解 Linux 系统管理、HTTP 基础和 JSON/YAML 语法，就能在 20 分钟内跑通整条链路。

提示：这不是“Vault 入门教程”，也不教vault server -dev这种开发模式。它解决的是真实生产场景中第一个痛点——如何让 Vault 本身成为 Infrastructure as Code 的一等公民。所有配置都托管在 Git 中，每次terraform apply都是一次可追溯的 Vault 环境发布，而不是一次不可逆的手工操作。

2. 整体架构设计与技术选型逻辑

2.1 为什么必须分两步：Packer 打镜像 + Terraform 部署？

新手常问：“Terraform 不是也能执行 shell 脚本吗？为什么还要加一层 Packer？” 这个问题直击本质。我用一个真实故障说明：某次客户升级 Vault 版本，我们直接在 Terraform 的remote-exec中写curl -sL https://releases.hashicorp.com/vault/1.15.0/vault_1.15.0_linux_amd64.zip | unzip。上线后发现新版本依赖 glibc 2.28，而客户基础镜像只有 2.27 —— Terraform 在实例启动后才开始执行，此时机器已创建、IP 已分配、DNS 已解析，回滚意味着销毁整个实例并重建，业务中断 5 分钟以上。而 Packer 方案完全不同：它在镜像构建阶段就完成所有二进制下载、解压、校验、配置文件注入、systemd 单元注册。最终产出的是一个“开箱即 Vault 就绪”的自包含镜像。Terraform 创建 Droplet 时，只需指定这个镜像 ID，实例启动后 3 秒内 Vault 就进入sealed状态，全程无需任何运行时网络拉取或编译。

更深层的价值在于一致性保障。Packer 构建过程是纯函数式：输入是源镜像 + 构建脚本 + 变量，输出是唯一 SHA256 校验值的镜像。无论你在本地 Mac、CI 流水线、还是离线环境执行，只要输入不变，输出镜像字节完全一致。而 Terraform 的provisioner是命令式：它依赖目标机器的实时状态（网络是否通畅、磁盘空间是否足够、apt 源是否可用），同一份代码在不同时间执行可能得到不同结果。我们团队内部规定：所有生产环境 Vault 镜像必须由 Packer 构建，且镜像 ID 必须硬编码在 Terraform 变量中，禁止使用latest标签——这是防止“雪人效应”（Snowman Effect）的关键防线。

2.2 为什么选 DigitalOcean 而非 AWS/Azure/GCP？

不是因为便宜，而是因为API 稳定性与调试友好性。DigitalOcean 的 Droplet API 是 RESTful 设计最干净的之一：创建实例、获取 IP、绑定浮动 IP、设置标签，全部是标准 HTTP 方法，响应结构统一，错误码语义清晰。对比 AWS EC2 的RunInstances返回一堆嵌套 Map，GCP 的insert接口要求传入完整 JSON Schema，DO 的/v2/droplets接口只需 POST 一个简洁 JSON：

{ "name": "vault-prod-01", "region": "nyc3", "size": "s-2vcpu-4gb", "image": "ubuntu-22-04-x64", "ssh_keys": ["3b:41:..."], "tags": ["vault", "prod"] }

这对 Terraform Provider 的可靠性至关重要。我们曾用同一套 Terraform 代码在 AWS 和 DO 并行部署，AWS 环境出现过 3 次InvalidInstanceID.NotFound错误（Terraform 认为实例已创建，但 AWS 控制台显示不存在），排查耗时 8 小时；而 DO 环境连续 127 次apply全部成功，失败时错误信息明确指向 SSH 密钥格式错误。对于 Quickstart 场景，稳定性 > 功能丰富度。DigitalOcean 的监控、告警、备份功能虽不如云巨头，但 Vault 本身自带健康检查端点（/v1/sys/health），我们用简单的curl -f http://$IP:8200/v1/sys/health就能集成到任何监控系统，无需依赖云平台原生能力。

2.3 为什么不用 Vault 的自动解封（Auto-unseal）？

标题强调 “Quickstart”，意味着要砍掉所有非必要复杂度。Auto-unseal 需要额外配置云 KMS（如 AWS KMS、GCP Cloud KMS）或第三方 HSM，这会引入新的依赖、新的权限模型、新的故障点。而本方案采用Shamir 秘密共享（Shamir’s Secret Sharing）的经典解封流程：生成 5 个恢复密钥，任意 3 个即可解封。这看似“原始”，实则最符合中小团队实际：密钥可以打印在纸上交给三位负责人，也可以加密后存入三个不同人的密码管理器。没有网络依赖，没有第三方服务 SLA，没有额外账单。更重要的是，它强制建立安全仪式感——解封不是vault operator unseal一条命令，而是三人协作的物理过程，天然防止单点失误。我们在客户培训中发现，当工程师亲手输入三段密钥时，对 Vault “密封”概念的理解深度远超阅读文档十遍。

3. 核心细节解析与安全基线配置

3.1 Packer 构建镜像：从裸 Ubuntu 到 Vault 就绪镜像的完整链条

Packer 模板（vault-packer.json）不是简单地apt install vault，而是一套精密的“操作系统手术”。整个构建分为 5 个阶段，每个阶段解决一个关键问题：

第一阶段：基础环境加固
使用shellprovisioner 执行apt update && apt upgrade -y，但关键在后续两步：

• 禁用 root 密码登录：sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
• 强制 SSH 密钥认证：sed -i 's/^#PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
  这不是 Vault 特有需求，而是所有生产服务器的底线。我们曾发现某客户镜像因未禁用密码登录，被暴力破解工具扫出 root 密码，导致 Vault 数据库凭证泄露。

第二阶段：Vault 二进制安全注入
不走apt源（版本滞后、签名难验），而是用fileprovisioner 直接上传预下载的.zip包，再用shell执行校验：

sha256sum -c /tmp/vault_1.15.0_linux_amd64.zip.sha256 2>/dev/null || exit 1 unzip -o /tmp/vault_1.15.0_linux_amd64.zip -d /usr/local/bin/ chown root:root /usr/local/bin/vault chmod 755 /usr/local/bin/vault

.sha256文件必须和 ZIP 包同名，由 HashiCorp 官网提供。这一步杜绝了中间人攻击风险——如果只校验 ZIP 而不校验校验文件本身，攻击者可同时篡改两者。

第三阶段：配置文件与策略预置
templateprovisioner 渲染vault.hcl配置模板，核心参数如下：

storage "raft" { path = "/var/lib/vault/data" node_id = "vault-node-01" } listener "tcp" { address = "0.0.0.0:8200" cluster_address = "0.0.0.0:8201" tls_cert_file = "/etc/vault/tls/fullchain.pem" tls_key_file = "/etc/vault/tls/privkey.pem" tls_min_version = "tls12" } api_addr = "https://{{user `vault_domain`}}:8200" cluster_addr = "https://{{user `vault_domain`}}:8201"

注意tls_min_version = "tls12"是硬性要求，禁用 TLS 1.0/1.1。vault_domain作为 Packer 变量传入，支持不同环境（如vault-staging.example.com/vault-prod.example.com）复用同一模板。

第四阶段：Systemd 服务单元注册
创建/etc/systemd/system/vault.service：

[Unit] Description=HashiCorp Vault Requires=network-online.target After=network-online.target [Service] Type=simple User=vault Group=vault ExecStart=/usr/local/bin/vault server -config=/etc/vault/vault.hcl Restart=on-failure RestartSec=5 LimitNOFILE=65536 [Install] WantedBy=multi-user.target

关键点：LimitNOFILE=65536解决高并发连接数限制；User=vault强制以非 root 用户运行，符合最小权限原则。

第五阶段：初始化脚本注入
最后用fileprovisioner 上传init-vault.sh到/opt/vault/init.sh，内容为：

#!/bin/bash # 仅在首次启动时运行 if [ ! -f /var/lib/vault/.initialized ]; then vault server -config=/etc/vault/vault.hcl -dev & sleep 5 # 生成初始 root token 和 unseal keys vault operator init -key-shares=5 -key-threshold=3 -format=json > /root/vault-init.json chown root:root /root/vault-init.json chmod 600 /root/vault-init.json touch /var/lib/vault/.initialized fi

这个脚本在镜像构建时不会执行（因为 Vault 服务未启动），但会被复制到最终镜像中，供 Terraform 部署后首次启动调用。

3.2 Terraform 部署：从镜像到可访问 Vault 服务的七步闭环

Terraform 模块（main.tf）不是简单创建一台 Droplet，而是构建一个完整的“Vault 就绪环境”。以下是七个不可省略的环节，每一步都对应一个真实运维痛点：

第一步：Droplet 创建与基础属性定义

resource "digitalocean_droplet" "vault" { image = var.vault_image_id # Packer 输出的镜像 ID name = "${var.env}-vault-01" region = var.region size = var.droplet_size # 推荐 s-2vcpu-4gb 起步 ssh_keys = [digitalocean_ssh_key.main.fingerprint] tags = ["vault", var.env] }

var.vault_image_id必须是 Packer 构建后输出的精确 ID（如123456789），而非ubuntu-22-04-x64这类通用名称。这是保证环境一致性的第一道锁。

第二步：浮动 IP 绑定与 DNS 解析

resource "digitalocean_floating_ip" "vault" { droplet_id = digitalocean_droplet.vault.id region = var.region } resource "digitalocean_record" "vault" { domain = var.domain type = "A" name = var.vault_subdomain # 如 "vault" -> vault.example.com value = digitalocean_floating_ip.vault.ip_address ttl = 30 }

浮动 IP 是关键：它解耦了 Droplet 生命周期与 DNS 记录。当 Droplet 因故障需重建时，只需将浮动 IP 重新绑定到新实例，DNS 记录无需变更，客户端零感知。我们曾用此特性在 47 秒内完成 Vault 实例灾备切换。

第三步：安全组（Firewall）精细化控制

resource "digitalocean_firewall" "vault" { name = "${var.env}-vault-fw" inbound_rule { protocol = "tcp" port_range = "22" source_addresses = var.ssh_allowed_ips # 仅允许运维 IP 段 } inbound_rule { protocol = "tcp" port_range = "8200" source_addresses = var.vault_allowed_ips # 仅允许应用服务器 IP } inbound_rule { protocol = "tcp" port_range = "8201" source_addresses = ["0.0.0.0/0"] # Raft 集群通信需开放，但后续扩展时应限制 } outbound_rule { protocol = "all" port_range = "1-65535" destination_addresses = ["0.0.0.0/0"] } droplet_ids = [digitalocean_droplet.vault.id] }

重点在8200端口的白名单：绝不开放0.0.0.0/0。Vault 的安全性始于网络层——如果攻击者连https://vault.example.com:8200/v1/auth/token/create都无法访问，后续所有攻击向量都归零。

第四步：TLS 证书自动化部署
使用 Let's Encrypt 通过 DNS01 挑战：

resource "acme_certificate" "vault" { provider = acme.production domain { domain = var.vault_fqdn } dns_challenge { provider = "digitalocean" } } resource "tls_private_key" "vault" { algorithm = "RSA" } # 将证书和私钥写入 Droplet resource "null_resource" "deploy_tls" { triggers = { cert_pem = acme_certificate.vault.certificate_pem privkey = tls_private_key.vault.private_key_pem } connection { type = "ssh" host = digitalocean_floating_ip.vault.ip_address user = "root" private_key = file(var.ssh_private_key_path) } provisioner "file" { content = acme_certificate.vault.certificate_pem destination = "/etc/vault/tls/fullchain.pem" } provisioner "file" { content = acme_certificate.vault.private_key_pem destination = "/etc/vault/tls/privkey.pem" } }

这里acme_certificate依赖 DigitalOcean API 写入 DNS TXT 记录完成验证，比 HTTP01 更安全（无需暴露 Web 服务）。证书路径与 Packer 配置中的tls_cert_file严格对应。

第五步：Vault 初始化与密钥安全导出

resource "null_resource" "vault_init" { depends_on = [ digitalocean_droplet.vault, null_resource.deploy_tls ] connection { type = "ssh" host = digitalocean_floating_ip.vault.ip_address user = "root" private_key = file(var.ssh_private_key_path) } provisioner "remote-exec" { inline = [ "systemctl start vault", "sleep 10", // 等待 Vault 启动 "vault operator init -key-shares=5 -key-threshold=3 -format=json > /root/vault-init.json", "chmod 600 /root/vault-init.json" ] } # 将初始化结果下载到本地 provisioner "file" { source = "/root/vault-init.json" destination = "./vault-init-${var.env}.json" } }

vault-init.json包含 root token 和 5 个 unseal key，必须立即下载并加密保存。我们用gpg --encrypt --recipient team-security@company.com vault-init-prod.json加密后存入 Git 仓库，确保密钥不落地明文。

第六步：健康检查与就绪等待

resource "null_resource" "vault_wait" { depends_on = [null_resource.vault_init] connection { type = "ssh" host = digitalocean_floating_ip.vault.ip_address user = "root" private_key = file(var.ssh_private_key_path) } provisioner "remote-exec" { inline = [ "while ! curl -f -k https://localhost:8200/v1/sys/health 2>/dev/null; do echo 'Waiting for Vault...'; sleep 5; done", "echo 'Vault is ready!'" ] } }

-k参数临时忽略证书验证（因证书刚部署，本地 CA 未更新），但仅用于初始化等待。生产环境客户端必须配置正确 CA 证书。

第七步：策略与初始令牌预置

resource "null_resource" "vault_setup" { depends_on = [null_resource.vault_wait] connection { type = "ssh" host = digitalocean_floating_ip.vault.ip_address user = "root" private_key = file(var.ssh_private_key_path) } # 使用 root token 创建 admin 策略 provisioner "remote-exec" { inline = [ "export VAULT_ADDR='https://localhost:8200'", "export VAULT_TOKEN='$(cat /root/vault-init.json | jq -r .root_token)'", "vault policy write admin - <<EOF", "path \"*\" {", " capabilities = [\"create\", \"read\", \"update\", \"delete\", \"list\", \"sudo\"]", "}", "EOF" ] } }

admin策略是临时管理入口，后续应创建细粒度策略（如app-db-read、ci-cd-token-gen）并禁用 root token。

4. 实操过程与关键参数详解

4.1 环境准备：本地开发机的最小依赖清单

不要幻想“一键安装”，先确认你的笔记本满足以下四点，否则后续所有步骤都会卡在第一步：

1. DigitalOcean Personal Access Token
登录 DO 控制台 → API → Generate New Token → 勾选Read and Write权限 → 复制 Token。切勿用默认 token 名称，改为tf-vault-prod这类带环境标识的名称，便于审计。将 Token 存入环境变量：

export DIGITALOCEAN_TOKEN="abc123...xyz789"

Terraform Provider 会自动读取此变量，无需硬编码在代码中。

2. SSH 密钥对（非密码登录）
必须使用ssh-keygen -t ed25519 -C "vault-admin@company.com"生成 Ed25519 密钥（比 RSA 更安全、更快）。公钥（id_ed25519.pub）需提前上传到 DO 控制台的 Settings → Security → SSH Keys。私钥路径（如~/.ssh/id_ed25519）将作为 Terraform 变量传入。

3. 域名与 DNS 管理权
你需要一个已接入 DigitalOcean DNS 的域名（如example.com）。在 DO 控制台的 Networking → Domains 中添加该域名，并确保 NS 记录已指向 DO 的 DNS 服务器（ns1.digitalocean.com等）。这是 Let's Encrypt 自动签发证书的前提。

4. Terraform 与 Packer 版本
必须使用匹配版本：

• Terraform ≥ 1.5.0（支持acme_certificate的 DNS01 挑战）
• Packer ≥ 1.9.0（支持digitaloceanbuilder 的最新 API）
  验证命令：

terraform version # 应输出 v1.5.7+ packer version # 应输出 1.9.6+

旧版本会报错Error: Unsupported argument或Builder 'digitalocean' not found，这是新手最常踩的坑。

4.2 Packer 构建镜像：从模板到可用镜像的完整执行流

假设你已克隆官方模板仓库，目录结构如下：

vault-packer/ ├── packer.json # 主模板 ├── scripts/ │ ├── install-vault.sh # 安装脚本 │ └── setup-systemd.sh # systemd 配置 └── templates/ └── vault.hcl.tpl # Vault 配置模板

执行前必改的三个变量（在packer.json中）：

1. "source_image": "ubuntu-22-04-x64"→ 确认 DO 官方镜像 ID，运行doctl compute image list --public | grep ubuntu-22-04获取最新 ID
2. "region": "nyc3"→ 改为你目标区域（如sfo3,ams3）
3. "vault_version": "1.15.0"→ 改为当前最新稳定版，从 HashiCorp Releases 页面复制

构建命令与关键日志解读：

cd vault-packer packer build -var 'vault_version=1.15.0' -var 'region=nyc3' packer.json

成功构建的日志末尾必须出现：

==> Builds finished. The artifacts of successful builds are: --> digitalocean: A snapshot was created: 'vault-1.15.0-nyc3-20231015' (ID: 123456789)

这个123456789就是下一步 Terraform 所需的vault_image_id。切勿复制vault-1.15.0-nyc3-20231015这个名称，必须用数字 ID。

常见失败场景与修复：

• 错误：Error uploading file: POST https://api.digitalocean.com/v2/images/... gave status 404
  原因：source_image值错误，不是有效镜像 ID。修复：用doctl命令重新查询，确认 ID 格式为纯数字。
• 错误：Script exited with non-zero exit status: 1
  原因：install-vault.sh中curl下载失败。检查vault_version是否拼写错误，或官网是否已下架该版本。
• 警告：Warning: 'type' is deprecated
  原因：Packer 模板使用旧版语法。修复：将"type": "shell"改为"type": "shell"（新版仍支持，但需确认文档），或升级模板到 HCL2 格式。

4.3 Terraform 部署：从init到apply的逐阶段验证

阶段一：初始化与 Provider 验证

cd terraform-vault terraform init

成功标志：终端输出Terraform has been successfully initialized!且.terraform/providers/registry.terraform.io/digitalocean/digitalocean/目录存在。若报错Failed to query available provider packages，检查DIGITALOCEAN_TOKEN是否设置正确，或网络是否能访问registry.terraform.io。

阶段二：计划（Plan）与安全审查

terraform plan -var 'env=staging' -var 'domain=example.com'

此命令不执行任何操作，只生成执行计划。必须人工审查以下三点：

1. digitalocean_droplet.vault的size是否为s-2vcpu-4gb（低于此规格可能导致 Vault OOM）
2. digitalocean_firewall.vault的inbound_rule中8200端口的source_addresses是否为你的可信 IP 段（如["192.168.1.0/24", "203.0.113.5"]）
3. acme_certificate.vault的domain是否为你拥有的域名（如vault-staging.example.com）

阶段三：执行（Apply）与关键等待点

terraform apply -var 'env=staging' -var 'domain=example.com' -auto-approve

-auto-approve跳过交互确认，适合 CI 流水线。执行中会经历：

• Droplet 创建（约 45 秒）
• 浮动 IP 绑定（约 5 秒）
• DNS 记录创建（DO API 立即返回，但全球生效需 30-60 秒）
• TLS 证书申请（DNS01 挑战约 2-3 分钟）
• Vault 初始化（vault operator init约 10 秒）

最关键的等待点：当看到null_resource.vault_wait开始执行时，终端会持续输出Waiting for Vault...。此时打开新终端，手动验证：

# 替换为你的浮动 IP curl -k https://192.0.2.1:8200/v1/sys/health # 应返回 JSON：{"initialized":true,"sealed":true,"standby":false,...}

如果超时（>5 分钟），立即检查：

• journalctl -u vault -n 50查看 Vault 日志
• ss -tlnp | grep :8200确认端口是否监听
• openssl s_client -connect 192.0.2.1:8200 -servername vault-staging.example.com测试 TLS 握手

阶段四：初始化结果提取与解封
执行完成后，本地会生成vault-init-staging.json。用jq解析：

jq -r '.unseal_keys_b64[0]' vault-init-staging.json # 第一个密钥 jq -r '.root_token' vault-init-staging.json # root token

解封操作（在 Droplet 上执行）：

ssh root@192.0.2.1 vault operator unseal # 粘贴第一个密钥 vault operator unseal # 粘贴第二个密钥 vault operator unseal # 粘贴第三个密钥 # 输出 "Sealed: false" 即成功

此时curl -k https://192.0.2.1:8200/v1/sys/health的"sealed"字段会变为false。

4.4 Vault 初始配置：从解封到第一个密钥的完整链路

解封只是开始，真正的价值在于快速创建第一个可使用的密钥。以下是三步极简流程：

第一步：登录并创建策略

# 使用 root token 登录 export VAULT_ADDR="https://vault-staging.example.com:8200" export VAULT_TOKEN="s.xxxxxxxx" # 来自 vault-init-staging.json vault login $VAULT_TOKEN # 创建一个只读数据库凭证的策略 vault policy write db-reader - <<EOF path "database/creds/readonly" { capabilities = ["read"] } EOF

database/creds/readonly是路径，不是实际存在，它定义了未来数据库引擎的访问点。

第二步：启用数据库秘密引擎

vault secrets enable -path=database database vault write database/config/my-mysql \ plugin_name=mysql-database-plugin \ connection_url="{{username}}:{{password}}@tcp(10.0.0.1:3306)/" \ allowed_roles="readonly" \ username="vault-admin" \ password="strong-password"

10.0.0.1是你的 MySQL 内网地址，vault-admin是 MySQL 中已创建的专用用户（权限：GRANT SELECT ON *.* TO 'vault-admin'@'%'）。

第三步：创建角色并获取第一个动态凭证

vault write database/roles/readonly \ db_name=my-mysql \ creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON *.* TO '{{name}}'@'%';" \ default_ttl="1h" \ max_ttl="24h" # 立即生成一个临时 MySQL 用户 vault read database/creds/readonly # 输出： # Key Value # --- ----- # lease_id database/creds/readonly/abcd1234... # lease_duration 3600 # lease_renewable true # password n9Xx...YzQ # username v-root-readonly-efgh5678

这个username/password组合是动态生成、带 TTL 的，用完即焚。把它交给你的应用，就完成了 Vault 的首次价值交付。

5. 常见问题与实战排障技巧

5.1 网络与 TLS 类问题：90% 的失败源于此

注意：所有网络诊断必须在Droplet 内部执行（ssh root@ip），而非本地。因为本地网络可能受防火墙、代理影响，而 Droplet 内部能真实反映服务状态。

5.2 Vault 自身状态类问题：解封、密封、崩溃三态解析

Vault 有三种核心状态，每种对应不同处理逻辑：

状态一：Sealed: true（密封）
这是 Vault 启动后的初始状态，表示加密密钥未加载。必须执行vault operator unseal输入至少key-threshold个密钥。

• 典型错误：输入密钥时多了一个空格或换行符 → 报错invalid key。解决方案：用printf "%s" "$KEY" \| vault operator unseal确保无多余字符。
• 致命错误：丢失超过key-threshold-1个密钥 → 无法解封，只能重建实例。预防：初始化后立即将vault-init.json加密备份到至少两个离线位置（U 盘+纸质）。

**状态二：`Sealed: false