Configure security settings

Configure these security settings to ensure your Puppet Enterprise (PE) environment is secure.

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, only version 1.2 and 1.3 of the Transport Layer Security (TLS) protocol are enabled. If necessary, you can manually 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.
puppet_enterprise::profile::console::ldap_sync_period_seconds
An integer specifying, in seconds, the interval at which LDAP group membership associations are synchronized.
The default value is 1800 (30 minutes).
This synchronization refreshes group membership for every LDAP user in the system, regardless of the last time the user logged in. If a user is no longer present in LDAP or has no group bindings, then all user-group associations are removed from the user and all of the user's known tokens are revoked; however, the user object itself is not removed. If a user is present in LDAP and has group bindings, this synchronization updates the user's group membership, user name, and descriptions (if this data had changed).
To disable automatic synchronization, set the value to 0 or a negative integer. When disabled, user names, descriptions, and group membership only refresh when users log in.
When enabled, various entries are recorded to console-services.log that indicate whether the service is enabled and when each synchronization event has completed. If you enabled SAML after LDAP, these logs can show tokens being revoked in associated with past LDAP users if those users haven't logged in through SAML.

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

Security warnings due to missing HSTS response headers

Puppet Enterprise (PE) does not implement HTTP Strict Transport Security (HSTS) in response headers because the ports used by PE are not open to the internet. However, your security system might flag HSTS response headers as missing and deliver a warning that PE service ports are vulnerable. If this happens, consider adjusting your security software configuration to add an exception for PE ports.

About HSTS

HSTS is designed to protect sites against man-in-the-middle attacks. When HSTS is enabled, an HSTS response header forces user agents and browsers to use HTTPS for loading site content.

Why HSTS is not required for PE

HSTS is not required for PE because none of the ports used by PE are open to the internet.

Adding exceptions for PE ports

If your security system flags a vulnerability due to missing HSTS headers in PE service ports, consider adjusting your security software configuration to add an exception for PE ports.

Typically, an exception is required only for port 443, which is used for PE console services. Port 443 is available to PE users, only within an internal network. To prevent attacks, the console service allows only secure, domain-bound cookies and HTTPS traffic. Mixed content (a combination of HTTP and HTTPS content) is not allowed.

To learn more about PE ports, see Firewall configuration.