How Puppet Works
Puppet provides the ability to define which software and configuration a system requires and then maintain a specified state after an initial setup.
You use a declarative Domain Specific Language (DSL) that is similar to Ruby to define configuration parameters for a specific environment or infrastructure. Puppet discovers information about a system by using a utility called Facter, which is installed when you install the Puppet software package. See Gathering Information About a System by Using Facter.
The Puppet master is the system that manages important configuration information for all of the nodes that it controls by using manifests. See Puppet Manifests.
The nodes that the master controls are those that have Puppet installed on them and are running the Puppet agent, which is a daemon. The configuration information that the agent collects about a node is sent to the Puppet master. The Puppet master then complies a catalog based on how the node should be configured. Each node uses that information to apply any necessary configuration updates to itself.
Puppet works by using a pull mode, where agents poll the master at regular intervals to retrieve site-specific and node-specific configurations. In this infrastructure, managed nodes run the Puppet agent application, typically as a background service. For more information, go to Overview of Puppet’s Architecture.
The following figure describes the Puppet master/agent topology in more detail.
About the Puppet Master
The Puppet master is a daemon that runs on a designated server and is the primary source of configuration data and authority for Puppet. The master provides instructions for all of the nodes that are part of the Puppet infrastructure. Because some aspects of component configuration depend on the configuration of other components, the server that is designated as the Puppet master is required to be aware of the system's entire configuration. Puppet restricts access to the master by having the master run as its own user and group. See Function of the Puppet User and Group.
-
Compiling the catalog for the agents
-
Transferring files from a file server
-
Sending reports to a central instance
The master is responsible for several actions, including the following:
Note - The master might also perform other actions that do not require root privileges.
About the Puppet Agent
The Puppet daemon that runs on a target system (or node) is known as the Puppet agent. The agent must have the appropriate privileges for the node on which it is enabled so that it can apply the configuration catalogs that it pulls from the Puppet master. The agent gains communication privileges from the master server by requesting an Secure Socket Layer (SSL) certificate the first time that it contacts the master. Subsequently, whenever the agent polls the master for configuration updates, it only receives updates if its certificate is valid.
The Puppet agent that runs on each of the target nodes must have the ability to modify most aspects of the system's configuration. This requirement enforces the state in which the master has indicated the agent should be. Because so much access to the system is required by the puppet agent, it is run as the root user or a user who is assigned the Puppet Management rights profile.
Note - Note that the master must also authenticate to the agents so that they do not inadvertently receive incorrect configuration information.
Function of the Puppet User and Group
The Puppet user and group are used for security purposes to ensure that a module only has access to the information that it requires from the master. The Puppet user and group also prevent the Puppet module from being exploited or compromised. The Puppet user performs tasks on the master and is a member of the Puppet group. This privileged user and group are automatically created and assigned to the master daemon when you enable the master SMF service instance during the setup process. See Getting Started With Puppet in Oracle Solaris.
-
Stores configuration manifests in the puppet manifests directory.
-
Accepts SSL certificates from agent.
-
Transfers files to agents.
-
Creates catalogs.
Through the Puppet user, the Puppet master performs the following tasks:
Puppet Encryption and Communication Methods
Puppet interfaces with the OpenSSL toolkit, which is based on SSL and the Transport Layer Security (TLS) cryptographic protocol. Puppet uses standard SSL/TLS encryption technology and standard SSL certificates for agent and master authentication and verification. Puppet also makes use of SSL/TLS to encrypt the traffic flow between server and agents. SHA-256 is the default hash that is used.
-
Authenticates any agent to the master
-
Authenticates the master on any agent
-
Prevents communication eavesdropping between master and agents
Puppet's encryption method does the following:
Puppet uses a TLS client-side X.509 certificate to perform mutual host authentication. By default, this information is stored in the /etc/puppet/ssl directory, which is defined in the puppet configuration file (puppet.conf). You can change the default location by using SMF commands, which would then be reflected in the site configuration file. Note that there are separate directories for keys, certificates, and signed requests, as well as those requests that are awaiting a signature. These directories exists on both the master and the agent.
Because Puppet uses its own certificate authority (CA), you do not need to use the system's default setting for CAs (/etc/certs/CA). When the master is initialized, it generates its own CA certificate and private key, initializes the Certificate Revocation List (CRL), then generates another certificate, called the server certificate. This certificate is used for SSL and TLS communications and is sent to the agent. During the master and agent exchange, the CA is stored in the /etc/puppet/ssl/ca/signed directory on the master and in the /etc/puppet/ssl/certs directory on the agent.