In part 1 I explained how to run HuBot inside a Docker container. Part 2 was about setting up a continuous deployment pipeline. This part shows you how you could handle your secrets like API Keys, usernames and passwords.
Hide your secrets
HuBot uses environment variables to configure scripts. For example the variable
HUBOT_SLACK_TOKEN is used to store the API Key of the Slack adapter. With ECS you can have the variables inside the docker file or as part of the task-definition file. But storing such sensitive data inside a repository is not a good idea. Even if its a private repository it can be viewed by more people than necessary.
Security by obscurity (Edited) The principle of least privilege is also in this case the preferable way.d
An advice you often hear is to keep secrets in a s3 bucket and define a restrictive policy to access it. But how do I get it inside my container? I got another helpful idea from Michael Wittig. He suggested to store all my secrets in an
env.sh file like this and put it manually on s3.
export HUBOT_SLACK_TOKEN=xxx export HUBOT_AUTH_ADMIN=xxx export HUBOT_SLACK_ADMIN=xxx export HUBOT_GITHUB_KEY=xxx export HUBOT_GOCD_USERNAME=xxx export HUBOT_GOCD_PASSWORD=xxx
Inside my dockerfile I should load that file and execute it immediately just before I launch my application.
CMD ["/bin/sh", "-c", "aws s3 cp --region eu-west-1 s3://your-bucket/env.sh .; . ./env.sh; bin/hubot --adapter slack"]
This command starts a shell and downloads the
env.sh file from my secured s3 bucket. Next it executes that file so that the environment variables are set and finally starts HuBot.
That’s it. With this little trick I can keep my secrets in my secured s3 bucket and I don’t have to commit them to my repository. You can find all the sources on my GitHub repo.
Subscribe via RSS