jvanderhoof

Starting Configuration:

server-1
  domain: conjur-master-1.mycompany.com
  container: Conjur v5.2.2
  configured as: Master

server-2
  domain: conjur-master-2.mycompany.com
  container: Conjur v5.2.2

jvanderhoof

- !policy 
  id: conjur/authn-openid_connect/okta
  body:
    - !webservice
        annotations:
          credential/client-id: ops/okta/client-id
          credential/client-secret: ops/okta/client-secret
          credential/organization: ops/okta/org
          credential/url: ops/okta/url

jvanderhoof

#!/bin/bash -e

function authentication_token {
  api_key="$(curl -k --user admin:secret https://localhost/authn/cucumber/login)"
  raw_token="$(curl -k -X POST -d "$api_key" https://localhost/authn/cucumber/admin/authenticate)"
  token=$(echo -n $raw_token | base64 | tr -d '\r\n')
  echo "$token"
}

auth_token=$(authentication_token)

jvanderhoof

Patterns for Scalable Policy

For security policies to be effective, those policies need to be considerate of the people, teams, and existing workflows. Security policy without consideration is destined to be ignored or circumvented. When designing Conjur policies, we need to be considerate of an organization's existing structure, communication, and workflow. A few simple guidelines will get an organization a long way.

What is a Credential?

Let's start by understanding what credentials really are. Credentials are the keys that enable their holder to access a restricted resource. When we talk about credential management, we're actually talking about restricting access to the resources those credentials enable.

Let's look at an example to help illustrate how we can accomplish this goal.

Building a Billing Microservice

jvanderhoof

{
	"description": "Default Docker seccomp profile, plus keyctl calls (required by Conjur)",
	"comment": "Run with `docker run --security seccomp:path/to/seccomp.json` to use it.",
	"defaultAction": "SCMP_ACT_ERRNO",
	"architectures": [
		"SCMP_ARCH_X86_64",
		"SCMP_ARCH_X86",
		"SCMP_ARCH_X32"
	],
	"syscalls": [{

jvanderhoof

Ansible connects to remote machines using SSH. This leads to a challenge running Ansible at scale: How do we manage the private SSH keys Ansible uses to connect to the remote machines it manages? We can keep those keys on the Ansible Controller, but this makes them difficult to rotate, and makes the Controller a high value target in the network for attackers. Let's look at a better option: moving those SSH keys into a vault, and retrieve those keys only when they are needed for an Ansible playbook run.

Setting the Stage

Everyone's environment is going to look a bit different. Let's start by defining some context for our example environment: We have two applications: Foo and Bar, and two different environments: staging and production. Each application has a load balancer to manage traffic. In our production environment, applications Foo and Bar each have five application servers running behind the load balancer. In staging, each application has a single node. Each node for a given application and envir

jvanderhoof

# config_management/ansible.yml
- !policy
  id: ansible
  body: 
  - !layer

  - !host-factory
    layer: [ !layer ]

jvanderhoof

#!/usr/bin/env groovy

pipeline {
  agent { label 'executor-v2' }

  options {
    timestamps()
    buildDiscarder(logRotator(numToKeepStr: '30'))
  }

jvanderhoof

#!/bin/bash -e

docker pull registry.tld/conjurinc/publish-rubygem

summon --yaml "RUBYGEMS_API_KEY: !var rubygems/api-key" \
  docker run \
    --rm \
    --env-file @SUMMONENVFILE \
    -v "$(pwd)":/opt/src \
  registry.tld/conjurinc/publish-rubygem conjur-api

jvanderhoof

version: '2.1'
services:
  pg:
    image: postgres:9.3

  conjur:
    image: cyberark/conjur
    command: server -a cucumber
    environment:
      DATABASE_URL: postgres://postgres@pg/postgres