Security policy as code

Policy defines and organizes objects in your Conjur database. Policy also establishes the rules for role-based access on resources.


Policy defines security rules. It is written using YAML, a language that is human and machine readable. Policy is loaded directly into Conjur.

Policy defines the following types of infrastructure :

  • Human users who can access Conjur through the CLI, or the API. Policy defines the users, organizes them, and defines privileges.

  • Applications that can authenticate to Conjur programmatically and access data. Policy defines the applications (hosts), organizes them, and defines permissions on protected data, including secrets.

  • Variables that represent the secrets that will be stored in Conjur. Policy defines and manages the variables, and defines who can access the values. Note that policy does not hold the values (the actual secrets.)

  • Web services can provide services to Conjur. Policy defines the services and makes them accessible.

Policy files

You define policy in files that can be checked into source control. We recommend establishing a process and review around changing policy files just like other controlled files.

After saving policy in text files with .yml extensions, you load the file into Conjur using the Client CLI or REST API. Conjur interprets and transforms your policy statements into definitive database records. You can safely re-apply policy any number of times.

A policy file is declarative, meaning that the rules become data in the database; it is not an executable code. Therefore, loading a policy file does not have any effect other than to create and update the role-based access control model in your Conjur appliance. These properties make policy files automation-friendly.


Policy files do not contain secret or password values. They contain only the declaration of the variable that will store the values and rules defining which roles can access the values.