mirror of
https://github.com/certimate-go/certimate.git
synced 2026-04-26 05:05:56 +03:00
[GH-ISSUE #97] [Feature] 实现cert-agent，在任何服务器上自动部署证书 #78
Labels
No labels
announcement
backlog
bug
declined
documentation
duplicate
enhancement
good first issue
good first issue
help wanted
invalid
pull-request
question
stale
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/certimate#78
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fslongjin on GitHub (Sep 25, 2024).
Original GitHub issue: https://github.com/certimate-go/certimate/issues/97
功能描述
实现cert-agent，在任何服务器上自动部署证书。
这个agent负责把证书下载到统一的路径，服务器上的nginx设置证书路径即可。
动机
如果certimate服务器拥有访问其他机器的ssh权限，是不安全的。
@usual2970 commented on GitHub (Sep 26, 2024):
感谢反馈～关于 cert-agent 这块可以讨论一下，我觉得没必要，理由如下：
安全考虑：certimate 服务器本身就是你自己的服务器，你自己的服务器拥有其它服务器的访问权限，应该不是个问题。反而cert-agent直接部署在其它服务器上，是不是也会产安全疑虑。
操作麻烦：你要一个个服务器安装 agent
有现成的替代：既然要一个个服务器安装，何不用 acme.sh 呢
可能我的考虑并不周全，你可以参考一下😀
@fslongjin commented on GitHub (Sep 26, 2024):
你这个考虑有点不对啊。
Agent本身就是对权限进行了限制，就像很多生产环境的软件是通过agent来做发布，而不是中央服务器通过ssh登上去执行发布脚本。
把所有服务器的密码或者登录凭证放在同个机器上，本身就是一个非常不安全的事情。
第二个点，安装certimate的机器，极有可能没法直接访问到目标机器。场景就是，我个人有几个在不同云厂商的服务器，在某个服务商那里，我可能只会有一个公网IP。然后有一台机，作为NAT网关机器，其他的都是没有公网ip。
这个组网本身就是安全考量。假如我部署certimate在a云，不通过agent，他就没有办法部署证书到T云的机器上，这个本身好像也不太对.
这种情况下就完全不能用ssh连接，因为这样子打破了网络安全边界。而且正常来说，网关一般我都会拒绝掉入方向的ssh的端口，而是通过跳板机的方式登上去。
@ycq3 commented on GitHub (Sep 27, 2024):
我认为提供一个api，可以通过api获取证书信息（api可以做鉴权之类的操作），自己通过shell脚本部署证书即可。既不用Agent又可以满足实际需求
@sgpublic commented on GitHub (Sep 27, 2024):
我讲一下我的意见奥：
这个我觉得其实是为了给不同的系统、环境提供一个相同的接口，能很方便的完成分布式，而对于 certimate 这个项目来说，这只是一个部署 ssl 证书的小项目，如此大动干戈搞个 agent 然后最后就部署个证书，是否成本过高了。
如果部署证书需要执行前置和后置命令，就算是使用 agent 执行，也是需要 agent 的来执行的，
虽然这句话看上去是个废话，但这样的话你就把你服务器 shell 的保护从 sshd 交给了 agent，再加上 certimate 使用的是 pocketbase 作为后端框架，这个框架还在积极开发中，我个人认为相比 pocketbase，目前可能还是 sshd 更可信一点。所以我觉得对于 certimate 这个项目来说，使用 agent 也许无法提高安全性。
既然如此，只要你能访问到 ssh，你就能用相同的办法让 certimate 也访问到。前文提到了，既然都需要执行 shell 命令，直接用 ssh 登陆和让 agent 帮你执行我觉得差不多。
其实我个人觉得，你不如专门为 certimate 创建一个独立的用户，专门用于证书部署，也许这样安全性还能更高。
@fslongjin commented on GitHub (Sep 27, 2024):
你可能误解了我的意思，我上面issue原话是：
也就是说，agent负责维护一个文件夹，比如
/opt/cert-agent/<每个站点的名称>
然后nginx配置文件是用户自己去设置证书路径为
/opt/cert-agent/<每个站点的名称>，而不需要agent去执行一些操作。agent负责下载&维护好这个文件夹就行@fslongjin commented on GitHub (Sep 27, 2024):
对，我的意思也类似这个，我所描述的是这个意思：
有个程序负责下载证书到某个固定格式的路径下面，然后nginx的配置文件里面咱们指定好路径就行了。
@sgpublic commented on GitHub (Sep 27, 2024):
你说的有道理，然后 agent 的宿主机自己监控这个文件夹，有变动的时候自动重载。确实。
@usual2970 commented on GitHub (Nov 2, 2024):
后续没有这方面的迭代计划
@fslongjin commented on GitHub (Nov 15, 2024):
我认为只需要提供一个用于轮询的api就行了，能够轮询去查询“当前机器的各个证书的状态” 这样灵活度就高很多了。