Puppet and Chef Security: Certificates, Keys, Secrets and Server Hardening

A configuration management server can push code to every machine it manages, so whoever controls its signing keys, certificates or admin accounts controls the fleet. Chef and Puppet both run agents as root or SYSTEM on thousands of nodes, and both authenticate those agents with private keys or certificates that are themselves non-human identities. This guide covers how each platform establishes node identity, which settings weaken it (autosigning, shared validator keys, disabled TLS verification), how to keep secrets out of catalogs and cookbooks, and how to harden and monitor the servers. It is for platform engineers, infrastructure security teams and auditors running open source or commercial editions. Platforms are listed alphabetically (Chef, then Puppet) wherever both appear; order is not a ranking. Puppet behaviour is described from the OpenVox documentation, the community open source implementation of Puppet, and applies to Puppet 8 compatible servers; confirm details against your own edition's documentation.

This is an independent guide from NHI Mgmt Group, based on Chef's public documentation and Puppet's public documentation as of November 2026. It is not sponsored or reviewed by Chef or Puppet. Product features change, so confirm settings against each vendor's current documentation.

Key takeaways

• Node keys and certificates are the trust root. Chef signs every API request with the node's client.pem key; Puppet authorises agents by the certname in a certificate issued by its CA. Protect, inventory and revoke them like any other machine credential.
• Never auto-approve identities blindly. Puppet's documentation says naive autosigning should never be used in production and that basic autosign.conf whitelisting is essentially insecure; on Chef, use the default validatorless bootstrap instead of a shared validation.pem.
• Catalogs and node objects are not secret stores. Puppet's Sensitive type redacts values from logs and reports but they remain plain text in the catalog; Chef node attributes are readable through the server API. Fetch secrets at run time from a secrets manager.
• Server admin equals fleet root. Chef organisation admins, Puppet CA administrators and anyone who can merge to the control repository can execute code everywhere (MITRE ATT&CK T1072 Software Deployment Tools).
• Check lifecycle dates now. Progress Chef lists Chef Infra Server 15.x as deprecated with end of life on 30 November 2026 and Chef 360 Platform as the replacement, so self-hosted Chef servers need a decision this month.

How identity and access work in Chef and Puppet

Chef

Chef Infra Server uses public key authentication. Chef Infra Client keeps its private key at /etc/chef/client.pem and Chef Workstation users keep theirs in ~/.chef; the server stores only the public keys. Every request carries a set of signed HTTP headers, and the server verifies the signature with the stored public key. Authorisation is per organisation, which is the top-level role-based access control entity, with default groups admins, billing_admins, clients and users. The documentation describes the clients group as the non-human actors, nearly always Chef Infra Client, that read from and write to the server.

New nodes register in one of two ways. In the legacy flow the node uses the shared chef-validator key at /etc/chef/validation.pem on its first run to register and receive its own key; the documentation says to delete validation.pem after the first successful run. Validatorless bootstrapping, now the default and the recommended method, generates a key for each node and transfers it during bootstrap, so no shared registration key exists.

Puppet

Puppet uses an internal certificate authority. Each agent generates a key pair and submits a certificate signing request (CSR) under its certname; by default an administrator must sign it with puppetserver ca sign. Puppet Server then authorises every HTTP request against rules in auth.conf, matching on path, method and the authenticated certname or certificate extensions. A catalog rule typically uses a backreference such as $1 so that a node can only fetch its own catalog. The default auth.conf authorises the puppetserver ca command line tool through any certificate carrying the pp_cli_auth extension.

Admin roles and privileged access

• Chef organisation admins: the admins group has administrative rights to all objects in an organisation. Keep it small, review it quarterly, and use separate organisations for environments that should not trust each other. Server-wide administration through chef-server-ctl needs root on the server and should be restricted to a break-glass group.
• Chef workstation keys: a user key in ~/.chef can upload cookbooks that every node will run. Store workstation keys on managed devices, rotate them when people leave, and prefer pipeline uploads from a protected CI identity over personal laptops.
• Puppet CA administrators: anyone with a certificate carrying pp_cli_auth, or write access to ca.conf and auth.conf, can sign or revoke node identities. The ca.conf documentation tells administrators to always restrict access to that file.
• Control repository and code deployment: on both platforms the cookbook or module repository is the real admin console. Require reviewed merges, signed commits where your Git platform supports them, and protected branches for production environments. See the Infrastructure as Code Security Guide.
• Commercial consoles: Chef Automate and Puppet Enterprise add web consoles with their own role-based access control and API tokens. Connect them to your identity provider with MFA and include their tokens in the same review as server keys.

