Configure security settings

Configure cipher suites

Regulatory compliance or other security requirements might require you to change the cipher suites your SSL-enabled PE services use to communicate with other PE components.

Before you begin: Make sure you're using Compatible ciphers.

To add or remove cipher suites for different service types, use Hiera to modify the following parameters:

puppet_enterprise::ssl_cipher_suites

List IANA-formatted ciphers for all PE Java-based services, which includes PuppetDB, Puppet Server, console services, and the orchestrator.

Format: Array of strings

Example:

puppet_enterprise::ssl_cipher_suites:
- 'TLS_AES_256_GCM_SHA384'
- 'TLS_AES_128_GCM_SHA256'
- 'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256'
- 'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'

puppet_enterprise::ssl_cipher_suites_non_java

List OpenSSL-formatted ciphers for all PE non-Java services, which includes Bolt Server, ACE Server, and PostgreSQL.

Format: Array of strings

Example:

puppet_enterprise::ssl_cipher_suites_non_java:
- 'ECDHE-ECDSA-AES128-GCM-SHA256'
- 'ECDHE-ECDSA-AES256-GCM-SHA384'
- 'ECDHE-RSA-AES128-GCM-SHA256'
- 'ECDHE-RSA-AES256-GCM-SHA384'

puppet_enterprise::ssl_cipher_suites_browser

List OpenSSL-formatted ciphers for NGINX. These ciphers are accepted by the PE console in the browser.

Format: Array of strings

Example:

puppet_enterprise::ssl_cipher_suites_browser:
- 'TLS_CHACHA20_POLY1305_SHA256'
- 'ECDHE-ECDSA-CHACHA20-POLY1305'
- 'ECDHE-RSA-CHACHA20-POLY1305'
- 'ECDHE-ECDSA-AES128-GCM-SHA256'

Configure SSL protocols

You can change what SSL protocols your Puppet Enterprise (PE) infrastructure uses.

Where to configure: In Hiera data files.; In the PE console on the PE Infrastructure node group's Configuration data tab.

Parameter

puppet_enterprise::master::puppetserver::ssl_protocols

Format

Array of strings representing SSL protocols.

Example

This declaration enables TSLv1.3 and TSLv1.2:

puppet_enterprise::master::puppetserver::ssl_protocols: ["TLSv1.3", "TLSv1.2"]

Default

["TLSv1.3", "TLSv1.2"]

Note: To comply with security regulations, PE 2019.8.9 and later use only version 1.2 and 1.3 of the Transport Layer Security (TLS) protocol. If necessary, you can enable TLSv1 and TSLv1.1.

Configure RBAC and token-based authentication settings

You can configure RBAC and token-based authentication settings, such as setting the number of failed attempts a user has before they are locked out of the console or the amount of time tokens are valid.

RBAC and token authentication settings can be changed in the PE Infrastructure node group in the Puppet Enterprise (PE) console or in Hiera data. Settings include:

puppet_enterprise::profile::console::rbac_failed_attempts_lockout: An integer specifying how many failed login attempts are allowed on an account before the account is revoked.; Default: 10
puppet_enterprise::profile::console::rbac_password_reset_expiration: An integer representing the number of hours that password reset tokens are valid.; An administrator generates these token for users to reset their passwords.; Default: 24
puppet_enterprise::profile::console::rbac_session_timeout: An integer representing, in minutes, how long a user's session can last.; The session length is the same for node classification, RBAC, and the console.; Default: 60
puppet_enterprise::profile::console::rbac_token_auth_lifetime: A string representing the default authentication lifetime for a token.; The value is formatted as string consisting of a number followed by a suffix representing a unit of time: y (years), d (days), h (hours), m (minutes), or s (seconds).; Important: This value cannot exceed the rbac_token_maximum_lifetime.; Default: "1h" (one hour)
puppet_enterprise::profile::console::rbac_token_maximum_lifetime: A string representing the maximum allowable lifetime for all tokens.; The value is formatted as a string consisting of a number followed by a suffix representing a unit of time: y (years), d (days), h (hours), m (minutes), or s (seconds).; Default: 10y (10 years)
puppet_enterprise::profile::console::rbac_account_expiry_check_minutes: An integer specifying, in minutes, how often the application checks for idle user accounts.; Default: 60 minutes; Important: The rbac_account_expiry_check_minutes parameter is ignored if you do not also specify the rbac_account_expiry_days parameter.
puppet_enterprise::profile::console::rbac_account_expiry_days: An integer specifying, in days, the duration before an inactive user account expires.; The default value is undefined. To activate this feature, specify a positive integer of 1 or greater.; When non-superusers don't log into the console during the specified period, their user status changes to revoked. This also applies to new accounts – The inactivity timer starts once the account is created.

RBAC database configuration

