Yes, storing your ssh keys directly on a build node is a bad practice. Nodes can be replicated, deleted, or given access to from other systems, and you don't want to lose track of what systems have access to your secrets. You should also not pass them directly into the build job, either as a parameter or as an environment variable. This can cause a huge ...


You have to execute ssh-keyscan. For example to ssh to a host (github.com here ) you have to run below script # Add ssh key to help cloning private github repo ssh-keygen -t rsa -N "" -f secrets/ssh/github_rsa PUB_KEY=$(cat secrets/ssh/github_rsa.pub) PRV_KEY=$(cat secrets/ssh/github_rsa) echo "${PRV_KEY}" >> ~/.ssh/github_rsa chmod 600 ~/.ssh/...


Found this --> Passing secrets to a Docker container Environment variables appear the preferred method - will need to run a prebuild script to fetch the secrets and then follow this https://docs.docker.com/compose/environment-variables/ @Mods feel free to close as a duplicate


Richard, you are right that Cloud and HSMs are two contradictory concepts. To fulfill availability and elasticity requirements for key management and cryptographic operations a middleware is needed controlling all the hardware. This is basically done by the cloud KMS available now. With AWS Cloud HSM, there is no fully managed availability and elasticity ...


So having gone backwards and forward over this for a couple of weeks, Azure has confirmed to me in-person that the only way to utilise FIPS-140 Level 2 certified hardware security modules in Microsoft Azure is to use Azure Key Vault.

Only top voted, non community-wiki answers of a minimum length are eligible