Currently we inject secrets into the Jenkins container via environment variables in the setup script:
# munge the private key so that we can pass it into an env var sanely
# and then unmunge it in our startup script
echo PRIVATE_KEY=$(cat ${DOCKER_CERT_PATH}/key.pem | tr '\n' '#') >> _env
echo 'Edit the _env file to include a JENKINS_PASSWD and GITHUB_* config'This blueprint can be a first use case for implementing secrets management via Vault. Although supporting secure injection for launching production containers requires the help of a scheduler, we can get away without that in the case of a one-off container like a Jenkins master. This will let us build an example workflow for secrets management that we can then enhance when Mariposa is completed.
Currently we inject secrets into the Jenkins container via environment variables in the setup script:
This blueprint can be a first use case for implementing secrets management via Vault. Although supporting secure injection for launching production containers requires the help of a scheduler, we can get away without that in the case of a one-off container like a Jenkins master. This will let us build an example workflow for secrets management that we can then enhance when Mariposa is completed.