这是我对这个问题的看法。它有一定的限制,但至少密码没有存储在秘密中,并且对托管服务提供商不可用。我真的很欢迎 cmets 进行改进。同样,我真正想要的是使密码可用于某些构建,但将此密码存储在无法访问文件系统和机器的人的范围内
jenkins 的某些工作依赖于存储在 ENV 变量中的密码。 Jenkins 应该在没有这个密码的情况下继续工作,如果没有提供密码,只有特定的构建应该失败。例如,这些是数据库备份构建。
密码可以存储在 jenkins/secrets 中,但这意味着托管服务提供商可以访问此密码。这是不希望的。当 jenkins 启动时,密码作为 ENV 变量提供。
为此,必须将它们添加到 /etc/default/jenkins 并添加到 /etc/init.d/jenkins 中的守护进程参数中
将密码添加到 /etc/default/jenkins
SPECIAL_PASSWORD=123
密码由 /etc/init.d/jenkins 处理,并通过以下方式添加到 DAEMON_ARGS:
if [ -n "$SPECIAL_PASSWORD" ]; then
echo "Using SPECIAL_PASSWORD provided by /etc/default/jenkins"
DAEMON_ARGS="$DAEMON_ARGS --env=SPECIAL_PASSWORD=$SPECIAL_PASSWORD"
fi
这使得 SPECIAL_PASSWORD 在 jenkins 启动时可用。密码在 jenkins 的 SystemInfo 选项卡中作为 ENV 变量可见,并且可以被 jenkins 构建作业使用。
不希望将密码存储在 /etc/default/jenkins 中。这使其再次可供托管服务提供商使用。
这就是为什么我实现了以下脚本
1.询问密码
2. 将 SPECIAL_PASSWORD 添加到 /etc/default/jenkins
3.重启詹金斯
4. 将/etc/default/jenkins 恢复为原版本,无需密码
#!/bin/bash
# The script requies passwords for starting jenkins and places this password
# in the jenkins env. It then restarts jenkins after which the file is returned
# to the original
read -s -p "Enter SPECIAL_PASSWORD: " SPECIAL_PASSWORD
cp /etc/default/jenkins /etc/default/jenkins.bck
echo "SPECIAL_PASSWORD=$SPECIAL_PASSWORD" >> /etc/default/jenkins
echo "Contents of the jenkins env"
service jenkins restart
cp /etc/default/jenkins.bck /etc/default/jenkins
限制:
1.在/etc/default/jenkins中可以找到短暂的密码。
2. 密码以纯文本形式作为整个 jenkins 的 ENV 变量提供。