BLOG POST

Secure Developer Access to Hosted Services via Conjur and Pow

 

April 27, 2015 | DevOps | Kevin Gilpin

 

Conjur’s HTTP service authorization capability, aka Software Defined Firewall (SDF), is a high performance and highly available way to protect services and micro-services against unauthorized access. The SDF consists of two parts: the forwarder, and the gatekeeper. The forwarder runs on the client end of the transaction. All outbound traffic from the client is sent through the forwarder, which:

  • Authenticates the client with Conjur, obtaining a Conjur auth token

  • Puts the auth token on the outbound request, in the HTTP Authorization header

The gatekeeper runs on the server side. It’s a lightweight reverse proxy which intercepts each inbound request, verifies authenticity of the auth token, and verifies the client’s access privilege using the Conjur web service.

The gatekeeper is installed on the server-side in accordance with the server-side hosting architecture. For example, for Heroku apps, the gatekeeper is installed as a custom buildpack. In Docker clusters, the gatekeeper is a Docker container which is outward-facing, and has a Docker “link” to the protected service.

In server-to-server scenarios, the forwarder can also run embedded in the server stack (e.g. Docker cluster). A key aspect of all Conjur technology is our emphasis on consistent workflows through development/stage/production, and uniform access controls for people, machines and code. Therefore, it’s important for developers to have an easy way to run a local forwarder and thereby access SDF-protected services.

After brainstorming and experimenting with some different approaches, we’ve discovered pow.cx, “a zero-config Rack server for Mac OS X”. It’s a self-contained web server that automatically launches Rack-based applications, and assigns them locally resolvable DNS names like “myapp.dev”.

Let’s take a look at the entire workflow: setting up Pow, using it to run a Conjur forwarder, and invoking a protected web service using cURL.

The Conjur ReleaseBot is a good example of a protected web service. It’s a Sinatra app which runs in Heroku and performs Conjur code pushes to RubyGems, NPM, and Heroku. It has a simple REST interface:

  • POST /npm/releases release to NPM
  • POST /rubygems/releases release to RubyGems
  • DELETE /rubygems/releases/:name yank a Ruby gem
  • POST /heroku/releases push a Heroku app

To access this protected web service from a developer machine (on MacOS), the first step is to install Pow:

$ curl get.pow.cx | sh
Next, create a Rack application which runs a forwarder. Conjur provides a forwarder implementation called conjur-asset-proxy which runs as a plugin to the Conjur CLI.
A simple Gemfile installs the dependency libraries:
source "https://rubygems.org"

gem 'conjur-cli'
gem 'conjur-asset-proxy'
A config.ru (aka “rackup”) defines the Rack application, which builds a Conjur proxy to the remote service:
proxy = Conjur::Proxy.new("https://releasebot-conjur.herokuapp.com", api)
proxy.configure
run proxy
(This is just a snippet, you can view a full example here).
Rack applications are mounted into Pow via symlinks. Pow picks these up automatically and deploys them as Rack applications. Navigate to the ~/.pow directory and create a symlink to the Rack application:
$ cd ~/.pow
$ ln -s ~/source/sdf-forwarders/releasebot .
Pow logs are easy to find and read in the MacOS Console:
pow-console-log
When everything’s up and all looks well in the log, accessing the service is a simple matter of a cURL command (or for web apps, opening the http://appname.dev in your browser).

So, how is ReleaseBot used to publish a new Ruby gem version of the Conjur CLI? First, here’s what it looks like without any authorization:

$ curl -i -X POST https://releasebot-conjur.herokuapp.com/rubygems/releases 
  --data "name=conjur-cl"

HTTP/1.1 401 Unauthorized
Server: Cowboy
Date: Fri, 24 Apr 2015 19:56:03 GMT
Connection: keep-alive
Content-Type: text/html;charset=utf-8
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Via: 1.1 vegur

By changing the base URL to http://releasebot.dev, which is running automatically under Pow, we can successfully perform the Gem release without having to worry about authorization:

$ curl -X POST releasebot.dev/rubygems/releases --data "name=conjur-cli"
Gem version 4.21.1 released
This is just as convenient as using completely insecure services! That’s the workflow everyone is looking for, without the risk. This is security at speed, via Conjur.

 

 

Share This