和我一起学vault
现代软件之所以能够安全、稳定地运行，离不开各种机密信息Secrets的支撑。这些机密信息包括访问凭证、加密密钥、认证证书以及其他关键安全数据，是应用程序实现持续运行与安全通信的基础。 Vault提供对这类机密数据的集中化、安全化管理能力，从而降低凭据泄露风险，并为应用系统构建统一的安全控制体系。
1.安装配置
wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vault
# /etc/vault.d/vault.hcl
ui = true
# 后端支持:
# 1. 内置存储系统(Vault集群中节点都存储数据副本，使用RAFT共识算法保证一致性) 支持HA
# 2. 外部存储系统(亚马逊云,google云，微软云，MYSQL，包括数据库) 可能支持HA
# 3. 本地文件系统 不支持HA
# 4. 内存文件系统 不支持HA
storage "file" {
path = "/opt/vault/data"
}
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/opt/vault/tls/tls.crt"
tls_key_file = "/opt/vault/tls/tls.key"
}
这里使用vault的默认配置。默认情况下，Vault会在8200端口开启UI界面，首次打开页面需要进行初始化，需要设置Shamir密钥共享的参数。(1.master主密钥的分片数量 2.解封阈值) 设置成功后，Vault将生成root令牌以及关于master密钥的全部分片，随后只需要输入设置阈值的数量的分片密钥即可以解封数据，开启系统。
如上图所示，在Vault中，原始数据使用数据加密密钥DEK进行加密存储，数据加密密钥使用主密钥加密保存(密码学中的信封加密)。 主密钥仅存在于内存中，一旦Vault重启，主密钥即消失，只能通过Shamir分片密钥重构主密钥
2.基本操作
Vault是一个基于插件的开放式系统，总体包括一下三种类型插件:
- 认证插件处理认证数据流，同时决定客户端如何访问Vault
- 通用的机密插件，生成、存储、管理敏感信息
- 数据库插件，管理用于管理客户端访问数据库时使用的动态凭据
在Vault系统中，客户端想访问对应资源需要先进行身份认证，Vault返回(关联资源访问控制策略)的对应身份令牌。 客户端使用该令牌申请一个具有生命周期的动态资源操作凭证，然后用该凭证去操作对应的资源。
下面命令打印出vault支持的相关插件及其版本信息。 可以看到主流云厂商，aliyun，aws，gcp，azure的认证插件与加密插件全部支持，数据库插件方面mongodb，mysql，postgres，redis也全部支持
vault plugin list secret
Name Type Version
---- ---- -------
alicloud auth v0.22.0+builtin
approle auth v1.21.3+builtin.vault
aws auth v1.21.3+builtin.vault
azure auth v0.22.0+builtin
cert auth v1.21.3+builtin.vault
cf auth v0.22.0+builtin
gcp auth v0.22.0+builtin
github auth v1.21.3+builtin.vault
jwt auth v0.25.0+builtin
kerberos auth v0.16.0+builtin
kubernetes auth v0.23.1+builtin
ldap auth v1.21.3+builtin.vault
oci auth v0.20.1+builtin
oidc auth v1.21.3+builtin.vault
okta auth v1.21.3+builtin.vault
pcf auth v1.21.3+builtin.vault
radius auth v1.21.3+builtin.vault
userpass auth v1.21.3+builtin.vault
cassandra-database-plugin database v1.21.3+builtin.vault
couchbase-database-plugin database v0.15.0+builtin
elasticsearch-database-plugin database v0.19.0+builtin
hana-database-plugin database v1.21.3+builtin.vault
influxdb-database-plugin database v1.21.3+builtin.vault
mongodb-database-plugin database v1.21.3+builtin.vault
mongodbatlas-database-plugin database v0.16.0+builtin
mssql-database-plugin database v1.21.3+builtin.vault
mysql-aurora-database-plugin database v1.21.3+builtin.vault
mysql-database-plugin database v1.21.3+builtin.vault
mysql-legacy-database-plugin database v1.21.3+builtin.vault
mysql-rds-database-plugin database v1.21.3+builtin.vault
postgresql-database-plugin database v1.21.3+builtin.vault
redis-database-plugin database v0.7.0+builtin
redis-elasticache-database-plugin database v0.8.0+builtin
redshift-database-plugin database v1.21.3+builtin.vault
snowflake-database-plugin database v0.15.0+builtin
ad secret v0.21.0+builtin
alicloud secret v0.21.0+builtin
aws secret v1.21.3+builtin.vault
azure secret v0.23.0+builtin
consul secret v1.21.3+builtin.vault
gcp secret v0.23.0+builtin
gcpkms secret v0.22.0+builtin
kubernetes secret v0.12.0+builtin
kv secret v0.25.0+builtin
ldap secret v1.21.3+builtin.vault
mongodbatlas secret v0.16.0+builtin
nomad secret v1.21.3+builtin.vault
openldap secret v0.17.0+builtin
pki secret v1.21.3+builtin.vault
rabbitmq secret v1.21.3+builtin.vault
ssh secret v1.21.3+builtin.vault
terraform secret v0.13.0+builtin
totp secret v1.21.3+builtin.vault
transit secret v1.21.3+builtin.vault
2.1认证插件
- github认证
github认证必须与github组织绑定，组织内成员可以登录vault平台，认证成功后，Vault会生成一个会话token，并将其绑定到当前用户预设的策略上，从而决定该token的权限范围
vault auth enable github
vault write auth/github/config organization=cauc-peter-gmail-com // cauc.peter@gmail.com组织成员均可以访问vault
# github平台创建Personal Access Token
vault login -method=github token="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"
Key Value
--- -----
token hvs.CAESIFLpifwS9Pa-nTR2ScNXwy4JGfE3LtxNlezqQ00AZPbzGh4KHGh2cy45RUJ4aWNSMlBwQTN1ZE5aYjlHVDN0QUw
token_accessor 9Ed2kc2XvttHiwqbYSyzqXtY
token_duration 768h
token_renewable true
token_policies ["default"]
identity_policies []
policies ["default"]
token_meta_org cauc-peter-gmail-com
token_meta_username ewall-cauc
# 未设置预设策略的认证方式，系统将登录用户绑定至默认策略，使用如下命令可以查看default策略的权限范围
vault policy read default
# 使用如下命令可以将组织内dev组的用户，绑定至vault的dev策略
vault write auth/github/map/teams/dev value=dev
- userpass认证
userpass认证方式允许，使用用户名密码方式登录valut平台，同样认证成功后，会获得一个绑定预设权限的会话token
vault auth enable userpass
vault write auth/userpass/users/test password=test policies=default
vault login -method=userpass username=test
2.2数据库插件
数据库机密引擎通过基于预设策略动态生成数据库访问凭证，避免在代码或配置文件中硬编码账号和密码，从而显著提升应用系统的安全性。同时，各服务使用独立凭证，有助于实现精细化审计与权限隔离。
vault secrets enable database
- 动态角色，应用向vault申请服务申请帐号密码时，每次都会创建一个带有过期时间的新数据库账号(适用于微服务，CI/CD，临时任务)
- 静态角色，vault会绑定一个固定的数据库账号，同时定期修改这个账号的密码(兼容旧系统)
下面以postgresql数据库为例，分别演示如何配置使用动态角色与静态角色
动态角色
# 创建数据库连接字符串
# 注意: 这里test用户在postgresql必须具有createrole的权限
vault write database/config/postgresql \
plugin_name="postgresql-database-plugin" \
allowed_roles="postgres-dev,postgres-dev-static" \
connection_url="postgresql://{{username}}:{{password}}@192.168.5.170:5432/test" \
username="test" \
password="test" \
password_authentication="scram-sha-256"
# 创建预定义数据库角色
vault write database/roles/postgres-dev \
db_name="postgresql" \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
# 务必保存帐号密码及id，后续操作都基本该id
vault read database/creds/postgres-dev
Key Value
--- -----
lease_id database/creds/postgres-dev/o2rnQmjYEG62D1ivx945z3pc
lease_duration 1h
lease_renewable true
password hm4VNxJRkERU-8QjDtYe
username v-root-postgres-wVdxRb1egh1xAweUjEfD-1771047941
# 测试登录
psql -U v-root-postgres-wVdxRb1egh1xAweUjEfD-1771047941 -d test
\du+
List of roles
Role name | Attributes | Member of | Description
-------------------------------------------------+------------------------------------------------------------+-----------+-------------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} |
test | Create role | {} |
v-root-postgres-wVdxRb1egh1xAweUjEfD-1771047941 | Password valid until 2026-02-14 14:45:46+08 | {} |
# 查看预定义数据库角色的关联密钥
vault list sys/leases/lookup/database/creds/postgres-dev/
o2rnQmjYEG62D1ivx945z3pc
vault lease lookup database/creds/postgres-dev/o2rnQmjYEG62D1ivx945z3pc
Key Value
--- -----
expire_time 2026-02-14T06:45:41.699753535Z
id database/creds/postgres-dev/o2rnQmjYEG62D1ivx945z3pc
issue_time 2026-02-14T05:45:41.699753194Z
last_renewal <nil>
renewable true
ttl 28m7s
# 账户密码撤销
vault lease revoke database/creds/postgres-dev/o2rnQmjYEG62D1ivx945z3pc
静态角色
vault write database/config/postgresql \
plugin_name="postgresql-database-plugin" \
allowed_roles="postgres-dev,postgres-dev-static" \
connection_url="postgresql://{{username}}:{{password}}@192.168.5.170:5432/test" \
username="test" \
password="test" \
password_authentication="scram-sha-256"
# 创建预定义数据库角色
vault write database/static-roles/postgres-dev-static \
db_name="postgresql" \
username="develop" \
rotation_period="24h" \
rotation_statements="ALTER USER \"{{name}}\" WITH PASSWORD '{{password}}';"
vault read database/static-creds/postgres-dev-static
Key Value
--- -----
last_vault_rotation 2026-02-14T06:32:58.381446726Z
password jdldcgVNCaTpCfO-Ytk7
rotation_period 24h
ttl 23h50m22s
username develop
# 强制轮换密码
vault write -f database/rotate-role/postgres-dev-static
vault read database/static-creds/postgres-dev-static
Key Value
--- -----
last_vault_rotation 2026-02-14T06:44:45.886929173Z
password 61iyN-nO6AE-HWJB-w90
rotation_period 24h
ttl 23h58m51s
username develop
# 删除静态角色，并不会删除数据库的develop用户
vault delete database/static-roles/postgres-dev-static
2.3机密插件
亚马逊云
下面以亚马逊云举例，机密插件的使用方法。
vault secrets enable aws
vault write aws/config/root \
access_key=AK*AJWVN***FOFT***NA \
secret_key=Rm****3hgMVo*****xOs5nHLeLX****r7ZJ3Nt0i \
region=us-east-1
亚马逊云支持多种认证，每种认证方式适用不同的场景:
- iam_user，创建绑定预设策略的iam用户，到期后用户被删除，需同步其他亚马逊服务，速度慢
- assumed_role，通过在亚马逊平台提前设置定义权限集合，申请临时凭证，不新增用户
- federation_token，不会新增iam用户，权限策略是调用者本身权限子集
- session_token，使用已有账户生成临时凭证，权限不变，不能附加新策略，增加过期时间
iam_user
最传统、最彻底的隔离方式。每个申请者都会获得一个独立的、在AWS控制台可见的IAM用户。
优点，权限隔离最彻底，审计日志中可以清晰看到每个动态用户的操作。
缺点，AWS创建用户并同步到全球节点需要时间有时长达数秒，且账号多了会触及AWS IAM用户数量限制。
通常适用于，需要长期租约如几天或几周且对审计要求极高的旧式应用程序。
vault write aws/roles/iam-develop \
credential_type=iam_user \
policy_document=-<<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
}
]
}
EOF
vault read aws/creds/iam-develop
Key Value
--- -----
lease_id aws/creds/iam-develop/GNwJlqTFKo9M3hGEWdYwQWe4
lease_duration 768h
lease_renewable true
access_key A****I3MRYPN3A2PTWUW
secret_key C****NatkIy6M7DPX+PSmaQKRY1Y3DDmG53tyPiE
session_token <nil>
# 权限撤销
vault lease revoke aws/creds/iam-develop/GNwJlqTFKo9M3hGEWdYwQWe4
assumed_role
Vault并不创建新用户，而是让它自己的根账号去执行sts:AssumeRole操作，代表某个已存在的IAM Role产生一套临时凭证。
这是一种借用身份的模式。预先在AWS定义好一个角色Role，比如下面使用的test角色，每次申请时就像穿上这件衣服一样获取临时令牌。
优点，速度极快，不增加IAM用户数量，符合AWS云原生安全最佳实践。
缺点，需要预先在AWS侧手动创建Role并配置好可信实体，配置相对复杂。
通常适用场景，现代云原生架构，高频、短期的凭证申请
vault write aws/roles/ass-develop \
role_arns=arn:aws:iam::225176568795:role/test \
credential_type=assumed_role
vault write aws/sts/ass-develop ttl=30m
Key Value
--- -----
lease_id aws/sts/ass-develop/wn7wQ1oZJaGPU9gKpy0vfqqt
lease_duration 29m59s
lease_renewable false
access_key A****I3MRYPNXIRL6WKJ
arn arn:aws:sts::225176568795:assumed-role/test/vault-root-ass-develop-1771068434-hOD5RWDSCeqL7Ci5A8R1
secret_key v****ogbDh9kWVdgtiZPyCTlQbEq3V3lunUcRIMR
security_token I****3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJIMEYCIQDoav/vqWMcpQL/E7kKasa+ze2CkGRGDtusMHPWEDf/bwIhAIKakZJa/oU4zpRtEjGIa23R9SPvi6vkj40KsQWZuJetKsMCCAUQABoMMjI1MTc2NTY4Nzk1IgxltEOyXXHwu30ysQMqoALO9jXognqnqviQXQOGzOSxuO/XT012k5VCk9/fgjM12oUTQShAgUz9KkFPPz2y+1WmQto5VpZp+qoKd9UeJWahMsITO4Ug75OnYMUGv8gbmH8rprQsjfrIsjWIR3cFYx7uKCLqI7XKJTNMCCYq58FGq7QFDEfgnbCwsZP6YYi9z9aVoQtYa+ChxbxZBgXgUWkLeYO/MzyH82YloT2WGiLshCcHM5VU20HpYSjnXFRy055HvmqhfzhfmQEq+t9ueNffE+YGXph3P6NYhMMpGBsFdGCtbpa2d3MZ/cdaOnvRS+2w8azt1I1aDRquq7wf41ObhBV0a3tlo2xdxxYla7UhWTZYIPGKBxLM6V9yxooH6Si0nsIe7udo8OjOlyCBsIIwk7jBzAY6nAFLA+jgcNAfC/odZ9xezhV8S2Yar4sQYBNk9FZEQ2OmbMTqvIswuOp4HCWjTkHljswmHMZ0WU/qNCQrmQWhrcVlMTxkQJg0D7NzmQjeNFVIrCGzuk6z/Z1zymEgRhNuu3SEJZ6us028AluJQzTZew47pisrTiztuDnbFAwXqLXFPzgCT58RlPS9JtILx8Bx0AdU0dnkM5hmfKQK59I=
session_token I****3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJIMEYCIQDoav/vqWMcpQL/E7kKasa+ze2CkGRGDtusMHPWEDf/bwIhAIKakZJa/oU4zpRtEjGIa23R9SPvi6vkj40KsQWZuJetKsMCCAUQABoMMjI1MTc2NTY4Nzk1IgxltEOyXXHwu30ysQMqoALO9jXognqnqviQXQOGzOSxuO/XT012k5VCk9/fgjM12oUTQShAgUz9KkFPPz2y+1WmQto5VpZp+qoKd9UeJWahMsITO4Ug75OnYMUGv8gbmH8rprQsjfrIsjWIR3cFYx7uKCLqI7XKJTNMCCYq58FGq7QFDEfgnbCwsZP6YYi9z9aVoQtYa+ChxbxZBgXgUWkLeYO/MzyH82YloT2WGiLshCcHM5VU20HpYSjnXFRy055HvmqhfzhfmQEq+t9ueNffE+YGXph3P6NYhMMpGBsFdGCtbpa2d3MZ/cdaOnvRS+2w8azt1I1aDRquq7wf41ObhBV0a3tlo2xdxxYla7UhWTZYIPGKBxLM6V9yxooH6Si0nsIe7udo8OjOlyCBsIIwk7jBzAY6nAFLA+jgcNAfC/odZ9xezhV8S2Yar4sQYBNk9FZEQ2OmbMTqvIswuOp4HCWjTkHljswmHMZ0WU/qNCQrmQWhrcVlMTxkQJg0D7NzmQjeNFVIrCGzuk6z/Z1zymEgRhNuu3SEJZ6us028AluJQzTZew47pisrTiztuDnbFAwXqLXFPzgCT58RlPS9JtILx8Bx0AdU0dnkM5hmfKQK59I=
ttl 29m59s
federation_token
Vault调用sts:GetFederationToken。它利用Vault根账号的权限，切出一部分权限封装成一个令牌。
这是一种授权委托模式。生成的凭证权限不能超过Vault根账号本身的权限，它是根账号权限的一个交集或子集。
优点，不需要提前在AWS创建Role，管理成本低。
缺点，无法像assumed_role那样突破根账号的权限边界。此外，AWS对此接口的调用频率限制较严。
一般运用于，临时给外部合作伙伴或特定任务分配一个受限的只读/特定操作权限，且不想动IAM架构时。
vault write aws/roles/fed-develop \
credential_type=federation_token \
policy_document=-<<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": "*"
}
]
}
EOF
vault read aws/creds/fed-develop
Key Value
--- -----
lease_id aws/creds/fed-develop/9gVoQ760Ue9QQH8YxIlMbY5s
lease_duration 1h
lease_renewable false
access_key A****I3MRYPNZP4V7FHW
secret_key V****73j445jx4vpmPJ0h+fhwiVFxxVF1tyizBe4
security_token I****3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJHMEUCIBm5MSA9xL5Ooxv5qXQ/lXGEjh2jEqGaobIp2blEE5FCAiEAr+kF9QvFPiuYbD8/xVek8YyhxPGc2rwTOfovVQ3Hxr4qrAIIBRAAGgwyMjUxNzY1Njg3OTUiDC7TqfKzBMA1dx/gRyqJAm8Uns+INSNyOkoZQNSUfw/yXByZZgHIxl0fEbWeloXsgnO69bsXg2eFn2pngNySPfql9h7vWjrsMUxxwfiNCYqvpbJAFPJcAdbcN68KuqXy92tcUHIF4Yyfno9EPwjt3os9zC7JJOwomuS09/AYOMcaHCGqy83E2XKijKvaM7HSdmXYsJtmyoChXY7BBjkMe1lQTbd8296WK1VFzkhxtSN16XOTnQKdPsc4q9shPQxfUe/QwOW9EzgwW5lqLmnwVkqw6hIQXY9OuB+088Fv16EugL82PK5bt3ZC7FwgxWJS17x7tpuUfH8qiwhsgy1xDyauQIuTFUKXkeTRq1/h+UjohR4Uab20Iu0w8bjBzAY6mQGVcM14JDjjibjTCflFxBU1GkUwQQ6Ro9QgVt52+EcGHqMhdCuhYsgeoSZgnfNcb5whCgYPVOmbZAHdfAfmjaBxoIF6hdPXIJH+UYoqryxe7R2k6DHzKDfJpacytA0ccHSM1fYsjM+tjyA5lEcTiS3eF5zoV8UBgJdpclrbYm331gNBK4OdoC89YzyehX/W8MpNAemWJhwZoU4=
session_token I****3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJHMEUCIBm5MSA9xL5Ooxv5qXQ/lXGEjh2jEqGaobIp2blEE5FCAiEAr+kF9QvFPiuYbD8/xVek8YyhxPGc2rwTOfovVQ3Hxr4qrAIIBRAAGgwyMjUxNzY1Njg3OTUiDC7TqfKzBMA1dx/gRyqJAm8Uns+INSNyOkoZQNSUfw/yXByZZgHIxl0fEbWeloXsgnO69bsXg2eFn2pngNySPfql9h7vWjrsMUxxwfiNCYqvpbJAFPJcAdbcN68KuqXy92tcUHIF4Yyfno9EPwjt3os9zC7JJOwomuS09/AYOMcaHCGqy83E2XKijKvaM7HSdmXYsJtmyoChXY7BBjkMe1lQTbd8296WK1VFzkhxtSN16XOTnQKdPsc4q9shPQxfUe/QwOW9EzgwW5lqLmnwVkqw6hIQXY9OuB+088Fv16EugL82PK5bt3ZC7FwgxWJS17x7tpuUfH8qiwhsgy1xDyauQIuTFUKXkeTRq1/h+UjohR4Uab20Iu0w8bjBzAY6mQGVcM14JDjjibjTCflFxBU1GkUwQQ6Ro9QgVt52+EcGHqMhdCuhYsgeoSZgnfNcb5whCgYPVOmbZAHdfAfmjaBxoIF6hdPXIJH+UYoqryxe7R2k6DHzKDfJpacytA0ccHSM1fYsjM+tjyA5lEcTiS3eF5zoV8UBgJdpclrbYm331gNBK4OdoC89YzyehX/W8MpNAemWJhwZoU4=
ttl 59m59s
session_token
Vault调用sts:GetSessionToken，这本质上是给Vault的根账号Root Config生成一个带过期时间的克隆体。
优点，最简单，几乎不需要额外配置。
缺点，无法附加新策略。意味着通过这个角色拿到的权限，跟你的vault write aws/config/root里的管理员权限相同。
适用场景，极少数情况。通常仅用于需要给某些不支持IAM Role的工具提供临时MFA验证后的会话，生产环境通常不建议使用，因为权限过大且无法收缩。
vault write aws/roles/ses-develop credential_type=session_token
vault read aws/sts/ses-develop ttl=60m
Key Value
--- -----
lease_id aws/sts/ses-develop/lFRrEnJazo5Uep2cUVGOjpI3
lease_duration 1h
lease_renewable false
access_key A****I3MRYPNUCQAQXPF
secret_key I****os1Y6wps1iT+LoEJ1yY0nmIIUlPIny4tFn9
session_token I****3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJIMEYCIQCvZc5uxYgNLGJzHGZxgBJJl96wBWtc3SZ8cpvEozTvbwIhAK79Dq9sXbVGcb6LzOZrUznljdY3YQpCfaYvi6QoZWEqKuoBCAUQABoMMjI1MTc2NTY4Nzk1IgyEEmBOJcmm83lPagwqxwEOAmcKaGZSLe5HJzJeswgEB0bVGGUQ/Yd8m6JI4Gdh5D+e8UOJxW3L4mxJ0yL/hUy8NdzTxXvCSlH8XrHre5yVJnb0IqXAi422Z7KIJXMiaI0EmI/kPLiuR9qElkTf9Z9FuTC9Bu2/xKN4l8IZOUNltNtuWW88PFrdne97wnQoUhg5cQJUALH7gcRrvn8FCLxSE1HIZlJRfuZdUQTKxLIsaayyTgaOojs7A7rpBSfcHpMkTzywvlP1/wtVvZxS8mwFnYCH7AGnMMG5wcwGOpcBIX2qVMLYEJXBsaksHCSBblgRc6JgEq3zaHsDGL0zgY/SQz2adl6aSKzgy/PXR01ib+KrXm+IyxiBXw5HHH7wUjTC4cA334teTciRFShyQmuRY6DVlSt+5ErQOEpw1Ms6FUHeT4yXf6UGZxnEpGdFUDj7k7Bhtk2SOWn3fBT1KQEdy54ZLkxY2EbCJ0e3ynEzZj89OkoUDg==
ttl 59m59s
ssh插件
ssh插件比较特殊，需要修改登录主机的sshd服务的相关配置，同时安装vault-ssh-helper程序 注意这里属于一次一密，每次重新登录主机，需要重新生成登录密钥
# 登录受控主机
# 1. 修改/etc/pam.d/sshd
注释
@include common-auth
@include common-password
新增
auth requisite pam_exec.so quiet expose_authtok log=/var/log/vault.log /usr/bin/vault-ssh-helper -config=/etc/vault-ssh-helper.d/config.hcl
auth optional pam_unix.so not_set_pass use_first_pass nodelay
# 2. 修改/etc/ssh/sshd_config配置
ChallengeResponseAuthentication yes
PasswordAuthentication no
UsePAM yes
# 3. 新增vault-ssh-helper程序配置，/etc/vault-ssh-helper.d/config.hcl
vault_addr = "https://192.168.5.225:8200"
ssh_mount_point = "ssh"
tls_skip_verify = true
allowed_roles = "*"
# vault平台侧
vault secrets enable ssh
ault write ssh/roles/otp \
key_type=otp \
default_user=root \
cidr_list=192.168.5.0/24
vault write ssh/creds/otp ip=192.168.5.5
3.安全溢价
引入Vault绝非仅仅是安装一个软件，它实际上推动了配置即机密向凭据即流动的架构转型。这种转型在提升安全性的同时，给程序开发带来了挑战。
- 连接池的信任危机，传统的数据库连接池假设密码是永恒的。在Vault模式下，应用必须具备自愈能力，能够识别认证失效并主动重新获取凭据。
- 生命周期同步，租约的过期时间与应用侧的缓存时间必须对齐。如果应用缓存了已过期的令牌，会导致大面积的任务失败。
- 启动依赖链，如果Vault挂了，整个微服务集群可能因为拿不到数据库密码而无法启动。这要求Vault本身必须具备极高的可用性。
Vault的引入是一次认知升级。虽然初期会觉得麻烦，但它带来的审计可追溯性和凭据动态化，是构建零信任网络Zero Trust Network不可或缺的基石。
安全不应以牺牲稳定性为代价。在下一章中，我们将探索如何让程序在Vault的动态世界里游刃有余。我们会一起编写支持动态感知的Python/Go后端逻辑，并详细拆解Sidecar模式下的配置自动化链路——利用Consul-template捕捉机密的每一次脉动，实现进程的无感知重载。敬请期待。