Conjur: policy driven secrets management where machines hold the credentials

A secrets system built for hosts, not for people

Conjur provides secrets management and application identity for modern infrastructure, and the two halves of that sentence matter. Most people meet secrets management as a way to stop storing database passwords in configuration files. Conjur's framing starts from the machine side, where the consumer of a credential is a service, a job or a container, and where the interesting question is not who typed a password but what the running process is allowed to fetch.

The repository description puts it plainly: Conjur automatically secures secrets used by privileged users and machine identities. The README lists three capabilities. The Machine Authorization Markup Language, called MAML, is a role-based access policy language used to define system components and their roles, privileges and metadata. A REST web service manages identity life cycles for humans and machines, organises and searches roles and data in the secrets infrastructure, authorises access to resources using a sophisticated permission model, and stores secrets and makes them available securely. And there are integrations across the cloud toolchain, covering infrastructure as a service, configuration management, continuous integration and deployment, and container management and cloud orchestration.

That combination is the reason Conjur looks different from a generic password manager. A policy written in MAML describes the system itself, the hosts and the services and what each is allowed to reach, and the same policy drives both what a secret is called and who may read it.

The implementation language is Ruby, the project is hosted at conjur.org, and it carries a CI workflow badge, a maintainability badge and a test coverage badge, plus Docker Hub pull badges for the published image.

MAML and the REST service are two halves of one system

MAML is the part that makes Conjur more than a key vault, so it is worth separating the two ideas the README puts together.

The policy language is role-based. Roles describe system components and carry privileges and metadata, and access decisions are made against those roles rather than against individual credentials. The web service is the machinery that acts on the policy: it manages identity life cycles for humans and machines, and it authorises access to resources using a permission model the README calls sophisticated, with roles and data that can be searched across the secrets infrastructure.

The result is that a machine does not hold a long lived secret. It authenticates, receives a signed token, and presents that token when it asks for the value it is entitled to. The README makes the cryptographic side explicit. The `authenticate` function issues a signed JSON token, and the signing key is a 2048 bit RSA key stored encrypted in the database. Each account also has its own token-signing private key, and when a role is authenticated the HMAC of the access token is computed using the signing key of that role's account.

Because the policy is data rather than code, the interesting operational question becomes who can change the policy. The README addresses that directly, listing the ability to secure access to authenticators using policy files as one of the things Conjur makes easy, alongside enabling and disabling built-in authenticators and creating custom ones.

Docker and PostgreSQL are the deployment shape

The architecture section is short and specific. Conjur is designed to run in Docker containers, using PostgreSQL as the backing data store, and it is easy to run both Conjur and PostgreSQL in Docker, with the demo directory holding an example. The README notes that Conjur is compatible with PostgreSQL 15.

The database connection is a single environment variable. Conjur uses `DATABASE_URL` to connect, with two typical options given: a local linked `pg` container, or an external managed database such as AWS RDS. Schema management is automatic. Conjur creates and updates the database schema when it starts up, and the migration scripts live in the db/migrate directory.

The root of the repository is a Ruby application with the usual furniture. There is a Gemfile and Gemfile.lock, a Rakefile, config.ru, a Procfile, cucumber feature files, a Dockerfile plus Dockerfile.source, Dockerfile.test and Dockerfile.ubi variants, a Jenkinsfile for CI, and directories for app/, engines/, db/, design/, contrib/, distrib/ and docs/. The docker-compose.yml in the root builds an API documentation service and maps it on port 3000:

services:
  apidocs:
    build:
      context: ./apidocs
      dockerfile: Dockerfile.apidocs
    image: conjur-apidocs
    ports:
      - 3000:3000
    volumes:
      - ./apidocs/src:/home/node/src

The image itself is a two stage build that installs gems in a builder layer and copies them into a FIPS enabled Ubuntu runtime, and the container entry point is `conjurctl`.

The data key is the single point of failure

There is one operational requirement that deserves more attention than any other line in the README, and it is the requirement to generate a master data key before you start the server.

When you start Conjur you must provide a Base64-encoded master data key in the environment variable `CONJUR_DATA_KEY`. The README gives the command that generates one:

$ docker run --rm conjur data-key generate

And then it says, without softening it, do NOT lose the data key, or all the encrypted data will be unrecoverable.

That is the failure mode to plan for. Conjur encrypts data in and out of the database using Slosilo, the library that provides symmetric encryption with AES-256-GCM, a Ruby class mixin for encrypting object attributes into the database, asymmetric encryption and signing, and a keystore in a PostgreSQL database for storing and retrieving keys. Because the encryption is anchored on a key you hold outside the database, the key is the root of trust for every secret and every role API key inside it. Lose it and the ciphertext is noise.

