Version information
This version is compatible with:
- Puppet Enterprise 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
- RedHat,CentOS,OracleLinux
Start using this module
Add this module to your Puppetfile:
mod 'enterprisemodules-pg_secured', '0.2.8'Learn more about managing modules with a PuppetfileDocumentation
Table of Contents
- Usage - Configuration options and additional functionality
- Reference - An under-the-hood peek at what the module is doing and how
- Limitations - OS compatibility, etc.
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_typeinstalled. - 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]/Ora_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]/Ora_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]/Ora_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]/Ora_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]/Ora_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 => 'pg13',
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.
Reference
Table of Contents
Classes
pg_secured::ensure_pg_permissions_libraries: See the file "LICENSE" for the full license governing this code. ++--++ pg_secured::ensure_permissions_libraries Make sure all required papg_secured::ensure_set_user_libraries: See the file "LICENSE" for the full license governing this code. ++--++ pg_secured::ensure_set_user_libraries Make sure all required packe
Defined types
pg_secured::controls::backend_runtime_parameters_are_configured_correctly: In order to serve multiple clients efficiently, the PostgreSQL server launches apg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured: pgBackRest aims to be a simple, reliable backup and restore system that can seamlessly scale up to the largest databases and workloads.pg_secured::controls::correct_messages_are_written_to_the_server_log: The log_min_messages setting specifies the message levels that are written topg_secured::controls::correct_sql_statements_generating_errors_are_recorded: The log_min_error_statement setting causes all SQL statements generating errorspg_secured::controls::correct_syslog_facility_is_selected: The syslog_facility setting specifies the syslog "facility" to be used whenpg_secured::controls::data_cluster_initialized_successfully: First time installs of PostgreSQL requires the instantiation of the databasepg_secured::controls::debug_pretty_print_is_enabled: Enabling debug_pretty_print indents the messages produced by debug_print_parse,pg_secured::controls::debug_print_parse_is_disabled: The debug_print_parse setting enables printing the resulting parse tree for eachpg_secured::controls::debug_print_plan_is_disabled: The debug_print_plan setting enables printing the execution plan for each executed query.pg_secured::controls::debug_print_rewritten_is_disabled: The debug_print_rewritten setting enables printing the query rewriter output forpg_secured::controls::excessive_administrative_privileges_are_revoked: With respect to PostgreSQL administrative SQL commands, only superusers shouldpg_secured::controls::excessive_dml_privileges_are_revoked: DML (insert, update, delete) operations at the table level should be restrictedpg_secured::controls::excessive_function_privileges_are_revoked: In certain situations, to provide required functionality, PostgreSQL needs topg_secured::controls::file_permissions_mask_is_correct: TODO: Write documentationpg_secured::controls::filename_pattern_for_log_files_is_set_correctly: The log_filename setting specifies the filename pattern for log files.pg_secured::controls::fips_140_2_openssl_cryptography_is_used: Install, configure, and use OpenSSL on a platform that has a NIST certified FIPSpg_secured::controls::log_connections_is_enabled: Enabling the log_connections setting causes each attempted connection to thepg_secured::controls::log_destinations_are_set_correctly: PostgreSQL supports several methods for logging server messages, includingpg_secured::controls::log_disconnections_is_enabled: Enabling the log_disconnections setting logs the end of each session, includingpg_secured::controls::log_error_verbosity_is_set_correctly: The log_error_verbosity setting specifies the verbosity (amount of detail) ofpg_secured::controls::log_file_destination_directory_is_set_correctly: The log_directory setting specifies the destination directory for log files whenpg_secured::controls::log_file_permissions_are_set_correctly: The log_file_mode setting determines the file permissions for log files whenpg_secured::controls::log_hostname_is_set_correctly: Enabling the log_hostname setting causes the hostname of the connecting host topg_secured::controls::log_line_prefix_is_set_correctly: The log_line_prefix setting specifies a printf-style string that is prefixed topg_secured::controls::log_statement_is_set_correctly: The log_statement setting specifies the types of SQL statements that are logged.pg_secured::controls::log_timezone_is_set_correctly: The log_timezone setting specifies the time zone to use in timestamps within logpg_secured::controls::log_truncate_on_rotation_is_enabled: Enabling the log_truncate_on_rotation setting when logging_collector is enabledpg_secured::controls::logging_collector_is_enabled: The logging collector is a background process that captures log messages sent topg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly: A large number of authentication METHODs are available for hosts connectingpg_secured::controls::maximum_log_file_lifetime_is_set_correctly: When logging_collector is enabled, the log_rotation_age parameter determines thepg_secured::controls::maximum_log_file_size_is_set_correctly: The log_rotation_size setting determines the maximum size of an individual logpg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled: The PostgreSQL Audit Extension (pgAudit) provides detailed session and/or objectpg_secured::controls::postgresql_pg_wheel_group_membership_is_correct: pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct The group pg_wheel is explicitly created on a host where the PostgreSQpg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct: The syslog_ident setting specifies the program name used to identify PostgreSQLpg_secured::controls::set_user_extension_is_installed: Even when reducing and limiting the access to the superuser role as describedpg_secured::controls::ssl_is_enabled_and_configured_correctly: SSL on a PostgreSQL server should be enabled (set to on) and configured to encrypt TCP traffic to and from the server.pg_secured::controls::sudo_is_configured_correctly: It is common to have more than one authorized individual administering thepg_secured::controls::systemd_service_files_are_enabled: Confirm, and correct if necessary, the PostgreSQL systemd service is enabled.pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions: Using a PostgreSQL extension called pg_permissions it is possible to declare which DB users should have which permissions on a given object and generate a report showing compliance/deviation.pg_secured::controls::wal_archiving_is_configured_and_functional: Write Ahead Log (WAL) Archiving, or Log Shipping, is the process of sendingpg_secured::ensure_cis: defined typepg_secured::ensure_cispg_secured::ensure_set: defined typepg_secured::ensure_setpg_secured::ensure_stig: defined typepg_securedpg_secured::internal::ensure_extension: See the file "LICENSE" for the full license governing this code. ++--++ --++--pg_secured::internal::set_parameter: See the file "LICENSE" for the full license governing this code. ++--++ --++--
Resource types
pg_secured_setup: Start the setup for applying postgres secure classes.
Functions
pg_secured::default_doc_version: See the file "LICENSE" for the full license governing this code. This function determins the CIS default doc_version based on the product_vepg_secured::default_product_version: See the file "LICENSE" for the full license governing this code. This function determins the CIS product_version to use for this call. It upg_secured::filter_controls: See the file "LICENSE" for the full license governing this code. Filter the list of controls based on the which database it will be appliedpg_secured::lookup_setting: See the file "LICENSE" for the full license governing this code. This function uses its current scope te infer what CIS rule is called on w
Classes
pg_secured::ensure_pg_permissions_libraries
See the file "LICENSE" for the full license governing this code.
++--++
pg_secured::ensure_permissions_libraries
Make sure all required packes and libraries are loaded for the permissions extension
--++--
Parameters
The following parameters are available in the pg_secured::ensure_pg_permissions_libraries class:
required_packages
Data type: Array[String[1]]
url
Data type: String[1]
release
Data type: String[1]
pg_secured::ensure_set_user_libraries
See the file "LICENSE" for the full license governing this code.
++--++
pg_secured::ensure_set_user_libraries
Make sure all required packes and libraries are loaded for the permissions extension
--++--
Parameters
The following parameters are available in the pg_secured::ensure_set_user_libraries class:
required_packages
Data type: Array[String[1]]
url
Data type: String[1]
release
Data type: String[1]
Defined types
pg_secured::controls::backend_runtime_parameters_are_configured_correctly
pg_secured::controls::backend_runtime_parameters_are_configured_correctly
new "backend" process for each client. The runtime parameters in this benchmark section are controlled by the backend process. The server's performance, in the form of slow queries causing a denial of service, and the RDBM's auditing abilities for determining root cause analysis can be compromised via these parameters.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::backend_runtime_parameters_are_configured_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::backend_runtime_parameters_are_configured_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content backend_runtime_parameters_are_configured_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 6.2
- Postgres Database 11 CIS V1.0.0 - paragraph 6.2
- Postgres Database 12 CIS V1.0.0 - paragraph 6.2
- Postgres Database 13 CIS V1.0.0 - paragraph 6.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::backend_runtime_parameters_are_configured_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured
pg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured
Instead of relying on traditional backup tools like tar and rsync, pgBackRest implements all backup features internally and uses a custom protocol for communicating with remote systems. Removing reliance on tar and rsync allows for better solutions to database-specific backup challenges. The custom remote protocol allows for more flexibility and limits the types of connections that are required to perform a backup which increases security.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content backup_and_restore_tool_pgbackrest_is_installed_and_configured to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 8.3
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::backup_and_restore_tool_pgbackrest_is_installed_and_configured defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::correct_messages_are_written_to_the_server_log
pg_secured::controls::correct_messages_are_written_to_the_server_log
the server log. Each level includes all the levels that follow it. The lower the level (vertically, below), the fewer messages are sent. Valid values are:
- DEBUG5 <-- exceedingly chatty
- DEBUG4
- DEBUG3
- DEBUG2
- DEBUG1
- INFO
- NOTICE
- WARNING
- ERROR
- LOG
- FATAL
- PANIC <-- practically mute WARNING is considered the best practice unless indicated otherwise by your organization's logging policy.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::correct_messages_are_written_to_the_server_log: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::correct_messages_are_written_to_the_server_log::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content correct_messages_are_written_to_the_server_log to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.12
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::correct_messages_are_written_to_the_server_log defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::correct_sql_statements_generating_errors_are_recorded
pg_secured::controls::correct_sql_statements_generating_errors_are_recorded
at or above the specified severity level to be recorded in the server log. Each level includes all the levels that follow it. The lower the level (vertically, below), the fewer messages are recorded. Valid values are:
- DEBUG5 <-- exceedingly chatty
- DEBUG4
- DEBUG3
- DEBUG2
- DEBUG1
- INFO
- NOTICE
- WARNING
- ERROR
- LOG
- FATAL
- PANIC <-- practically mute ERROR is considered the best practice setting.
Changes should only be made in accordance with your organization's logging policy.
Note: To effectively turn off logging of failing statements, set this parameter to PANIC.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::correct_sql_statements_generating_errors_are_recorded: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::correct_sql_statements_generating_errors_are_recorded::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content correct_sql_statements_generating_errors_are_recorded to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.13
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::correct_sql_statements_generating_errors_are_recorded defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::correct_syslog_facility_is_selected
pg_secured::controls::correct_syslog_facility_is_selected
logging to syslog is enabled. You can choose from any of the 'local' facilities: • LOCAL0 • LOCAL1 • LOCAL2 • LOCAL3 • LOCAL4 • LOCAL5 • LOCAL6 • LOCAL7 Your organization's logging policy should dictate which facility to use based on the syslog daemon in use.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::correct_syslog_facility_is_selected: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::correct_syslog_facility_is_selected::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content correct_syslog_facility_is_selected to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.10
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.10
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.10
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.10
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::correct_syslog_facility_is_selected defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::data_cluster_initialized_successfully
pg_secured::controls::data_cluster_initialized_successfully
cluster. A database cluster is a collection of databases that are managed by a single server instance.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::data_cluster_initialized_successfully: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::data_cluster_initialized_successfully::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content data_cluster_initialized_successfully to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 1.5
- Postgres Database 11 CIS V1.0.0 - paragraph 1.5
- Postgres Database 12 CIS V1.0.0 - paragraph 1.5
- Postgres Database 13 CIS V1.0.0 - paragraph 1.3
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::data_cluster_initialized_successfully defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::debug_pretty_print_is_enabled
pg_secured::controls::debug_pretty_print_is_enabled
debug_print_rewritten, or debug_print_plan making them significantly easier to read.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::debug_pretty_print_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::debug_pretty_print_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content debug_pretty_print_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.17
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.17
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.17
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.17
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::debug_pretty_print_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::debug_print_parse_is_disabled
pg_secured::controls::debug_print_parse_is_disabled
executed query. These messages are emitted at the LOG message level. Unless directed otherwise by your organization's logging policy, it is recommended this setting be disabled by setting it to off.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::debug_print_parse_is_disabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::debug_print_parse_is_disabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content debug_print_parse_is_disabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.14
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.14
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.14
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.14
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::debug_print_parse_is_disabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::debug_print_plan_is_disabled
pg_secured::controls::debug_print_plan_is_disabled
These messages are emitted at the LOG message level. Unless directed otherwise by your organization's logging policy, it is recommended this setting be disabled by setting it to off.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::debug_print_plan_is_disabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::debug_print_plan_is_disabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content debug_print_plan_is_disabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.16
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.16
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.16
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.16
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::debug_print_plan_is_disabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::debug_print_rewritten_is_disabled
pg_secured::controls::debug_print_rewritten_is_disabled
each executed query. These messages are emitted at the LOG message level. Unless directed otherwise by your organization's logging policy, it is recommended this setting be disabled by setting it to off.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::debug_print_rewritten_is_disabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::debug_print_rewritten_is_disabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content debug_print_rewritten_is_disabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.15
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.15
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.15
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.15
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::debug_print_rewritten_is_disabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::excessive_administrative_privileges_are_revoked
pg_secured::controls::excessive_administrative_privileges_are_revoked
have elevated privileges. PostgreSQL regular, or application, users should not possess the ability to create roles, create new databases, manage replication, or perform any other action deemed privileged. Typically, regular users should only be granted the minimal set of privileges commensurate with managing the application:
- DDL (create table, create view, create index, etc.)
- DML (select, insert, update, delete)
Further, it has become best practice to create separate roles for DDL and DML. Given an application called 'payroll', one would create the following users:
- payroll_owner
- payroll_user
Any DDL privileges would be granted to the payroll_owner account only, while DML privileges would be given to the payroll_user account only. This prevents accidental creation/altering/dropping of database objects by application code that run as the payroll_user account.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::excessive_administrative_privileges_are_revoked: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::excessive_administrative_privileges_are_revoked::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content excessive_administrative_privileges_are_revoked to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 4.2
- Postgres Database 11 CIS V1.0.0 - paragraph 4.2
- Postgres Database 12 CIS V1.0.0 - paragraph 4.2
- Postgres Database 13 CIS V1.0.0 - paragraph 4.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::excessive_administrative_privileges_are_revoked defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
exclude
Data type: Array
Default value: pg_secured::lookup_setting('exclude', [])
pg_secured::controls::excessive_dml_privileges_are_revoked
pg_secured::controls::excessive_dml_privileges_are_revoked
to only authorized users. PostgreSQL manages table level DML permissions via the GRANT statement.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::excessive_dml_privileges_are_revoked: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::excessive_dml_privileges_are_revoked::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content excessive_dml_privileges_are_revoked to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 4.4
- Postgres Database 11 CIS V1.0.0 - paragraph 4.4
- Postgres Database 12 CIS V1.0.0 - paragraph 4.4
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::excessive_dml_privileges_are_revoked defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::excessive_function_privileges_are_revoked
pg_secured::controls::excessive_function_privileges_are_revoked
execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by their organization. This is known as privilege elevation. Privilege elevation must be utilized only where necessary. Execute privileges for application functions should be restricted to authorized users only.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::excessive_function_privileges_are_revoked: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::excessive_function_privileges_are_revoked::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content excessive_function_privileges_are_revoked to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 4.3
- Postgres Database 11 CIS V1.0.0 - paragraph 4.3
- Postgres Database 12 CIS V1.0.0 - paragraph 4.3
- Postgres Database 13 CIS V1.0.0 - paragraph 4.3
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::excessive_function_privileges_are_revoked defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
exclude
Data type: Array
The objects to exclude from the control actions.
Default value: pg_secured::lookup_setting('exclude', [])
pg_secured::controls::file_permissions_mask_is_correct
pg_secured::controls::file_permissions_mask_is_correct
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::file_permissions_mask_is_correct: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::file_permissions_mask_is_correct::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content file_permissions_mask_is_correct to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 2.1
- Postgres Database 11 CIS V1.0.0 - paragraph 2.1
- Postgres Database 12 CIS V1.0.0 - paragraph 2.1
- Postgres Database 13 CIS V1.0.0 - paragraph 2.1
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::file_permissions_mask_is_correct defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::filename_pattern_for_log_files_is_set_correctly
pg_secured::controls::filename_pattern_for_log_files_is_set_correctly
The value for log_filename should match your organization's logging policy. The value is treated as a strftime pattern, so %-escapes can be used to specify time- varying filenames. The supported %-escapes are similar to those listed in the Open Group's strftime specification. If you specify a filename without escapes, you should plan to use a log rotation utility to avoid eventually filling the partition that contains log_directory. If there are any time-zone-dependent %-escapes, the computation is done in the zone specified by log_timezone. Also, the system's strftime is not used directly, so platform- specific (nonstandard) extensions do not work. If CSV-format output is enabled in log_destination, .csv will be appended to the log filename. (If log_filename ends in .log, the suffix is replaced instead.)
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::filename_pattern_for_log_files_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::filename_pattern_for_log_files_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content filename_pattern_for_log_files_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.5
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.5
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.5
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.5
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::filename_pattern_for_log_files_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::fips_140_2_openssl_cryptography_is_used
pg_secured::controls::fips_140_2_openssl_cryptography_is_used
140-2 installation of OpenSSL. This provides PostgreSQL instances the ability to generate and validate cryptographic hashes to protect unclassified information requiring confidentiality and cryptographic protection, in accordance with the data owner's requirements.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::fips_140_2_openssl_cryptography_is_used: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::fips_140_2_openssl_cryptography_is_used::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content fips_140_2_openssl_cryptography_is_used to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 6.7
- Postgres Database 11 CIS V1.0.0 - paragraph 6.7
- Postgres Database 12 CIS V1.0.0 - paragraph 6.7
- Postgres Database 13 CIS V1.0.0 - paragraph 6.7
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::fips_140_2_openssl_cryptography_is_used defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_connections_is_enabled
pg_secured::controls::log_connections_is_enabled
server to be logged, as well as successful completion of client authentication. This parameter cannot be changed after session start.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_connections_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_connections_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_connections_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.18
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.18
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.18
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.18
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_connections_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_destinations_are_set_correctly
pg_secured::controls::log_destinations_are_set_correctly
stderr, csvlog and syslog. On Windows, eventlog is also supported. One or more of these destinations should be set for server log output.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_destinations_are_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_destinations_are_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_destinations_are_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.2
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.2
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.2
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_destinations_are_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_disconnections_is_enabled
pg_secured::controls::log_disconnections_is_enabled
session duration. This parameter cannot be changed after session start.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_disconnections_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_disconnections_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_disconnections_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.19
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.19
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.19
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.19
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_disconnections_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_error_verbosity_is_set_correctly
pg_secured::controls::log_error_verbosity_is_set_correctly
logged messages. Valid values are:
- TERSE
- DEFAULT
- VERBOSE
with each containing the fields of the level above it as well as additional fields. TERSE excludes the logging of DETAIL, HINT, QUERY, and CONTEXT error information. VERBOSE output includes the SQLSTATE, error code, and the source code file name, function name, and line number that generated the error. The appropriate value should be set based on your organization's logging policy.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_error_verbosity_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_error_verbosity_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_error_verbosity_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.20
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_error_verbosity_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_file_destination_directory_is_set_correctly
pg_secured::controls::log_file_destination_directory_is_set_correctly
log_destination is stderr or csvlog. It can be specified as relative to the cluster data directory ($PGDATA) or as an absolute path. log_directory should be set according to your organization's logging policy.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_file_destination_directory_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_file_destination_directory_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_file_destination_directory_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.4
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.4
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.4
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.4
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_file_destination_directory_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_file_permissions_are_set_correctly
pg_secured::controls::log_file_permissions_are_set_correctly
logging_collector is enabled. The parameter value is expected to be a numeric mode specification in the form accepted by the chmod and umask system calls. (To use the customary octal format, the number must start with a 0 (zero).) The permissions should be set to allow only the necessary access to authorized personnel. In most cases the best setting is 0600, so that only the server owner can read or write the log files. The other commonly useful setting is 0640, allowing members of the owner's group to read the files, although to make use of that, you will need to alter the log_directory setting to store the log files outside the cluster data directory.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_file_permissions_are_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_file_permissions_are_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_file_permissions_are_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.6
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.6
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.6
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.6
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_file_permissions_are_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_hostname_is_set_correctly
pg_secured::controls::log_hostname_is_set_correctly
be logged in addition to the host's IP address for connection log messages. Disabling the setting causes only the connecting host's IP address to be logged, and not the hostname. Unless your organization's logging policy requires hostname logging, it is best to disable this setting so as not to incur the overhead of DNS resolution for each statement that is logged.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_hostname_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_hostname_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_hostname_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.21
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.21
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.21
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.21
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_hostname_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_line_prefix_is_set_correctly
pg_secured::controls::log_line_prefix_is_set_correctly
each log line. If blank, no prefix is used. You should configure this as recommended by the pgBadger development team unless directed otherwise by your organization's logging policy. % characters begin "escape sequences" that are replaced with status information as outlined below. Unrecognized escapes are ignored. Other characters are copied straight to the log line. Some escapes are only recognized by session processes and will be treated as empty by background processes such as the main server process. Status information may be aligned either left or right by specifying a numeric literal after the % and before the option. A negative value will cause the status information to be padded on the right with spaces to give it a minimum width, whereas a positive value will pad on the left. Padding can be useful to aid human readability in log files. Any of the following escape sequences can be used:
%a = application name
%u = user name
%d = database name
%r = remote host and port %h = remote host
%b = backend type
%p = process ID
%t = timestamp without milliseconds
%m = timestamp with milliseconds
%n = timestamp with milliseconds (as a Unix epoch) %i = command tag
%e = SQL state
%c = session ID
%l = session line number
%s = session start timestamp
%v = virtual transaction ID
%x = transaction ID (0 if none)
%q = stop here in non-session processes
%% = '%'
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_line_prefix_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_line_prefix_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_line_prefix_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.22
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_line_prefix_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_statement_is_set_correctly
pg_secured::controls::log_statement_is_set_correctly
Valid values are:
- none (off)
- ddl
- mod
- all (all statements)
It is recommended this be set to ddl unless otherwise directed by your organization's logging policy. ddl logs all data definition statements:
- CREATE
- ALTER
- DROP
mod logs all ddl statements, plus data-modifying statements:
- INSERT
- UPDATE
- DELETE
- TRUNCATE
- COPY FROM
(PREPARE, EXECUTE, and EXPLAIN ANALYZE statements are also logged if their contained command is of an appropriate type.) For clients using extended query protocol, logging occurs when an Execute message is received, and values of the Bind parameters are included (with any embedded single-quote marks doubled).
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_statement_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_statement_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_statement_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.23
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.23
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.23
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.23
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_statement_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::log_timezone_is_set_correctly
pg_secured::controls::log_timezone_is_set_correctly
messages. This value is cluster-wide, so that all sessions will report timestamps consistently. Unless directed otherwise by your organization's logging policy, set this to either GMT or UTC.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_timezone_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_timezone_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_timezone_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.24
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.24
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.24
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.24
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_timezone_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
preferred_value
Data type: String[1]
Default value: pg_secured::lookup_setting('preferred_value', 'GMT')
pg_secured::controls::log_truncate_on_rotation_is_enabled
pg_secured::controls::log_truncate_on_rotation_is_enabled
causes PostgreSQL to truncate (overwrite) existing log files with the same name during log rotation instead of appending to them. For example, using this setting in combination with a log_filename setting value like postgresql-%H.log would result in generating 24 hourly log files and then cyclically overwriting them: Note: Truncation will occur only when a new file is being opened due to time-based rotation, not during server startup or size-based rotation (see later in this benchmark for size-based rotation details).
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::log_truncate_on_rotation_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::log_truncate_on_rotation_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content log_truncate_on_rotation_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.7
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.7
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.7
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.7
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::log_truncate_on_rotation_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::logging_collector_is_enabled
pg_secured::controls::logging_collector_is_enabled
stderr and redirects them into log files. The logging_collector setting must be enabled in order for this process to run. It can only be set at server start.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::logging_collector_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::logging_collector_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content logging_collector_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.3
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.3
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.3
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.3
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::logging_collector_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly
pg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly
using TCP/IP sockets, including:
- trust
- reject
- md5
- scram-sha-256
- password
- gss
- sspi
- ident
- pam
- ldap
- radius
- cert
METHODs trust, password, and ident are not to be used for remote logins. METHOD md5 is the most popular and can be used in both encrypted and unencrypted sessions,however, it is vulnerable to packet replay attacks. It is recommended that scram-sha-256 be used instead of md5. Use of the gss, sspi, pam, ldap, radius, and cert METHODs, while more secure than md5, are dependent upon the availability of external authenticating processes/services and thus are not covered in this benchmark.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content login_via_host_tcp_ip_socket_is_configured_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
-
Postgres Database 10 CIS V1.0.0 - paragraph 5.2
-
Postgres Database 11 CIS V1.0.0 - paragraph 5.2
-
Postgres Database 12 CIS V1.0.0 - paragraph 5.2
-
Postgres Database 13 CIS V1.0.0 - paragraph 5.2
The authentication method to use for remote connections.
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::login_via_host_tcp_ip_socket_is_configured_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
exclude
Data type: Array[String[1]]
The objects to exclude from the control actions.
Default value: pg_secured::lookup_setting('exclude', [])
preferred_value
Data type: Enum['reject','md5','scram-sha-256','gss','sspi','pam','ldap','radius','cert']
Default value: pg_secured::lookup_setting('preferred_value', 'scram-sha-256')
pg_secured::controls::maximum_log_file_lifetime_is_set_correctly
pg_secured::controls::maximum_log_file_lifetime_is_set_correctly
maximum lifetime of an individual log file (depending on the value of log_filename). After this many minutes have elapsed, a new log file will be created via automatic log file rotation. Current best practices advise log rotation at least daily, but your organization's logging policy should dictate your rotation schedule.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::maximum_log_file_lifetime_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::maximum_log_file_lifetime_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content maximum_log_file_lifetime_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.8
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.8
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.8
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.8
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::maximum_log_file_lifetime_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::maximum_log_file_size_is_set_correctly
pg_secured::controls::maximum_log_file_size_is_set_correctly
file. Once the maximum size is reached, automatic log file rotation will occur.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::maximum_log_file_size_is_set_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::maximum_log_file_size_is_set_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content maximum_log_file_size_is_set_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.9
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.9
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.9
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.9
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::maximum_log_file_size_is_set_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled
pg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled
audit logging via the standard PostgreSQL logging facility. The goal of pgAudit is to provide PostgreSQL users with the capability to produce audit logs often required to comply with government, financial, or ISO certifications.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content postgresql_audit_extension_pgaudit_is_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.2
- Postgres Database 11 CIS V1.0.0 - paragraph 3.2
- Postgres Database 12 CIS V1.0.0 - paragraph 3.2
- Postgres Database 13 CIS V1.0.0 - paragraph 3.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::postgresql_audit_extension_pgaudit_is_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct
pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct
The group pg_wheel is explicitly created on a host where the PostgreSQL serveris installed. Membership in this group enables an ordinary user account to gain'superuser' access to a database cluster by using the sudo command (See 'Ensuresudo is configured correctly' later in this benchmark). Only user accountsauthorized to have superuser access should be members of the pg_wheel group.## SkippingTo deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provideyou with three ways:1) Add pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct: skip to your hiera data. This will skip this control for ALL databases. 2) Add pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct::dbname: skip to your hiera data. This will skip this control for specified database only. 3) Add an entry with the content postgresql_pg_wheel_group_membership_is_correct to the array value pg_secured::skip_list in your hiera data. ## BenchmarksThis control is used in the following benchmarks:- Postgres Database 10 CIS V1.0.0 - paragraph 2.2- Postgres Database 11 CIS V1.0.0 - paragraph 2.2- Postgres Database 12 CIS V1.0.0 - paragraph 2.2- Postgres Database 13 CIS V1.0.0 - paragraph 2.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::postgresql_pg_wheel_group_membership_is_correct defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
gid
Data type: Integer
Default value: pg_secured::lookup_setting('gid', 1001)
authorized_users
Data type: Array[String[1]]
Default value: pg_secured::lookup_setting('authorized_users', ['postgres'])
pg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct
pg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct
messages in syslog logs. An example of a possible program name is postgres.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content program_name_for_postgresql_syslog_messages_is_correct to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 3.1.11
- Postgres Database 11 CIS V1.0.0 - paragraph 3.1.11
- Postgres Database 12 CIS V1.0.0 - paragraph 3.1.11
- Postgres Database 13 CIS V1.0.0 - paragraph 3.1.11
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::program_name_for_postgresql_syslog_messages_is_correct defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
preferred_value
Data type: String[1]
Default value: pg_secured::lookup_setting('preferred_value', 'proddb')
pg_secured::controls::set_user_extension_is_installed
pg_secured::controls::set_user_extension_is_installed
earlier in this benchmark, it is still difficult to determine who accessed the superuser role and what actions were taken using that role. As such, it is ideal to prevent anyone from logging in as the superuser and forcing them to escalate their role. This model is used at the OS level by the use of sudo and should be emulated in the database. The set_user extension allows for this setup.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::set_user_extension_is_installed: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::set_user_extension_is_installed::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content set_user_extension_is_installed to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 4.7
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::set_user_extension_is_installed defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
ensure_libraries
Data type: String[1]
Default value: 'pg_secured::ensure_set_user_libraries'
pg_secured::controls::ssl_is_enabled_and_configured_correctly
pg_secured::controls::ssl_is_enabled_and_configured_correctly
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::ssl_is_enabled_and_configured_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::ssl_is_enabled_and_configured_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content ssl_is_enabled_and_configured_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 6.8
- Postgres Database 11 CIS V1.0.0 - paragraph 6.8
- Postgres Database 12 CIS V1.0.0 - paragraph 6.8
- Postgres Database 13 CIS V1.0.0 - paragraph 6.8
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::ssl_is_enabled_and_configured_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::sudo_is_configured_correctly
pg_secured::controls::sudo_is_configured_correctly
PostgreSQL service at the Operating System level. It is also quite common to permit login privileges to individuals on a PostgreSQL host who otherwise are not authorized to access the server's data cluster and files. Administering the PostgreSQL data cluster, as opposed to its data, is to be accomplished via a localhost login of a regular UNIX user account. Access to the postgres superuser account is restricted in such a manner as to interdict unauthorized access. sudo satisfies the requirements by escalating ordinary user account privileges as the PostgreSQL RDBMS superuser.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::sudo_is_configured_correctly: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::sudo_is_configured_correctly::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content sudo_is_configured_correctly to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 4.1
- Postgres Database 11 CIS V1.0.0 - paragraph 4.1
- Postgres Database 12 CIS V1.0.0 - paragraph 4.1
- Postgres Database 13 CIS V1.0.0 - paragraph 4.1
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::sudo_is_configured_correctly defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::systemd_service_files_are_enabled
pg_secured::controls::systemd_service_files_are_enabled
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::systemd_service_files_are_enabled: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::systemd_service_files_are_enabled::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content systemd_service_files_are_enabled to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 1.4
- Postgres Database 11 CIS V1.0.0 - paragraph 1.4
- Postgres Database 12 CIS V1.0.0 - paragraph 1.4
- Postgres Database 13 CIS V1.0.0 - paragraph 1.2
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::systemd_service_files_are_enabled defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions
pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content use_pg_permission_extension_to_audit_object_permissions to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 13 CIS V1.0.0 - paragraph 4.5
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::use_pg_permission_extension_to_audit_object_permissions defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
ensure_libraries
Data type: String[1]
Default value: 'pg_secured::ensure_pg_permissions_libraries'
pg_secured::controls::wal_archiving_is_configured_and_functional
pg_secured::controls::wal_archiving_is_configured_and_functional
transaction log files from the PRIMARY host either to one or more STANDBY hosts or to be archived on a remote storage device for later use, e.g. PITR. There are several utilities that can copy WALs including, but not limited to, cp, scp, sftp, and rynsc. Basically, the server follows a set of runtime parameters which defines when the WAL should be copied using one of the aforementioned utilities.
Skipping
To deliberately skip this control (e.g. meaning don't use Puppet to enforce this setting), we provide you with three ways:
1) Add pg_secured::controls::wal_archiving_is_configured_and_functional: skip to your hiera data. This will skip this control for ALL databases.
2) Add pg_secured::controls::wal_archiving_is_configured_and_functional::dbname: skip to your hiera data. This will skip this control for specified database only.
3) Add an entry with the content wal_archiving_is_configured_and_functional to the array value pg_secured::skip_list in your hiera data.
Benchmarks
This control is used in the following benchmarks:
- Postgres Database 10 CIS V1.0.0 - paragraph 7.3
- Postgres Database 11 CIS V1.0.0 - paragraph 7.3
- Postgres Database 12 CIS V1.0.0 - paragraph 7.3
- Postgres Database 13 CIS V1.0.0 - paragraph 7.3
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::controls::wal_archiving_is_configured_and_functional defined type:
title
The database to apply the control to. All controls need an database to apply the control to. Here is a simple example:
pg_secured::controls::control_name { 'DB':}
In this example, the string DB is the database to apply the control to.
pg_secured::ensure_cis
pg_secured::ensure_cis
Apply all Postgres database CIS control to the specified database
Here is an example showing how to enable the CIS bencgmark for your database.:
pg_secured::ensure_cis { 'DBNAME':
product_version => 'pg13',
doc_version => 'V1.0.0',
}
When you don't specify the doc_version, puppet automatically uses the latest version for your current product_version. If you also don't specify a product_version, Puppet will detect the version of Postgres running and use this to determine the product_version. There is, however, one issue with the detection. On an initial run Puppet canot determine what the Postgres version is. In that case, the pg_secured defined type will skip applying the CIS benchmark and wait until (hopefully) the next run the version of Postgres for specified database is available.
When you want to skip certain controls, you can use the skip_list.
pg_secured::ensure_cis { 'DBNAME':
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'log_disconnections_is_enabled',
'log_destinations_are_set_correctly',
]
}
When you have multiple database on your system and want to use the same database version and CIS document version, you can do this:
pg_secured::Ensure_cis {
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'log_disconnections_is_enabled',
'log_destinations_are_set_correctly',
]
}
pg_secured::ensure_cis {'DB1':}
pg_secured::ensure_cis {'DB2':}
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::ensure_cis defined type:
title
The database to apply the control to. The CIS benchmark need an database to apply the controls to. Here is a simple example:
pg_secured { 'DB':}
In this example, the string DB is the database to apply the controls to.
product_version
Data type: Optional[String[1]]
The database version of the CIS benchmark you want to apply.
Although not very logical, you can apply an older (or newer) database version to your database.
If you also don't specify a product_version, Puppet will detect the version of Postgres running and use this to determine the product_version. There is, however, one issue with the detection. On an initial run Puppet canot determine what the Postgres version is. In that case, the pg_secured defined type will skip applying the CIS benchmark and wait until (hopefully) the next run the version of Postgres for specified database is available.
Default value: pg_secured::default_product_version($title)
doc_version
Data type: Optional[String[1]]
The version of the CIS benchmark you want to apply to your database.
When you don't specify the doc_version, puppet automatically uses the latest version for your current product_version.
Default value: pg_secured::default_doc_version($product_version, 'cis')
all_controls
This is an internal parameter. This is the Hash containing all paragraphs from the selected CIS benchmark.
skip_list
Data type: Array
This is the list of controls that you want to skip.
By default this vale is empty, meaning pg_secured will apply ALL controls. You must specifiy the name of the control. Here is an example on how to do this:
pg_secured { 'MYDB':
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'log_file_destination_directory_is_set_correctly',
'filename_pattern_for_log_files_is_set_correctly',
]
}
Default value: []
pg_secured::ensure_set
pg_secured::ensure_set
With this defined type, you can select a subset of the CIS controls to ensure_set to your database. Currently the sets BASIC, AUDIT_ONLY and ALL are predefined.
You can also define your own sets. See here on how to define your own levels.
Here is an example on how to use this:
pg_secured::ensure_set {'DB1:
product_version => 'pg13',
doc_version => 'V1.0.0',
set => 'BASIC'
}
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::ensure_set defined type:
title
The database to apply the set of controls to to.
pg_secured::apply need an database to apply the controls to. Here is a simple example:
pg_secured::apply { 'DB':}
In this example, the string DB is the database to apply the controls to..
product_version
Data type: Optional[String[1]]
The database version of the CIS benchmark you want to apply.
Although not very logical, you can apply an older (or newer) database version to your database.
If you also don't specify a product_version, Puppet will detect the version of Postgres running and use this to determine the product_version. There is, however, one issue with the detection. On an initial run Puppet canot determine what the Postgres version is. In that case, the pg_secured defined type will skip applying the CIS benchmark and wait until (hopefully) the next run the version of Postgres for specified database is available.
Default value: pg_secured::default_product_version($title)
doc_version
Data type: Optional[String[1]]
The version of the CIS benchmark you want to apply to your database.
When you don't specify the doc_version, puppet automatically uses the latest version for your current product_version.
Default value: pg_secured::default_doc_version($product_version, 'cis')
set
Data type: String[1]
With this parameter, you can specify the set of CIS controls you want to apply to your database. Currently, we have the following sets predefined:
- ALL
- BASIC
- AUDIT_ONLY Check here for a description of the predefined sets.
Default value: 'BASIC'
benchmark
Data type: Easy_type::Baseline_type
Default value: 'cis'
pg_secured::ensure_stig
pg_secured::ensure_stig
Apply all Postgres database STIG control to the specified database
Here is an example showing how to enable the STIG bencgmark for your database.:
pg_secured::ensure_stig { 'DBNAME':
product_version => 'pg13',
doc_version => 'V1.0.0',
}
When you don't specify the doc_version, puppet automatically uses the latest version for your current product_version. If you also don't specify a product_version, Puppet will detect the version of Postgres running and use this to determine the product_version. There is, however, one issue with the detection. On an initial run Puppet canot determine what the Postgres version is. In that case, the pg_secured::ensure_stig defined type will skip applying the STIG and wait until (hopefully) the next run the version of Postgres for specified database is available.
When you want to skip certain controls, you can use the skip_list.
pg_secured::ensure_stig { 'DBNAME':
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'log_file_destination_directory_is_set_correctly',
'filename_pattern_for_log_files_is_set_correctly',
]
}
When you have multiple database on your system and want to use the same database version and STIG document version, you can do this:
pg_secured::Ensure_stig {
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'alter_database_link_action_audit_is_enabled',
'alter_role_action_audit_is_enabled',
]
}
pg_secured::ensure_stig {'DB1':}
pg_secured::ensure_stig {'DB2':}
See the file "LICENSE" for the full license governing this code.
Parameters
The following parameters are available in the pg_secured::ensure_stig defined type:
title
The database to apply the control to. The CIS benchmark need an database to apply the controls to. Here is a simple example:
pg_secured { 'DB':}
In this example, the string DB is the database to apply the controls to.
product_version
Data type: Optional[String[1]]
The database version of the CIS benchmark you want to apply.
Although not very logical, you can apply an older (or newer) database version to your database.
If you also don't specify a product_version, Puppet will detect the version of Postgres running and use this to determine the product_version. There is, however, one issue with the detection. On an initial run Puppet canot determine what the Postgres version is. In that case, the pg_secured defined type will skip applying the CIS benchmark and wait until (hopefully) the next run the version of Postgres for specified database is available.
Default value: pg_secured::default_product_version($title)
doc_version
Data type: Optional[String[1]]
The version of the CIS benchmark you want to apply to your database.
When you don't specify the doc_version, puppet automatically uses the latest version for your current product_version.
Default value: pg_secured::default_doc_version($product_version, 'cis')
all_controls
This is an internal parameter. This is the Hash containing all paragraphs from the selected CIS benchmark.
skip_list
Data type: Array
This is the list of controls that you want to skip.
By default this vale is empty, meaning pg_secured will apply ALL controls. You must specifiy the name of the control. Here is an example on how to do this:
pg_secured { 'MYDB':
product_version => 'pg13',
doc_version => 'V1.0.0',
skip_list => [
'alter_database_link_action_audit_is_enabled',
'alter_role_action_audit_is_enabled',
]
}
Default value: []
pg_secured::internal::ensure_extension
See the file "LICENSE" for the full license governing this code.
++--++ --++--
Parameters
The following parameters are available in the pg_secured::internal::ensure_extension defined type:
ensure_libraries
Data type: String[1]
pg_secured::internal::set_parameter
See the file "LICENSE" for the full license governing this code.
++--++ --++--
Parameters
The following parameters are available in the pg_secured::internal::set_parameter defined type:
value
Data type: Any
Resource types
pg_secured_setup
Start the setup for applying postgres secure classes.
Properties
The following properties are available in the pg_secured_setup type.
ensure
Valid values: present, absent
The basic property that the resource should be in.
Default value: present
Parameters
The following parameters are available in the pg_secured_setup type.
provider
The specific backend to use for this pg_secured_setup resource. You will seldom need to specify this --- Puppet will
usually discover the appropriate provider for your platform.
Functions
pg_secured::default_doc_version
Type: Ruby 4.x API
See the file "LICENSE" for the full license governing this code.
This function determins the CIS default doc_version based on the product_version.It uses the following algorithmn:
- Use the specified version for this database
- Use a generic specified version for all databases
- Use the latest version available for thos product_version
pg_secured::default_doc_version(Optional[String[1]] $product_version, Enum['cis','stig'] $type)
See the file "LICENSE" for the full license governing this code.
This function determins the CIS default doc_version based on the product_version.It uses the following algorithmn:
- Use the specified version for this database
- Use a generic specified version for all databases
- Use the latest version available for thos product_version
Returns: Any
product_version
Data type: Optional[String[1]]
type
Data type: Enum['cis','stig']
pg_secured::default_product_version
Type: Ruby 4.x API
See the file "LICENSE" for the full license governing this code.
This function determins the CIS product_version to use for this call. It uses the following algorithmn:
- Use te specified version for this database
- Use a generic specified version for all databases
- Check if fact pg_version is set. If not, return an undef
- Use the version based on the version of the database
pg_secured::default_product_version(String[1] $db)
See the file "LICENSE" for the full license governing this code.
This function determins the CIS product_version to use for this call. It uses the following algorithmn:
- Use te specified version for this database
- Use a generic specified version for all databases
- Check if fact pg_version is set. If not, return an undef
- Use the version based on the version of the database
Returns: Any
db
Data type: String[1]
pg_secured::filter_controls
Type: Ruby 4.x API
See the file "LICENSE" for the full license governing this code.
Filter the list of controls based on the which database it will be applied to
pg_secured::filter_controls(String[1] $title, Hash[String[1], String[1]] $controls)
See the file "LICENSE" for the full license governing this code.
Filter the list of controls based on the which database it will be applied to
Returns: Any
title
Data type: String[1]
controls
Data type: Hash[String[1], String[1]]
pg_secured::lookup_setting
Type: Ruby 4.x API
See the file "LICENSE" for the full license governing this code.
This function uses its current scope te infer what CIS rule is called on what SID. Based on this information a hiera key is constructed. First we look up the most specfic key. Then we lookup the more global key. As an example the following puppet code:
define pg_secured::rules::r_1_2( Array $ignore = lookup_setting('ignore', []), ...
beeing called as: pg_secured::rules::r_1_2 { 'DB02':}
will result in a first lookup of the most specific key
pg_secured::rules::r_1_2::db02::ignore
when this key is not found, it will lookup the more global key beeing:
pg_secured::rules::r_1_2::ignore
If this is also not found, we return the specfied default value
pg_secured::lookup_setting(String $key, Any $default_value)
See the file "LICENSE" for the full license governing this code.
This function uses its current scope te infer what CIS rule is called on what SID. Based on this information a hiera key is constructed. First we look up the most specfic key. Then we lookup the more global key. As an example the following puppet code:
define pg_secured::rules::r_1_2( Array $ignore = lookup_setting('ignore', []), ...
beeing called as: pg_secured::rules::r_1_2 { 'DB02':}
will result in a first lookup of the most specific key
pg_secured::rules::r_1_2::db02::ignore
when this key is not found, it will lookup the more global key beeing:
pg_secured::rules::r_1_2::ignore
If this is also not found, we return the specfied default value
Returns: Any
key
Data type: String
default_value
Data type: Any
History
07-10-2021 Version 0.2.8
- [ensure_set_user_libraries] Fix rhel 8 issues
07-10-2021 Version 0.2.7
- [core] Fix Rhel 8 issues
16-09-2021 Version 0.2.6
- [data_cluster_initialized_successfully] Fix mode specification to octal.
08-09-2021 Version 0.2.5
- [docs] Include playground link and add REFERENCE.md
- [ensure_pg_permissions_libraries] Fix used path names
- [docs] Fix fix first steps documentation
02-06-2021 Version 0.2.4
- [backend_runtime_parameters_are_configured_correctly] Skip JIT parameters on pg versions 10 and lower
- [postgresql_audit_extension_pgaudit_is_enabled] Fix version for pg10
- [systemd_service_files_are_enabled] Fix hardcoded version
- [sudo_is_configured_correctly] Add newline to sudo file
- [ensure_extension] Only run when we know the version
- [core] Allow override on already existing config
02-06-2021 Version 0.2.3
- [pg_unsafe_authentication_methods] Fix when Postgres is not yet installed
28-05-2021 Version 0.2.2
- Update README.md
28-05-2021 Version 0.2.1
- Update README
28-05-2021 Version 0.2.0
- [core] Enabled controls for pg11 and pg10
- [core] Enabled some other controls in postgres 13
- [log_file_permissions_are_set_correctly] Fix file mode settings
- [set_user_extension_is_installed] Implement the installation of required libraries
- [use_pg_permission_extension_to_audit_object_permissions] Implement the installation of required libraries
- [sudo_is_configured_correctly] Initial implementation
- [login_via_host_tcp_ip_socket_is_configured_correctly] Initial implementation
- [core] Use resource_value for all parameter settings
- [cis] Add pg12 V1.0.0 data
- [excessive_function_privileges_are_revoked] Initial implementation
- [file_permissions_mask_is_correct] Initial implementation
- [postgresql_pg_wheel_group_membership_is_correct] Initial implementation
- [use_pg_permission_extension_to_audit_object_permissions] Initial implementation
- [set_user_extension_is_installed] Initial implementation
- [excessive_administrative_privileges_are_revoked] Initial implementation
- [facts/roles_with_excessive_admin_privs] Initial implementation
- [facts/pg_authorized_users] Initial implementation
- [core] CIS v1.0.0 for pg12 generated
- [systemd_service_files_are_enabled] More robust implementation
17-05-2021 Version 0.1.1
- [postgresql_audit_extension_pgaudit_is_enabled] Make it version dependant
- [data_cluster_initialized_successfully] Make it version dependant
10-05-2021 Version 0.1.0
- Initial release
Dependencies
- enterprisemodules/easy_type (>= 2.27.0 < 3.0.0)
- herculesteam-augeasproviders_core (>= 2.0.0 < 3.0.0)
- herculesteam-augeasproviders_postgresql (>= 3.0.0 < 4.0.0)
- enterprisemodules/pg_config (>= 0.4.0 < 1.0.0)
- puppet-archive (>= 5.0.0 < 6.0.0)
- puppet-epel (>= 3.0.0 < 4.0.0)
- puppetlabs-stdlib (>= 5.0.0 < 8.0.0)
Enterprise Modules License d.d. January 2018
This license (“License”) governs the terms and conditions under which pg_secured module (“the Software”)
is licensed by Enterprise Modules B.V, a limited liability company in the Netherlands, registered in
the Dutch Chamber of Commerce: 63689537 (“Licensor”), to the user of the Software (“Licensee”).
Article 1. Grant of license
1.1 Licensor hereby grants to Licensee the right to use the Software for its internal business
purposes.
1.2 The license granted in the previous paragraph is limited to the use on VirtualBox Virtual
machines. For further use a commercial license must be directly obtained from Licensor.
Article 2. License limitations
2.1 All right, title and interest to the Software, the accompanying documentation and all
modifications and extensions thereto rest and remain with Licensor. Licensee only has the
rights and permissions explicitly granted by this License or granted in writing otherwise.
Licensee shall not use, copy, modify, distribute or publish the Software in any other manner.
Nothing in this License is intended to, and shall not be construed to, transfer to Licensee any
rights in intellectual property developed by Licensor.
2.2 In particular, Licensee shall not:
a) provide copies of the Software to third parties, including to entities controlling,
controlled by or under common control with Licensee;
b) sublicense the Software or otherwise make available the Software to such third parties,
including by rental, Software-as-a-Service models or otherwise;
c) remove indications of Licensor as copyright holder of the Software or to remove or render
illegible any part thereof.
2.3 The Software comprises third-party open source software. The respective third-party rights
holders grant Licensee the rights indicated in the applicable open source licenses. These
licenses can be found in the documentation. The License does not apply to this open source
software, and nothing in this License shall be construed as a limitation of any right granted
under an open source license.
Article 3. Trademark
3.1 This License does not grant permission to use the trade names, trademarks, service marks, or
product names of the Licensor, except as required for reasonable and customary use in
describing the origin of the Software.
Article 4. Limitation of Liability
4.1 Licensor provides the Software on an "AS IS" basis, and expressly disclaims all conditions,
representations or warranties, express or implied, including without limitation any implied
warranties of merchantability, fitness for a particular purpose, and non-infringement of third
party rights regarding the Software. Licensor is solely responsible for determining the
appropriateness of using the Software and assume any risks associated arising out of or in
connection with the Software and this License.
4.2 Licensor shall not be liable for any damages, including consequential, special, punitive and/or
incidental damages or fines imposed by regulatory bodies, arising out of or in connection with
the Software and this License.
4.3 Licensee shall release, defend, indemnify and hold harmless Licensor from and against any and
all claims, damages and liability arising in connection with the Software, including from
claims, damages or liability from customers of Licensee.
Article 5. Miscellaneous
5.1 Licensor reserves the right to change any or all parts of this License without prior notice.
5.2 The law of the Netherlands governs this License and the terms and conditions therein.
5.3 Any disputes arising between Licensor and Licensee in connection with the License will be
settled by the competent courts in the Netherlands for the principal place of business of the
Licensor.