Certificates and node enrolment

Puppet autosigning options

A policy executable receives the certname as its only argument and the PEM CSR on standard input, and approves by exiting 0. Strong designs embed a per-node pre-shared key or a cloud instance identifier in CSR attributes (for example challengePassword, OID 1.2.840.113549.1.9.7) at provisioning time and verify it against the provisioning system or cloud API. Add timeouts, because the server waits for the script. To switch autosigning off completely, set autosign = false in the [server] section of puppet.conf.

Other CA settings: in ca.conf, allow-subject-alt-names and allow-authorization-extensions are false by default for security reasons; leave them off unless a specific server certificate needs them. allow-auto-renewal is false by default; when enabled, agents receive certificates with the auto-renewal-cert-ttl lifetime (60 days in the packaged ca.conf) instead of ca_ttl, which defaults to 5 years. Shorter lifetimes with automatic renewal reduce the value of a stolen agent key. In auth.conf, never set allow-header-cert-info to true unless TLS terminates on a proxy that no untrusted client can bypass; the documentation calls it very insecure because identity then comes from request headers.

Chef enrolment and TLS

• Validatorless bootstrap: keep the default and remove any validation.pem left on images, in bootstrap scripts or in object storage. A leaked validator key lets anyone register a node in the organisation (MITRE ATT&CK T1552.004 Private Keys).
• local_key_generation: defaults to true in client.rb, so the node creates its own key pair and sends only the public key. Leave it on.
• TLS verification: ssl_verify_mode defaults to :verify_peer, which also covers S3 and HTTPS remote_file downloads. Never set :verify_none in production. Replace the self-signed Nginx certificate on Chef Infra Server with one from your CA using nginx['ssl_certificate'] and nginx['ssl_certificate_key'] in chef-server.rb, and restrict ssl_protocols.
• trusted_certs: Chef trusts every certificate placed in /etc/chef/trusted_certs or ~/.chef/trusted_certs, including self-signed ones. Manage the directory with the chef_client_trusted_certificate resource and verify fetched certificates by SHA-256 fingerprint after knife ssl fetch.
• Mutual TLS: ssl_client_cert and ssl_client_key in client.rb enable mutual certificate validation where the server requires it.

See the Machine Identity, PKI and Certificate Lifecycle Guide and the Certificate Revocation Guide for lifecycle practice that applies to both CAs.

Integrations, API tokens and service accounts

Configuration management needs secrets: database passwords, API keys, TLS private keys. Where they live decides who can read them.

• Prefer run-time retrieval: a secret fetched by the node from a secrets manager, using its own identity, never appears in Git, the server database or reports. See the Secrets Management Guide and the HashiCorp Vault Guide.
• Catalogs, reports and PuppetDB: anything compiled into a catalog can be stored by reporting and query services. Restrict who can query them and keep secrets out of them.
• Integration identities: CI pipelines that upload cookbooks or deploy Puppet code, inventory sync jobs and monitoring tools all hold server credentials. Give each its own key or certificate with the narrowest group membership, record an owner, and rotate on a schedule. See the CI/CD Pipeline Identity Security Guide.
• Keys in code: scan cookbook and module repositories for private keys and passwords (ATT&CK T1552.001 Credentials In Files); the secret for encrypted data bags must never sit in the same repository.

Logging and detection

Forward these logs to your SIEM and alert on: a certificate signed outside the policy executable, a new member of a Chef admins group, auth.conf containing allow-unauthenticated for non-default paths, cookbook or module uploads from identities other than the release pipeline, and spikes of authentication failures.

Metrics:

• Percentage of nodes enrolled through validatorless bootstrap or policy-based autosigning (target 100%).
• Count of validation.pem files found on images, buckets or repositories (target 0).
• Number of human accounts in Chef admins groups and Puppet CA admin roles, reviewed each quarter.
• Percentage of secrets delivered by run-time lookup rather than stored in data bags or Hiera.
• Median agent certificate lifetime and percentage of decommissioned nodes revoked within 24 hours.

Hardening baseline

