October 2013 Archives

Secrets, Security and Environment Configuration

True story.

Once upon a time there was a web application stack built atop of a particular CI (continue integration) pattern with particular security constraints which I had the pleasure of configuring. The application needed certain secrets (third-party API keys, passwords, trade-secrets, etc) in order to run properly but that data needed to be very well guarded (and definitely not shipped with the codebase). The following is how I tackled the assignment, I think it works well but I could be mistaken. Please feel free to comment with any questions, suggestions, or other feedback.

First, I decide to put all configuration information in environment-based YAML files except for the sensitive info. I decided to store sensitive data in shell environment variables in-memory having and referencing them in the codebase where needed. This particular application uses Puppet for CM (configuration management), the provisioning and continuous deployment process is similar to the following...

A fresh server is booted-up using an image which executes a bootstrapping script which installs a few essentials and prompts for some user input. One of the expected inputs is a password which is used to access the contents of a password-protected 7zip archive which gets downloaded from a private file hosting server. The 7zip archive contains a GPG (GNU Privacy Guard) public and private keyring which is used to decrypt the environment config file which gets downloaded from a private GitHub repository which only hosts the various app configurations. The bash-based environment configuration file is then sourced in-place (e.g. eval gpg -d /tmp/envfile) having the commands within the file executed and certain secrets exposed as environment variables. Certain bits are also copied to disk in-case of failure and reboot (each location is secured).

Having the secrets exposed and a process and workflow which seems to be somewhat secure, I just needed a better way of getting at the complex environment variable names which held the sensitive data. So I decided to write Config::Environment, a module which give you access to app-specific environment variables (with some additional goodies as well).


HttpD On-Demand

Every so often I have a need to debug static web content which is usually within a random directory on my development system. I've created an alias in Linux which uses Python to start an HTTP daemon which serves static HTML content from the CWD (current working directory).

This alias uses Python and a core library to start an http daemon with directory browsing enabled. Very handy.

alias httpd='python -m SimpleHTTPServer'

Being a Perlist, I figured there is probably a way to do this in Perl, but after a few searches and lame attempts at it myself, I haven't been able to figure it out.

The closest I've gotten, after more research than this is worth, was starting the Mojolicious daemon and setting the MOJO_HOME envvar, which doesn't work.

MOJO_HOME=$(pwd) mojo daemon

Having bounced around various web frameworks and documentation, I've finally landed on Plack::App::Directory which does exactly what I'm after, with a little arm twisting.

plackup -MPlack::App::Directory -e 'Plack::App::Directory->new->to_app'

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!