The flip side is that this design also means the key is what an attacker wants. A backup of the database plus a copy of CONJUR_DATA_KEY is a complete compromise of the contents, so the key belongs in a secret store of its own, with the same care you would give the master key of a certificate authority. The README does not prescribe where to keep it, which means that decision is yours to make and document.

Rotators, authenticators and multi-tenant accounts

Three subsystems sit alongside the policy engine, and each has its own design document in the repository.

Authenticators are how a subject proves who it is. The README says Conjur makes it easy to enable and disable built-in authenticators, to secure access to authenticators using policy files, and to create custom authenticators. The design documentation is at design/authenticators/AUTHENTICATORS.md, and there is a separate CERTIFICATE_AUTH.md at the root for certificate based authentication.

Rotators are how a secret changes. Conjur makes it easy to rotate variables regularly using built-in rotators and to create custom rotators, with the design documentation at design/ROTATORS.md. Rotation is where secrets management earns its keep, because a credential that never changes is a credential that eventually leaks.

Account management is the third. Conjur supports the simultaneous operation of multiple separate accounts within the same database, in other words it is multi-tenant. Each account, also called an organization account, has its own token-signing private key, and the HMAC of the access token is computed with the signing key of the role's account. The practical consequence is that two organisations can share one Conjur installation and one PostgreSQL database without sharing token trust, and accounts can be listed, created and deleted through the API.

The repository also carries a TELEMETRY.md file and NOTICES.txt alongside the LICENSE, which is worth reading before an evaluation since it tells you what the project itself records about usage and what third party notices apply.

Version pinning to the suite release is the upgrade rule

The compatibility section contains the single most important operational instruction in the README, and it is repeated with emphasis: the maintainers strongly recommend choosing the version of the project to use from the latest Conjur Open Source suite release, because the maintainers perform additional testing on the suite release versions to ensure compatibility. When possible you should upgrade your Conjur version to match the latest suite release, and when using integrations you should choose the latest suite release that matches your Conjur version.

That is an unusual instruction for an open source project, and it reflects how the pieces fit together. Conjur server, the integrations that fetch secrets into infrastructure as code, configuration management or CI/CD pipelines, and the client side helpers are versioned against each other, and the suite release is the combination the maintainers have actually tested. Running a newer server against older integrations is exactly the case the guidance is designed to prevent.

When you are upgrading a Conjur server running in a Docker Compose environment to the latest suite release version, the README points you at the upgrade instructions in UPGRADING.md, and directs questions to the CyberArk Commons Discourse forum. The same section points at a migration guide for moving data from Conjur Open Source to CyberArk Secrets Manager, Self-Hosted, which is the commercial successor product.

The version history in the repository reflects a steady line of releases, with v1.27.0 on 2026-06-16, v1.24.0 on 2025-11-20 and v1.22.3 on 2025-09-24. The last push was on 2026-07-14, the default branch is master, and the project is not archived.

Where Conjur stops, and what to weigh against it

The boundary is worth stating plainly, because the README is enthusiastic and the fit is narrow.

Conjur is an application identity and secrets platform built around a policy language. If your problem is a human who needs to log into something and you want a vault with a user interface, a dedicated secrets manager is the better fit, and Conjur will ask you to model humans as roles with policies before it gives you a password.

There is also a real operational cost. The server is a Rails application with a PostgreSQL database, a master data key that is unrecoverable if lost, a policy language your team has to learn, and a set of integrations that must be version matched to the server. That is a system to run, not a library to import.

The usual approach treats secrets as values to be copied into configuration files and pipelines. The policy approach treats secrets as something a host proves it may have. If you already have a working inventory, rotation and audit process, Conjur adds a control plane rather than removing a problem. If you do not, it gives you one, at the cost of the deployment described above.

Editorial conclusion

Adopt Conjur when your problem is a machine identity that needs a credential delivered without anyone reading it, and when you can commit to pinning the suite release and protecting the master data key. Do not adopt it as a general purpose vault for humans with a rotating password problem. Before deploying, read the Quick Start Guide, generate CONJUR_DATA_KEY and store it somewhere safe, check that PostgreSQL 15 is what you have, and note that the licence is a custom one in LICENSE.md while the last push was on 2026-07-14 with v1.27.0 released on 2026-06-16.

Frequently asked questions

Official sources

1. cyberark/conjur on GitHub
2. Issues
3. Project website
4. README
5. Releases