1. Lifecycle first: check versions against vendor support pages. Chef's version page lists Chef Infra Client 19.x as the current LTS, 18.x deprecated until 31 August 2027, and Chef Infra Server 15.x reaching end of life on 30 November 2026. Plan a migration or a supported alternative before relying on further fixes.
2. Isolate the servers: place Chef Infra Server and Puppet Server on a management network, allow agents only the server ports, and allow administrative access only from bastion hosts. Treat them as tier-zero assets like domain controllers.
3. Lock down enrolment: validatorless bootstrap on Chef; autosign = false or a policy executable on Puppet. Remove naive and glob whitelists.
4. Restrict administration: minimum members in admins groups and pp_cli_auth certificates, file permissions on chef-server.rb, ca.conf, auth.conf and the CA directory limited to root and the service user.
5. Enforce TLS: CA-issued server certificates, :verify_peer on clients, modern ssl_protocols, short agent certificate lifetimes with auto-renewal where available, and CRLs kept current.
6. Move secrets out: migrate data bag and Hiera secrets to run-time lookups; rotate any secret that has ever been committed.
7. Protect the code path: reviewed merges, CI-only uploads, dependency pinning for community cookbooks and modules, and test environments before production. See the Ansible and AWX Security Guide for the equivalent controls on push-based tooling.
8. Back up and test restore: CA keys, server databases and configuration, encrypted and access-controlled. A restore test proves you can rebuild trust after compromise.

Testing and rollback: make enrolment and TLS changes in a staging organisation or environment first, enrol a pilot ring of nodes, and keep the previous puppet.conf, auth.conf or client.rb under version control so a single setting can be reverted. Never roll back by re-enabling naive autosigning or :verify_none.

Small versus large estates: a few dozen static servers can rely on manual Puppet signing or validatorless Chef bootstrap from a controlled workstation. Large or auto scaling estates need policy-based autosigning backed by cloud instance identity, run-time secret retrieval, and separate organisations or compile servers per trust zone.

Common misconfigurations

• Autosigning left permissive: autosign = true or a broad domain glob in autosign.conf lets an attacker on the network enrol a fake node and receive catalogs with whatever secrets they contain.
• Shared validator key baked into images: validation.pem copied into AMIs, container images or bootstrap scripts lets anyone register nodes long after the image was built.
• TLS verification disabled to fix a certificate error: :verify_none on Chef clients, or adding an unverified certificate to trusted_certs, opens agents to impersonation of the server.
• Secrets in catalogs and attributes: relying on Sensitive or node attributes for passwords, then exposing reports, PuppetDB queries or the Chef API to wide audiences.
• Decommissioned nodes never revoked: Puppet certificates and Chef client keys that outlive their machines are valid credentials for anyone who recovers the disk or a backup.
• Running past end of life: keeping a self-hosted server after its vendor end-of-life date leaves the system that controls the whole fleet without security fixes.

Framework mapping

Practitioner checklist

• Confirm Chef and Puppet component versions against vendor lifecycle pages, and plan for Chef Infra Server 15.x end of life on 30 November 2026.
• Set Puppet autosign = false or a policy executable that verifies a pre-shared key or cloud identity, with timeouts.
• Use validatorless bootstrap for Chef and remove every validation.pem from images, scripts and storage.
• Keep ssl_verify_mode at :verify_peer, replace self-signed server certificates and manage trusted_certs as code.
• Minimise Chef admins group members and pp_cli_auth certificate holders and review them quarterly.
• Restrict file access to chef-server.rb, ca.conf, auth.conf and the CA key directory to root and the service user.
• Move secrets from data bags, Hiera and node attributes to run-time retrieval from a secrets manager.
• Revoke certificates and delete client keys as part of node decommissioning.
• Upload cookbooks and deploy modules only from a protected pipeline identity after reviewed merges.
• Forward server access, CA and change logs to the SIEM with alerts on enrolment, privilege and code changes.

Standards and references

• Progress Chef: Chef Infra Client security
• Progress Chef: Chef Infra Server security
• Progress Chef: Supported versions
• OpenVox: SSL configuration, autosigning certificate requests
• OpenVox: Server configuration files, auth.conf
• OpenVox: Server configuration files, ca.conf
• MITRE ATT&CK: Software Deployment Tools
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Ansible and AWX Security Guide · Secrets Management Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Infrastructure as Code Security Guide · NIST SP 800-128 Security-Focused Configuration Management Guide