Welcome!

Enrolling an Application to Conjur

A very common question is: how do I add new secrets and apps to my infrastructure?

At Conjur, we refer to this process of adding new stuff as “enrollment”. The basic flow works in four steps:

Define protected resources, such as Webservices and Variables, using a policy. Call this “Policy A”.

In “Policy A”, create a group which has access to the protected resources.

Define an application, generally consisting of a Layer (group of hosts), in another policy. Call this “Policy B”.

In “Policy A”, add the Layer from “Policy B” to a group which has access to the protected resources.
Step (4) has a special name, “entitlement”, because in this step existing objects are linked together, and no new objects are created. An entitlement is always one of the following:

Grant a policy Group to a Layer.

Grant a policy Group to a different Group (usually a group of Users).
Organizing policy management into three categories - protected resources, applications, and entitlements - helps to keep the workflow organized and clear. It also satisfies the essential security requirements of separation of duties and least privilege.

Separation of duties Management of protected resources is separated from management of client applications. Different teams can be responsible for each of these tasks. In addition, policy management can also be delegated to machine roles if desired.

Least privilege The client applications are granted exactly the privileges that they need to perform their work. And policy managers (whether humans or machines) have management privileges only on the objects that rightfully belong under their control.

Setup

We will model a simple application in which a frontend service connects to a db server. The db policy defines a password, which the frontend application uses to log in to the database.

Here is a skeleton policy for this scenario, which simply defines two empty policies: db and frontend. Save this policy as “conjur.yml”:

- !policy
id: db
- !policy
id: frontend

Then load it using the following command:

conjur policy load --replace root conjur.yml

Loaded policy 'root'
{
"created_roles": {
},
"version": 1
}

Use the conjur list command to view all the objects in the system:

conjur list

[
"myorg:policy:root",
"myorg:policy:db",
"myorg:policy:frontend"
]

Define Protected Resources

Having defined the policy framework, we can load the specific data for the database.

Create the following file as “db.yml”:

Declare the secrets which are used to access the database

- &variables
- !variable password

Define a group which will be able to fetch the secrets

- !group secrets-users

"read" privilege allows the client to read metadata.
"execute" privilege allows the client to read the secret data.
These are normally granted together, but they are distinct just like read and execute bits on a filesystem.

Define an Application

Note Statically defining the hosts in a policy is appropriate for fairly static infrastructure. More dynamic systems such as auto-scaling groups and containerized deployments can be managed with Conjur as well. The details of these topics are covered elsewhere.
Now load the frontend policy using the following command:

Note The api_key printed above is a unique securely random string for each host. When you load the policy, you'll see a different API key. Be sure and use this API key in the examples below, instead of the value shown in this tutorial.

Entitlement

With the preceding steps completed, we now have the following objects and permissions in place:

variable:db/password is created and populated with a value.

group:db/secrets-users can “read” and “execute” the database password.

layer:frontend is created, and host:frontend/frontend-01 exists and belongs to the layer. We have an API key for it, so we can authenticate as this host.

When a frontend application is deployed to host:frontend/frontend-01, it can authenticate with the api_key printed above and attempt to fetch the db password. You can simulate this using the following CLI command:

Debugging Scenarios

Help

Katacoda offerings an Interactive Learning Environment for Developers. This course uses a command line and a pre-configured sandboxed environment for you to use. Below are useful commands when working with the environment.

cd <directory>

Change directory

ls

List directory

echo 'contents' > <file>

Write contents to a file

cat <file>

Output contents of file

Vim

In the case of certain exercises you will be required to edit files or text. The best approach is with Vim. Vim has two different modes, one for entering commands (Command Mode) and the other for entering text (Insert Mode). You need to switch between these two modes based on what you want to do. The basic commands are: