Delivering Conjur with Vagrant


July 15, 2015 | DevOps | Hleb Rubanau


The team at Conjur helps our customers deploy their application into many different environments: cloud providers like AWS and Joyent, internal VM clusters, bare-metal setups, and local VMs for evaluation. When we get down to it, though, these different configurations can all be setup as wrappers around around a fundamental Conjur LXC container. To package that up for all of these different setups we use Vagrant. The Vagrant plugin ecosystem makes it easy to swap in, and deploy to, different providers.

One Vagrantfile to rule them all

This method of standing up Conjur assumes you have Vagrant and some plugins (such as vagrant-berkshelf) installed. As soon as these prerequisites are met, it takes only three steps to get new Conjur server up and running:

  1. Clone the public Git repo
  2. Obtain from Conjur a non-public download URL for the Conjur LXC image, and export it  as environment variable INSTALLER_URL
  3. vagrant up with provider of your choice (so far we’ve tested only Virtualbox and AWS, but other platforms should work with only minor modifications using Ubuntu 12 LTS or Ubuntu 14 LTS as the base OS)

In about 10 minutes, Conjur will be set up and running inside this Vagrant-managed server (either virtual or cloud), and is ready to accept traffic after a pretty simple configuration.

Deployment architecture

Inside the server, Conjur runs as an LXC container named “conjur-appliance”:


For your convenience, the Conjur CLI and Docker are also installed on server, so it’s immediately possible to use the CLI for learning and experimenting with Conjur. For example, all the Conjur Demos will happily run in this server environment.

This configuration unlocks many interesting options for experimenting with Conjur:

  1. Snapshotting and hard-reset of Conjur appliance is extremely easy, because LXC containers can be backed up and restored with lxc-clone utility.
  2. It’s possible to make a snapshot of an appliance and copy it to other server(s) as just a tarball.
  3. The server can become a test lab for HA setups, with all components deployed on the same host.
  4. Appliance upgrade can potentially be done within same server, just by deploying new version of an LXC container, and performing a zero-downtime migration.

Turn it on

The Conjur server set up by vagrant is ‘blank’, which means it needs to be configured before it will operate.

To set up the simplest (“standalone”) version of Conjur, three parameters need to be defined:

  1. password — admin password
  2. hostname — the DNS name used by external applications to connect to Conjur
  3. account — organisational account (typically the name of a company), which is a constant serving as a prefix for all Conjur IDs

Configuration is performed by the evoke command-line utility which is built in to the Conjur container. To launch it run vagrant ssh and then lxc-attach to the Conjur container.

BE SURE AND SET hostname, password, and account VARIABLES IN YOUR SHELL ON THE SERVER!

# login to server
workstation$ vagrant ssh
# configure appliance
server$ sudo lxc-attach -n conjur-appliance -- evoke configure standalone -h $hostname -p $password $account
# check the appliance availability
server$ curl -k https://conjur/api/info
# configure local client to use the appliance
server$ conjur init -h conjur

Now, you’re all set. Conjur logs are stored under /var/lib/lxc/conjur-appliance/rootfs/var/log/conjur

Let the traffic flow

As seen from commands above, within the server, Conjur is available at short DNS names “conjur” and “conjur-appliance”, which point to the internal IP But how could this container be exposed to outer world?

It already is. Within the server, networking is set up so that all inbound traffic on ports 443 (ssl), 636 (ldaps) and 5432 (postgres, for replication purposes) is routed to the internal IP of Conjur LXC container.

All you have to do is to let clients find the server by appropriate configuration of your network (DNS, and in some cases, routing). DNS name is supposed to be the same as $hostname parameter provided during configuration.


Now, Vagrant-based deployment can work equally well for local Virtualbox labs and production-level AWS setups. No specific knowledge of Vagrant and LXC is needed to get Conjur just up and running.

However, if you feel brave enough to get to some familiarity with LXC, it will definitely pay back. It’s not the goal of this post to describe all possible configurations and use cases, but the ability to run many Conjurs in the same virtual server opens a lot of opportunities for nice and elegant engineering solutions, both for experimental and production purposes.

Here are two blog posts we wrote about LXC that you might find useful:

Please, do not hesitate to share your experience with us. We’re always happy to hear from you  at [email protected].





Keep up-to-date on security best practices, events and webinars.

Share This