Secure data

Data security involves the protection of your organization’s data and any input entered by users.

Secure data in motion

With PE, you can secure data in motion as it travels over a network or between locations. Network communications are based on HTTPS, which secures traffic with X.509 certificates. Certificates are used to verify the identity of users and protect sensitive data.

PE provides an internal certificate authority (CA) service that you can use to generate certificates. You can also use a custom CA. For an overview of certificate options, see Certificate Authority. For detailed information about certificates, see the following information:

• Regenerate the console certificate

  The certificate for the PE console expires every 824 days. Regenerate the console certificate when it is nearing expiration, or in the rare case that the certificate is corrupted and you're unable to access the console.

• Use a custom SSL certificate for the console

  The PE console uses a certificate signed by the built-in CA. Because this CA is specific to PE, web browsers don't know it or trust it, and you must add a security exception to access the console. For instructions, see Reaching the console. If the addition of a security exception is not acceptable for your organization, you can use a custom CA to create the console certificate.

• Configure SSL protocols

  To comply with security regulations, TLSv1 and TLSv1.1 are disabled by default. Ensure that TLSv1.2 or v1.3 is enabled as described in Configure SSL protocols. In addition, follow these guidelines:

  • Ensure that cipher suites are configured appropriately for your organization's security model. See Configure cipher suites. Configure the order of cipher suites to prioritize stronger ciphers. Weaker cipher suites can be included for backward compatibility.
  • Securely manage TLS certificates across all PE services, ensuring the use of RSA keys with SHA-2 or stronger algorithms.

Secure data at rest

Securing data at rest involves protecting data on physical media, such as hard drives and solid-state drives, and on cloud storage. PE supports various methods for securing data at rest.

The PE infrastructure includes many file types, some of which are unique to Puppet products. If you are new to PE, review this list to learn about the file types:

• Puppetfile: A dependency file that can be configured to execute code and is managed in a control repository.

• Puppet code files (.pp): Puppet language files used to manage nodes. These files can be configured to execute code.

• Hiera file (.yaml): A file that contains hierarchical data for parameterized classes. This file does not contain executable code.

• Puppet task and plan files: Executable files that Orchestrator and Puppet Bolt use to manage nodes. These files can contain executable code.

• Embedded Ruby Templates (.erb): Templates that resemble plain text documents interspersed with tags containing Ruby code. ERB templates are computed when catalogs are compiled. The templates can contain code that directly affects the server the template is compiled on (Puppet primary or Puppet compile server) rather than the agent nodes.

• Embedded Puppet Templates (.epp): Templates that resemble a plain text document interspersed with tags containing Puppet code. EPP templates are computed when catalogs are compiled. The templates can contain code that directly affects the server the template is compiled on (Puppet primary or Puppet compile server) rather than the agent nodes.

• Base configuration files: Usually in the Human-Optimized Configuration Object Notation (HOCON) format, these files do not contain executable code.

• Certificate files: Access to these files is controlled through Linux file permissions. These files are used to encrypt network communications. The files are backed up by default.

• Secret key files generated by services: Access to these files is controlled through file system permissions. The files are stored on disk and are not included in the archives created by the Puppet backup process. If you want to back up these keys, you must do so manually, as described in Back up your infrastructure. In addition, you can rotate the inventory service secret key every 90 days to help protect the encrypted database entries against potential attackers. See Rotating the inventory service secret key. The secret key files are used to encrypt sensitive information in databases.

Puppet Enterprise compilation data and reports are stored in and accessed from a secure PostgreSQL database by using the PuppetDB service. You can configure the connection between PuppetDB and PostgreSQL with certificates or password authentication for SSL. Infrastructure node groups are used for database configuration. For information about configuring the PostgreSQL database host, SSL setting, and port, see Infrastructure node groups .

PuppetDB uses standard HTTPS. All HTTPS clients must supply valid, verifiable SSL client certificates. PuppetDB uses a secure service account to access the PostgreSQL database. You can configure allowlists to further restrict access to specific users. For instructions, see The PuppetDB configuration file(s).

Manage environments with a control repository

You can maintain Puppet code and data in different environments. For example, you might have a development environment, a testing environment, and a production environment. You manage environments by using a properly configured control repository, with each environment represented by a corresponding branch. You can use a Puppetfile in the control repository to manage environment content such as modules and configuration data.

Ensure that only trusted users can create branches in your control repository:

• Consider using continuous delivery pipelines to automate the process for creating branches.

• Consider implementing additional controls such as peer reviews and security gates.

• Consider using version-control system checks to reject commits containing unexpected code in your Puppetfile.

• Ensure code is written with the appropriate functionality that is required for files used by Code Manager (read, write, and execute).

• When reviewing pull or merge requests to your control repository, review any changes as an update to executable code rather than an update to static strings or text.

Guidelines for securing tokens and other sensitive data

Follow these guidelines:

• Do not hard-code passwords, tokens, or other authentication information in Puppetfiles, configuration files, or the control repository.

• Use a hardware security module (HSM) or key store to manage Puppet-related secrets.

• Leverage Puppet functions to secure and retrieve sensitive data:

  • Use the hiera-eyaml gem to secure sensitive data on disk.

  • Use the lookup_options feature to secure data in the catalog.

  • Use the node_encrypt module to secure cached catalog data.

  • Use EPP templates to secure sensitive data.

  • Write deferred functions to retrieve secrets.

Secure user input

Securing user input involves masking or hiding the content of input fields in a user interface to prevent unauthorized individuals from viewing sensitive information. The PE console uses standard industry practices to secure user input.