我们有一套成熟的架构
监控告警部分:
1. 证书的核心是域名,我们的域名配置存在 GitHub 上,通过 Terraform + Atlantis 服务,经 PR 审批后才能由其他人交叉验证后再执行 apply ,最终生效
2. 每三个小时,会有自动化的 Action 拉取 Terraform state 里的 DNS 记录,连接每一个域名的 443 端口,如果可连通且不超时,则加入到待探测的列表中(域名、解析值都要放进去);对于例外的,比如非 443 端口的、或者与业务相关但非我公司域名的,也支持额外配置
3. 根据列表生成一套 telegraf 配置文件,配合使用它的 x509_cert 插件,拉起 telegraf --once 后,就能拿到这些域名的 HTTPS 证书的过期情况,并且写入到远程时序库里
4. 监控、告警配置在了 Grafana 里,取同一个域名的最小值(因为需要包含域名本身的过期时间、上游签发商的过期时间),过期前 10 天会发出告警
证书申请部分:
1.
acme.sh 专门跑在一台机器上,新域名证书首次申请签发需手动执行 --issue ,后续会有 cron 自动跑续期
2. 申请证书也是用了 DNS 验证,DNS API 用了一套基于 Terraform 的,但是一个独立的仓库,没有 Atlantis 人肉参与审批。直接通过 Actions 自动化运行,所以约束了一下:提交的内容只有 json 的 [{name,value}, {...}] ,收到 push 后立即跑 Action:检查是否是 `_acme-challange` 的 name 、套模板,模板里写死 type=TXT ,避免出现意外情况。而后就是 tf init / tf apply -auto-approve
3. 而后过个 2 、3 分钟,新的解析就会生效,域名证书的签发在正常情况下都会跑完
4. 签发完后,执行 --deploy ,会把证书、私钥存到我们的 Vault 里。因此我们的 Vault 里会持续有最新的 HTTPS 证书文件
证书更新部分:
这一趴搞法比较多,主要分三种情况:
1. 证书直接配在云服务商的实例里:由我们直接通过预先配置在 Vault 里的 RAM 管理员角色,以 STS Token 的形式,通过各云的 cli 命令行程序执行配置的更新(也是跑在
acme.sh 那台机器上,随 cron 一起更新)
2. 证书被配在了不支持 API 更新的服务商那里,人肉处理
3. 被配在了某些业务团队自己的 Nginx 里:给业务团队配置 Vault 的 AppRole ,他们自己来获取自己该拿的证书文件,自己更新