标签频道
Vault
该标签下的文章、提问与讨论帖。
现象或背景 最近帮几个团队做安全加固复盘，翻了一圈发现"密钥"这块几乎是重灾区——数据库密码、第三方 API key、签名密钥，散落在代码仓库、docker-compose、环境变量、配置文件里。有人把密钥写死在 config 里 comm
背景： 我做了 5 年安全加固，最近给一个 K8s 1.28（containerd 1.7、内核 5.15）的多租户 SaaS 做凭据管理加固。现在所有服务的密钥（数据库密码、第三方 API key、TLS 私钥）都是这么走的： - 写进
背景 我负责一套约 120 个微服务（Java/Go 混合，K8s 1.27 自建集群）的安全加固。过去半年把一批"长期高权限账号"往最小权限收敛：cluster-admin SA 拆成 per-service 的窄 RoleBinding
«作者视角：10 年经验安全工程师，专注安全加固与风险防范 栈：HashiCorp Vault 1.15、Spring Boot 3.2 / jjwt 0.12.6、Nginx 1.25、K8s 1.27、OpenSSL 3.1 结论先行：
背景 我负责一套 80+ 微服务（Java/Go 混合，K8s 1.27 自建集群，无云厂商）的安全加固。凭据来源非常分散： - K8s Secret：约 40 个服务启动时读取（DB 密码、Redis 密码、内部 API Token） -
背景 我负责一套 K8s 1.28 集群（3 节点，VPC 内），跑着 20 个微服务。每个服务平均 5~8 个密钥：MySQL 密码、Redis 密码、Kafka SASL 密码、第三方 API Key（支付、短信、地图）。 现状：全部用
【背景】 我负责一家做 SaaS 的公司安全加固，约 200 个微服务（Java/Go 混合，K8s 1.28 自建集群，无云账号）。最近做完一轮凭据盘点，发现三类"长寿命凭据"仍然大量存在： 1) 第三方 API Key（对象存储、短信网
先说背景：最近帮几个团队做安全加固复盘，翻了一圈发现"密钥"这块几乎是重灾区——数据库密码、第三方 API key、签名密钥，散落在代码仓库、docker-compose、环境变量、配置文件里。有人把密钥写死在 config 里 commi
【背景】 我负责一个 20 人团队的 Spring Boot 微服务（Java 17、Spring Boot 3.1，跑在 3 节点 K8s 1.28 上，自建集群、无云账号）。目前 DB 密码、第三方 API Key、JWT 签名密钥都写
文
标题
摘要