CI/CD is an important part of our team’s process. We regularly build small back-end web services to support the apps we build. We often use a combination of Node.js and MongoDB as a stack for services, and deploy them using Docker. As we keep ramping up our secure practices, we have been removing secrets embedded in projects using CredStash to store and serve our secrets. Since our servers are hosted at AWS, this is a good solution for us. CredStash is another topic entirely, but my team has it set up on their workstations and the build servers are configured to use it as well. The solution presented here uses CredStash, but it could be any other secret storage system as long as you can access the system via a shell script. The important part is that the secrets are acquired at build time and not persisted anywhere on the build server or in the resulting containers.
We want to be able to setup and populate the database at creation, and also to reset the database to its initial state during the development process. The best case scenario is to simply do this during the build process, so no one has to log into the server to do any setup or cleanup. Just kick off a build, which anyone on the team can do.
We want to run MongoDB in authenticated mode because it’s a problem otherwise. Security is a focus for us. There are four things we need to accomplish with the MongoDB database:
- Create an Administrative user
- Create a service account for the web service app
- Populate the collections with initial state
- Allow the database to be set back to initial state
Our build system is based on Jenkins, and we are using Pipelines so our build job configuration is persisted in source control. Our build script defines multiple build types, for the purposes of this article we’ll focus on two of them, Development and Reset, where Development is the default and happens on every git push, and Reset is used to set the database back to this initial state. I’m not going to cover all aspects of the build job, but we are using Docker Compose to create a container for a Node app and a container for MongoDB.
Let’s start with a script to populate the database. We’ll create a JavaScript file with all the base data being inserted something like this, but with many more lines and collections:
db.request.remove({});
db.request.insertOne({
"caseNumber": "1234567890",
"zipCode": "48439",
"requestLeniency": false,
"firstName": "Andy",
"lastName": "Smith",
"issueDate": "04/01/2018"
});
db.request.insertOne({
"caseNumber": "987654320",
"zipCode": "48185",
"requestLeniency": true,
"firstName": "Emily",
"lastName": "Juarez",
"issueDate": "04/07/2018"
});The first line removes any existing documents for the collection so we can use this file to reset the collection later. On first run this line has no effect. This file gets saved as setup.js in the project repository. The Dockerfile for the MongoDB container adds this file into the image so the file is part of the container:
FROM mongo:3.4
ADD setup.js /data/setup.js
In our docker-compose.yml we are mapping the /data/db of the MongoDB container to the file system of the Docker host in order to persist the database data across builds. You could achieve something similar with a data container. In this example the database is called sample and the MongoDB container is called test-db.
The next step is to persist the secrets in CredStash. I create strong passwords then persist them to CredStash using my terminal:
credstash put db-admin StrongPassword
credstash put db-user AnotherStrongPassword
Now create a shell script that creates users and populates the database. First set up the accounts and get their passwords from Credstash:
ADMIN_USER="admin"
ADMIN_PASS="$(credstash get db-admin)"
APP_USER="service"
APP_PASS="$(credstash get db-user)"
Next, assuming it’s a first-time build of the container, create an admin user and a service account:
docker exec test-db mongo admin --eval "db.createUser({user: '${ADMIN_USER}', pwd: '${ADMIN_PASS}', roles:[{role:'root',db:'admin'}]});"
docker exec test-db mongo sample -u $ADMIN_USER -p $ADMIN_PASS --authenticationDatabase admin --eval "db.createUser({user: '${APP_USER}', pwd: '${APP_PASS}', roles:[{role:'dbOwner', db:'sample'}]});"
After creating the users the script creates a file we can look for on later builds in order to skip creating the users again because that won’t work on subsequent builds. Also, the script restarts the application container, because it won’t be able to connect initially since the container is up and running before the database users are set up.
docker exec test-db touch /data/db/.mongodb_password_set
docker restart test-service
The last step is to populate the database with initial state. The JavaScript file is in the container already.
docker exec test-db mongo sample -u $APP_USER -p $APP_PASS --authenticationDatabase courthack /data/setup.jsHere is the entire script (data.sh) including all the checks for different states:
#!/usr/bin/env bash
ADMIN_USER="admin"
ADMIN_PASS="$(credstash get db-admin)"
APP_USER="service"
APP_PASS="$(credstash get db-user)"
FOUND=0
docker exec test-db ls /data/db/.mongodb_password_set || FOUND=$?
echo ""
echo "Previous DB setup file found: ${FOUND}"
echo ""
if [ "$FOUND" -ne "0" ]; then
echo ""
echo 'DATABASE: *** Creating Admin User ***'
echo ""
sleep 1
docker exec test-db mongo admin --eval "db.createUser({user: '${ADMIN_USER}', pwd: '${ADMIN_PASS}', roles:[{role:'root',db:'admin'}]});"
echo ""
echo 'DATABASE: *** Creating App User ***'
echo ""
sleep 2
docker exec test-db mongo sample -u $ADMIN_USER -p $ADMIN_PASS --authenticationDatabase admin --eval "db.createUser({user: '${APP_USER}', pwd: '${APP_PASS}', roles:[{role:'dbOwner', db:'sample'}]});"
docker exec test-db touch /data/db/.mongodb_password_set
sleep 1
docker restart bench-service
fi
if [ "$FOUND" -ne "0" -o "$BUILD_TYPE" = "Reset" ]; then
echo ""
echo 'DATABASE: *** Loading or Restoring Initial Data ***'
echo ""
docker exec test-db mongo sample -u $APP_USER -p $APP_PASS --authenticationDatabase courthack /data/setup.js
fi
echo ""
echo "DATABASE: *** Database Setup Complete ***"
echo ""
In the Jenkinsfile.groovy configuration of the pipeline, one of the steps can simply be to execute the above shell script:
// Lots of stuff omitted for brevity....
static final String BUILD_TYPE_DEV = 'Development'
static final String BUILD_TYPE_RESET = 'Reset'
properties(
[
parameters([choice(choices: [BUILD_TYPE_DEV, BUILD_TYPE_RESET], description: 'Reset restores the database to starting state', name: 'BUILD_TYPE')]),
])
switch (params.BUILD_TYPE) {
case BUILD_TYPE_DEV:
// Do all the dev build stuff (omitted for brevity)
break
case BUILD_TYPE_RESET:
stage('Data Reset') {
setExecutePermissions()
sh './data.sh'
}
break
default:
echo "Unsupported build type!"
currentBuild.result = 'FAILURE'
break
}
void setExecutePermissions() {
echo "Setting Execute Permissons"
script {
sh 'chmod +x data.sh'
}
}
So now the MongoDB database has two users set up and the passwords are not in either the build scripts or in an environment variable. They only existed in memory during build time. And the database ie pre-populated for development, and can be reset any time.