Credential information for the RBAC service is stored in a PostgreSQL database. Configuration information for this database is in the rbac-database section of the config file.

For example:

rbac-database: {
  classname: org.postgresql.Driver
  subprotocol: postgresql
  subname: "//<PATH_TO_HOST>:5432/perbac"
  user: <USERNAME>
  password: <PASSWORD>
}

It contains these parameters:

classname

Used by the RBAC service for connecting to the database.

The value must be org.postgresql.Driver.

subprotocol

Used by the RBAC service for connecting to the database.

The value must always be postgresql.

subname

The JDBC connection path used by the RBAC service for connecting to the database.

The value is a string-formatted URI path consisting of the hostname and configured port for the PostgreSQL database along with perbac, such as

"//<PATH_TO_HOST>:5432/perbac"

perbac is the database the RBAC service uses to store credentials.

user

This is the username the RBAC service uses to connect to the PostgreSQL database.

password

This is the password the RBAC service uses to connect to the PostgreSQL database.

Configure the password algorithm

Puppet Enterprise (PE) uses SHA-256 as a default password algorithm. You can use Hiera or the PE console to change the algorithm to argon2id by editing or adding password algorithm parameters.

Before you begin: Before changing your password algorithm to argon2id, review the Argon2 specifications on password-hashing.net.

Restriction: If you have FIPS 140-2 enabled PE, use the default SHA-256 algorithm, because Argon2id isn’t available for FIPS-enabled systems.

puppet_enterprise::profile::console::password_algorithm: A string, either "SHA-256" or "ARGON2ID".; Always required.; Default: "SHA-256"
puppet_enterprise::profile::console::password_hash_output_size: An integer representing the desired hash output size in bytes.; Required for argon2id.; Default: 128 bytes
puppet_enterprise::profile::console::password_algorithm_parallelism: An integer representing the number of parallel computations that can be performed at once.; Required for argon2id.; Default: Twice the number of cores in your system.
puppet_enterprise::profile::console::password_algorithm_memory_in_kb: An integer representing the amount of memory, in KB, the algorithm consumes when running.; Required for argon2id.; No default value. We recommend initially setting this to 25% of your CPU memory.
puppet_enterprise::profile::console::number_of_iterations: An integer representing the number of times a password is hashed before it’s stored.; Always required, and we recommend updating this value when switching from SHA-256 to argon2id. The minimum recommended value for argon2id is 3 iterations.; Default: 500000 iterations.
puppet_enterprise::profile::console::password_salt_size_bytes: An integer representing the size, in bytes, of each generated salt.; Default: 128 bytes

Add a custom HSTS header to NGINX

An HTTP Strict Transport Security (HSTS) response header is a security header that blocks access to non-HTTPS content. This prevents the browser from being exploited by man-in-the-middle attacks.

You can't use self-signed certificates with HSTS headers. Therefore, if you want to enable an HSTS header, you must first add a custom certificate with a trusted CA to your Puppet Enterprise (PE) console, and then use a custom NGINX module to define and manage the header content.

Add a custom certificate as explained in Use a custom SSL certificate for the console.
Write a custom NGINX module for managing the headers that includes a headers.conf file.
Tip: Use the Beginner's guide to writing modules in the Puppet documentation to learn how to write custom modules.
For example, assume your custom module is called nginxcustom. The custom module's location is:
```
/etc/puppetlabs/code/environments/production/modules/nginxcustom
```
And it has the following structure:
```
├── files 
│       └── headers.conf 
└── manifests 
	└── init.pp
```

Define the HSTS response header content in a header.conf file, such as:

# cat files/headers.conf

#Custom headers 
add_header X-Frame-Options SAMEORIGIN always; 
add_header X-Content-Type-Options nosniff; 
add_header X-XSS-Protection '1; mode=block'; 
add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload;';

In manifests/init.pp, create a file resource that points to the custom module that manages your headers.conf file.

For example, this file resource points to the nginxcustom module:

# cat manifests/init.pp

 #File resource to create headers.conf
 class nginxcustom {
    file { '/etc/puppetlabs/nginx/headers.conf':
      ensure => file,
      group => 'root',
      owner => 'root',
      mode => '0644',
      source =>'puppet:///modules/nginxcustom/headers.conf',
     }
}

In manifests/init.pp, use pe_nginx::directive to include the headers.conf file in the proxy.conf configuration file. This allows the headers to appear in the NGINX configuration in PE. For example:

#Nginx directive to add include statement 
pe_nginx::directive { 'include custom headers': 
directive_ensure => 'present', 
target => '/etc/puppetlabs/nginx/conf.d/proxy.conf', 
directive_name => 'include', 
value => 'headers.conf', 
server_context => $::fqdn, } 
}

Run Puppet: puppet agent -t