High level overview of patterns to use when building policies across departments

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

We have a team working to build a new micro-service called Billing. Our new billing service requires a database (we'll use Postgres), and connects to Stripe to allow a customer to pay their bill. The team is just getting started with the development effort. In order to release the Billing service, they'll need a database and access to the company's Stripe credentials.

Teams Involved

Database Team - The database team is responsible for provisioning and managing databases for all the engineering teams in the organization. When a team needs a new database, the database team rolls out the database and provides the requesting team credentials to connect.

From a security perspective, the database team wants passwords to be rotated daily. Daily rotation insures that even if a credential is leaked, the window the credential will remain valid is small.

Billing Engineering Team - The billing engineering team is responsible for building and running the service. The engineering team wants to move quickly. Key members of team may occasionally need access to the database to troubleshoot issues.

Finance - The finance team is responsible for all financial elements of the organization. This includes access to the company's Stripe account. It's hard to rotate the Stripe account, so the finance team wants to make sure the credentials do not get leaked.

Policy Structure

Let's start by constructing policies around the different protected resources (database, Stripe credentials), focusing only on the resources a particular team would be responsible for.

Database Policy

This policy is created by the database team. It will hold all the information an application or user would need to connect the created database.

- !policy
  id: billing-database
  owner: !group database-administrators
  body:
  - &variables
    - !variable username
    - !variable password
    - !variable url
    - !variable port

  - !group secrets-users
  - !group secrets-managers

  # secrets-managers has role secrets-users
  - !grant
    member: !group secrets-managers
    role: !group secrets-users

  # secrets-users can read and execute
  - !permit
    resource: *variables
    privileges: [ read, execute ]
    role: !group secrets-users

  # secrets-managers can update (and read and execute, via role grant)
  - !permit
    resource: *variables
    privileges: [ update ]
    role: !group secrets-managers

Strip Credenitals Policy

This policy holds the credentials used when connecting to the Stripe service.

- !policy
  id: stripe-api_credentials
  owner: !group finance-administrators
  body:
  - &variables
    - !variable key
    - !variable secret
    - !variable url

  - !group secrets-users
  - !group secrets-managers

  # secrets-managers has role secrets-users
  - !grant
    member: !group secrets-managers
    role: !group secrets-users

  # secrets-users can read and execute
  - !permit
    resource: *variables
    privileges: [ read, execute ]
    role: !group secrets-users

  # secrets-managers can update (and read and execute, via role grant)
  - !permit
    resource: *variables
    privileges: [ update ]
    role: !group secrets-managers

Application Policy

This policy includes the application servers that will run the Billing application. These servers will need access to the database and Strip credentials.

- !policy
  id: application-billing
  body:
  - !layer hosts

  - !host-factory
    layer: [ !layer ]

Billing Engineering Team Policy

This policy includes the people on the billing engineering team.

- !group billing-team

- !user sophie.madelon
- !user marcel.calisto
- !user ernest.alvin

- !grant
  role: !group billing-team
  members:
    - !user marcel.calistoÂ
    - !user ernest.alvin
    - !user sophie.madelon

Enabling Permission

After these policies have been loaded into Conjur and the variable values have been set, we can get down to the real business of security. Let's create a final policy which will wire these policies together:

# Allow the application servers to access the database credentials
- !grant
  member: !layer application/billing/hosts
  role: !group billing-database/secrets-users

# Allow the application servers to access the Stripe credentials
- !grant
  member: !layer application/billing/hosts
  role: !group stripe-api_credentials/secrets-users

Now the Billing micro-service can connect to the database and Stripe as required. The database credentials can be rotated (with Conjur) without needing to redeploy code changes to the Billing applications. Each team in the organization can work independently of the other. Thoughtful policy design empowers and enables teams while protecting resources.