
Making and keeping your fleet of Postgres databases secure can be a daunting task. Also a task that takes a lot of effort.
The pg_secured puppet module is an affordable supported Puppet module that allows you to ensure a security benchmark, like the CIS benchmark or the DoD STIG, to your databases. It integrates seamlessly with Puppet and Puppet Enterprise. The module supports extensive customizations and allows you to work with exclusion lists when you don’t want all of the security controls applied. It also allows you to define your own sub-set of security controls or even your own security controls.
Contact us for pricing information and see how you can reduce the TCO of your fleet of Postgres databases.
The pg_secured
module is the Puppet implementation of the Center for Internet Security (CIS) benchmark for for Postgres database. This module will help you:
We now support the current versions of the CIS benchmarks:
See here for a way to get started with the pg_secured
module.
The design goals for the pg_secured module where:
Let’s go over these design goals.
Securing your database with the pg_secured
module is as easy as adding one line of puppet code to your manifest. In its most basic form:
pg_secured::ensure_cis {'MYDB':}
is enough.
The CIS benchmark and STIG documents are very extensive. Applying ALL controls can make your database too secure for your application. The pg_secured
module allows you to specify what controls you want to skip. You can, for examle use the parameter skip_list
pg_secured::ensure_cis {'MYDB':
skip_list => [
'log_file_destination_directory_is_set_correctly',
'filename_pattern_for_log_files_is_set_correctly',
You can also use hiera to skip certain controls. Here is an example of that:
pg_secured::controls::log_file_destination_directory_is_set_correctly::mydb: skip
pg_secured::controls::filename_pattern_for_log_files_is_set_correctly::mydb: skip
For specific controls, the CIS benchmark allows you to specify a value. To be compiant with the CIS benchmark, the specified value must be within a specific range. The pg_secured
module supports this. Let’s look at an example. The control failed_login_attempts_is_less_than_or_equal_to_5
guards that the number of failed login attempts is 5 or less (as the name states). The default value the pg_secured
module enforces is 5
. But you can make it less. You can use the value 3
.
pg_secured::controls::failed_login_attempts_is_less_than_or_equal_to_5::preferred_value: 3
Is a way to do this. To ensure you stay compliant, the pg_secured
module enforces that the values stay within the bounds of CIS range. When you specify a value that is outside of the range, Puppet will not accept it. Here is an example when we specify 6
:
Error: Evaluation Error: Error while evaluating a Resource Statement, Pg_secured::Controls::Failed_login_attempts_is_less_than_or_equal_to_5[TEST]: parameter 'preferred_value' expects an Integer[0, 5] value, got Integer[6, 6] (file: /root/examples/apply_one_control.pp, line: 5) on node pg_secured
Many CIS controls layout settings that must apply to all objects in the database. Some organizations battle with this. Most of the time, there are just a few objects that have to deviate from a control to keep the application working. The pg_secured
module supports this. You can specify exclusion rules.
TODO: Add an example
Although it is excellent that Puppet guards the compliance of your database, it is good to know that when Puppet changes something, WHY it changed something. What was the control that caused this? And preferably, what paragraph in what version of the CIS benchmark states this.
The pg_secured
module helps you with this. Here is some example output:
Notice: /Stage[main]/pg13::V1_0_0::P5_1_1_1::Test/pg_secured::Controls::Execute_is_revoked_from_public_on_network_packages[TEST]/pg_secured::Internal::Revoke_public_grants[DBMS_LDAP@TEST]/Pg_object_grant[PUBLIC->SYS.DBMS_LDAP@TEST]/permissions: revoked the EXECUTE right(s)
Notice: /Stage[main]/pg13::V1_0_0::P6_1_1::Test/pg_secured::Controls::User_audit_option_is_enabled[TEST]/pg_secured::Internal::Audit_option[USER@TEST]/Pg_statement_audit[USER@TEST]/ensure: created
Notice: /Stage[main]/pg13::V1_0_0::P6_1_2::Test/pg_secured::Controls::Role_audit_option_is_enabled[TEST]/pg_secured::Internal::Audit_option[ROLE@TEST]/Pg_statement_audit[ROLE@TEST]/ensure: created
Notice: /Stage[main]/pg13::V1_0_0::P3_1::Test/pg_secured::Controls::Failed_login_attempts_is_less_than_or_equal_to_5[TEST]/pg_secured::Internal::Profile_setting[failed_login_attempts@TEST]/Pg_profile[DEFAULT@TEST]/failed_login_attempts: failed_login_attempts changed 10 to 5
Notice: /Stage[main]/pg13::V1_0_0::P6_2_1::Test/pg_secured::Controls::Create_user_action_audit_is_enabled[TEST]/pg_secured::Internal::Audit_policy[actions@TEST@create_user]/Pg_audit_
As you can see all of the messages contain:
The database version of the CIS benchmark (e.g. /pg13
)
The document version of the CIS benchmark (e.g. ::V1_0_0
)
The paragraph in the CIS benchmark (e.g. ::P6_2_1
)
The database that is changed (e.g. ``::Test)
The name of the control (e.g.
create_user_action_audit_is_enabled`)
This way, you can always see what the reason is for a change.
Because the exclusion lists, preferred values, and skip lists, are bound to the name of the control, your customizations will most of the times be compatible with newer versions of a CIS benchmark. So when a newer version comes. You only have to change the doc_version
property. Let’s see an example. Let’s say a V1.1.0 for the pg13
is available.
pg_secured::ensure_cis {'MYDB':
product_version => 'pg14',
doc_version => 'V1.1.0'
}
This is enough to start using the new CIS version. Sometimes CIS. Of course you will still have to look if new controls are available that you want to skip or customize. Also, sometimes the value of a configuration item changes. This will cause a new control in the pg_secured
module. Let’s look at this in a contrived example.
Let’s say that in the CIS document, the setting for the number of failed login attempts has been changed from a value of 5
or less to a value of 3
or less. The original control was named: failed_login_attempts_is_less_than_or_equal_to_5
. It will still be available. But a new control is also available. It is now called failed_login_attempts_is_less_than_or_equal_to_3
. Just change these values in your skip_lists, excludes and preferred value settings is enough.
Our modules are based on an annual subscription(an entitlement). When you purchase an entitlement:
We will make sure the modules keep working with the latest versions of Puppet en the supporting products like Oracle IBM MQ or WebLogic.
We currently have the following licensing methods for you:
1) Free when used on VirtualBox
2) Per node per year subscription
3) Custom licensing
This module is Free when used on a VirtualBox testing machine. The software checks if you are using VirtualBox and allows usage. No need to get any licenses from us to get going. Just download the module from our own forge and get going. To download the module use:
puppet module install
--module_repository=http://forge.enterprisemodules.com
enterprisemodules-modulename
Our basic licensing model requires a subscription per node. The subscription is valid for a year. To make this work, we need you to send us the node name of the system you want to use the module on. (Not the puppetmaster, but the system where the agent is running.). Based on this information we will send you a file containing the entitlement for your node(s). You can purchase the entitlement in the shop or you can contact us. After you have ordered this module, you will receive an entitlement file. This file contains the information needed to run the software on your Puppet machine (agents).
Our license manager is very flexible. If you have special requirements, please contact us so we can discuss other options.
When you have questions about licensing, please contact us or check our licensing FAQ
The pg_secured
module requires:
Here you can find some more information regarding this puppet module:
Some example code:
Also check out the Postgres database playgrounds here, where you can experiment with these modules without downloading or installing any software.