Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

pg_secured

Manage Postgres security benchmarks including CIS and STIG's
Project URLRSS Feed

4,973 downloads

362 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.5.0 (latest)
  • 0.4.0
  • 0.3.3
  • 0.3.2
  • 0.3.1
  • 0.3.0
  • 0.2.8
  • 0.2.7
  • 0.2.6
  • 0.2.5
  • 0.2.4
  • 0.2.3
  • 0.2.2
  • 0.2.1
  • 0.2.0
  • 0.1.1
  • 0.1.0
released Nov 3rd 2022
This version is compatible with:
  • Puppet Enterprise 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x
  • Puppet >= 5.0.0 < 8.0.0
  • , , , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'enterprisemodules-pg_secured', '0.5.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add enterprisemodules-pg_secured
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install enterprisemodules-pg_secured --version 0.5.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download
Tags: database, security, postgres, benchmark, stig, cis

Documentation

enterprisemodules/pg_secured — version 0.5.0 Nov 3rd 2022

Enterprise Modules

Table of Contents

Overview

The pg_secured module is the Puppet implementation of multiple security-related controls. At this point in time we support:

We now support the current versions:

We are currently working on:

  • STIG PostgreSQL 9.x Security Technical Implementation Guide

The module is part of our family of Puppet modules to manage and secure Postgres databases with Puppet. Besides the pg_secured module, this family also contains:

  • pg_config For configuring every aspect of your Postgres database
  • pg_profile As an easy customizable profile class to manage your complete progress setup.

License

This is an affordable commercially licensed module. But you can use the module on VirtualBox based development systems for FREE. When used on real systems a license is required.

You can license our modules in multiple ways. Our basic licensing model requires a subscription per node. But contact us for details.

Check the License for details.

Description

Let's first dive into the question: "What configuration settings are needed to get my system secure?". Many people have asked themselves this question. The Center for Internet Security (CIS) is one of the means to get an answer. CIS also has a security baseline for Postgres 12: CIS Postgres Database Server 12c Benchmark v2.0.0. We have taken this baseline and Puppetized it for you to use.

It is called the pg_secured and contains an implementation of all rules in the benchmark that describe a configuration setting inside of the database. At this point 124 of the 129 rules are implemented and 5 are not because they rely on settings outside of the database.

On a Puppet run, the module will inspect all settings described in the CIS rules and apply changes to them if they deviate from the standard. (If you have started the Puppet run with a noop, it will do nothing but report all changes that would have been made. ). All changes will be reported to the Puppet master and on the console, you get an overview of the changes. Because the Puppet agent runs every 20 minutes (or different if you set it to a different interval) every 20 minutes your database configuration is checked against the CIS benchmark and you can sleep well and be assured your data is safe.

Check the documentation here

Setup

Requirements

The pg_secured module requires:

  • Puppet module enterprisemodules-easy_type installed.
  • Puppet version 4.0 or higher. Can be Puppet Enterprise or Puppet Open Source
  • Postgres 12 or higher
  • A valid Postgres license
  • A valid Enterprise Modules license for usage.
  • Runs on most Linux systems.
  • Runs on Solaris

Installing the pg_secured module

To install these modules, you can use a Puppetfile

mod 'enterprisemodules/pg_secured'               ,'3.x.x'

Then use the librarian-puppet or r10K to install the software.

You can also install the software using the puppet module command:

puppet module install enterprisemodules-pg_secured

Usage

The scope of securing your Postgres database is large. The number of security controls in the CIS benchmark is large. This might make you think that it is difficult to get started, but actually, it is very simple.

Enabling CIS for your database

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:

"`puppet pg_secured::ensure_cis {'MYDB':}

is enough.

#### Easy to skip controls

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`

```puppet
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

Easy to customize values

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

Correlate Puppet changes to CIS

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.

Upgrade to a new CIS or Postgres version

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 more recent 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.

Reference

Here you can find some more information regarding this puppet module:

Limitations

This module runs on most Linux versions. It requires a puppet version 5 or higher. The module does NOT run on windows systems.