Skip to content

Instantly share code, notes, and snippets.

View full-sized avatar

Jason Vanderhoof jvanderhoof

View GitHub Profile
@jvanderhoof
jvanderhoof / conjur-upgrade.md
Last active December 14, 2018 22:03
Conjur Upgrade
View conjur-upgrade.md

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
jvanderhoof / authn-openid_connect-policy.yml
Created August 20, 2018 20:42
Sample Okta OpenID Connect
View authn-openid_connect-policy.yml
- !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
jvanderhoof / conjur-set-and-pull-variable.sh
Created June 25, 2018 13:43
Example authenticating with Conjur, setting, and retrieving a variable.
View conjur-set-and-pull-variable.sh
#!/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
jvanderhoof / conjur-policy-patterns.md
Last active May 23, 2018 22:22
High level overview of patterns to use when building policies across departments
View conjur-policy-patterns.md

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
jvanderhoof / sample_comjur_seccomp_profile.json
Created May 14, 2018 17:17
Sample Conjur seccomp profile (default profile with `keyctl` enabled, which provides access to underlying kernel keychain)
View sample_comjur_seccomp_profile.json
{
"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
jvanderhoof / conjur_ansible_ssh_keys.md
Created March 12, 2018 12:58
Overview of how to secure SSH keys for use by Ansible
View conjur_ansible_ssh_keys.md

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
jvanderhoof / ansible_sample_policy.yml
Created February 21, 2018 19:08
Example Conjur Policy files using the Conjur Ansible plugin
View ansible_sample_policy.yml
# config_management/ansible.yml
- !policy
id: ansible
body:
- !layer
- !host-factory
layer: [ !layer ]
View jenkins-example-jenkinsfile
#!/usr/bin/env groovy
pipeline {
agent { label 'executor-v2' }
options {
timestamps()
buildDiscarder(logRotator(numToKeepStr: '30'))
}
View jenkins-example-publish.sh
#!/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
View jenkins-example-docker-compose.yml
version: '2.1'
services:
pg:
image: postgres:9.3
conjur:
image: cyberark/conjur
command: server -a cucumber
environment:
DATABASE_URL: postgres://postgres@pg/postgres