Applications in Conjur

Overview

Conjur enables you to define users and groups and grant them privileges on resources in your environment. Authenticating and authorizing non-human actors is the other part of the puzzle. We refer to any non-human actor in your environment as an application. For example, an application can be, but is not limited to, a server in a datacenter, VM in the cloud or a container. Identifying and authorizing applications is important because we delegate authority to them in automated workflows.

An identity of the application is part of Conjur's authentication ("authn") system, allowing the application to prove to the Conjur Server that it is authorized ("authz") to access secrets and execute resources as defined in a policy. An application's identity is also used when the application is the target of an action, for example SSH access or traffic authorization.

When a VM first starts, it runs a configuration management tool to apply configuration. Some of the configuration to be applied is placing credentials (database passwords, SSL certificates, etc).

Assigning application identity allows you to grant the VM access to fetch the credentials it needs via security policy. Credential access is recorded to an immutable audit log. Changing or revoking access to credentials does not require further system configuration.

Applying application identity

There are different methods to apply application identity. Depending on your use cases and environment you may use one or more.

Method	Use Case
Policy	Static applications
Host Factory	Auto-configured applications deployed by orchestration tools
Integrations	Auto-configured applications deployed by third-party orchestration tools and integrated as `hosts` into Conjur.

Storing and securing application identity

An application identity exists as a collection of information which can be stored in files or environment variables.

This information includes a unique identifier, a secret key, and configuration information.

Storage using files

File Decription

/etc/conjur.identity

Contains identifier and secret key

Type: netrc

Security Concerns: Only accessible by root

Example:

machine conjur/authn
  login admin
  password 2hmr05c3ny0vfj10qbkyj386g9rg9zcrwy3d6n9wy1ej70xh1btr5m8

/etc/conjur.conf

Contains configuration

Type: yaml

Security Concerns: Only writable by root

Example:

---
account: myConjurAccount
plugins: []
appliance_url: https://<Conjur-DNS>

/etc/conjur.pem

Contains information from the Conjur Server

Type: certificate

Security Concerns: Only writable by root

/etc/conjur.identity contains the application's API key and should be kept secret. A good practice is to symlink this file from /dev/shm.

The remaining files contain no confidential information and can be shared freely.

Storage using environment variables

Application identity can also be applied through the environment.

This is useful for tooling that accepts configuration through the environment (Docker containers, CI jobs, Heroku apps, etc).

Variable	Description	Example
`CONJUR_ACCOUNT`	Account specified during Conjur setup	myorg
`CONJUR_APPLIANCE_URL`	Conjur HTTPS endpoint	https://conjur.myorg.com
`CONJUR_AUTHN_API_KEY`	Application (`host`) API key	sb0ncv1yj9c4w2e9pb1a2s
`CONJUR_AUTHN_LOGIN`	Application (`host`) identity	host/production/redis001
`CONJUR_AUTHN_TOKEN`	Conjur JSON access token, Base64 encoded	eyJkYXRhIjNTdjOWJkNWQ1ZDgyYTU0In0
`CONJUR_POLICY_ID`	Policy namespace (for variables)	redis-v1
`CONJUR_SSL_CERTIFICATE`	Public Conjur SSL certificate	-----BEGIN CERTIFICATE-----