ra2 studio - Fotolia
Configuration management tools, such as Puppet, Ansible and Chef, gather sensitive information about countless enterprise devices. If an unauthorized system or user intercepts that information, enterprises are subjected to risk -- and severe disruption.
To avoid this, management servers must validate the authenticity of each endpoint these tools manage, while each endpoint ensures it sends sensitive details to a valid management server. Modern networks typically use digital certificates for system authentication.
Let's take a closer look at certificate authority mechanisms for configuration management tools.
To operate, networks exchange packets of data between various devices or nodes. Network security focuses on validation -- ensuring that the sending and receiving nodes are the intended physical devices. This validation process is called authentication. Users are typically authenticated to servers on the network through credentials, such as usernames and passwords.
But user authentication is only part of the process. Servers must often authenticate themselves to the client systems that use their resources, while many client systems must also provide adequate authentication to the servers or other client systems that communicate over the network. Without this authentication, there is no way to determine whether the particular server or client system is trusted and legitimate.
The primary means of system-to-system authentication in modern networks is the digital certificate -- sometimes just referred to as a certificate. This is a special file that contains information, including the identity and public encryption key of an entity such as a person, business or system. A certificate authority (CA) then checks and validates that information. If the CA verifies the entity's identity and public encryption key, the information is then encrypted with the CA's private key to create a digitally signed certificate.
The certificate authority server sends a signed certificate to endpoints to use as the basis for Secure Sockets Layer (SSL) encryption between the server and the client, with confidence that the certificate represents the intended node. The key is typically used to create a temporary and disposable symmetric key that enables data encryption throughout the entire session. Even if the data is intercepted, it cannot be read or decrypted.
Configuration management platforms often integrate with a CA to maintain and exchange certificates with the client systems they manage. Thus, those client systems use certificates to ensure they exchange configuration changes or management information with an authentic management server.
CA tasks in systems management
Tools commonly involved in systems configuration and management -- again, such as Puppet, Ansible and Chef -- will include a certificate authority server as part of their functionality. For example, Puppet uses HTTPS for network communication, as well as X.509-compliant certificates. The highly automated certificate authority server enables the platform to manage its own certificates and maintain secure network communication with the devices under management.
The actual number of tasks that an IT administrator can perform with a CA server is limited, but those tasks are vital to configure and secure the management environment.
First, a CA server can regenerate certificates if a certificate authority becomes damaged or compromised. Administrators can typically log into the tool's console and run a straightforward command string to initiate the new certificates. A Puppet administrator, for example, can log into the master CA server as root and run a Puppet Infrastructure command line such as:
puppet infrastructure run regenerate_agent_certificate agent=<AGENT_HOSTNAME> caserver=<CA_SERVER_HOSTNAME>
By comparison, Ansible's openssl_certificate module uses a series of commands that delineate paths to critical locations. As an example, the sequence to generate an OpenSSL certificate signed with the CA might look like:
- name: Generate a CA-signed OpenSSL certificate openssl_certificate: path: <path where the generated certificate should be created or is located> csr_path: <path to the Certificate Signing Request that generates the certificate> ownca_path: <path to the CA> ownca_privatekey_path: <path to the CA private key> provider: ownca (the proper option to note what is generating the certificate)
Second, systems management tools enable administrators to set up an independent, third-party certificate authority, such as Verisign. This can be helpful when the enterprise wants to use a public CA, rather than the tool's own CA. The actual process to configure an independent CA varies between tools and involves numerous steps, so follow the tool's documentation.
For Puppet Enterprise, the process typically involves copying sensitive data -- including the certificate authority, certificate request and private key information -- to wherever the admin installs the CA master. Install Puppet Enterprise, adding the signing_ca parameter to the pe.conf file. The signing_ca parameter must include key value pairs for bundle, crl_chain and private_key. These details provide the installation with path information for important certificate authority data. After installation, create a certificate, using OpenSSL tools installed with Puppet, to check that the CA works.
Third, administrators can create a custom or self-signed certificate. A self-signed SSL certificate is signed by the same entity that it is intended to identify, and with its own private key. Some organizations opt to self-sign if internal CA safeguards are in place. However, self-signing is generally discouraged because the certificates are not trusted by other applications or OSes, might use weak hash or cipher technologies, and cannot be used by the broader public key infrastructure (PKI).
As an example, Ansible's openssl_certificate module might use the following sequence to generate an OpenSSL certificate self-signed with the CA:
- name: Self-sign a CSR and create a certificate openssl_certificate: path: <path where the generated certificate should be created or is located)> privatekey_path: <path to the location of the private key> privatekey_passphrase: <the private key password> csr_path: <path to the Certificate Signing Request that generates the certificate> provider: selfsigned (the proper option to note what is generating the certificate)
Fourth, administrators can typically implement configuration changes to the CA host master. As an example, an admin can use the Chef Infra Server to tune the Nginx service and optimize the use of SSL certificates. This can include stipulating specific values for the SSL certificate used to encrypt communication over HTTPS; selecting the preferred ciphers for encryption, such as AES256 with ECDHE; enabling or disabling Transport Layer Security (TLS); and setting the preferred protocols, including TLS 1.0, TLS 1.1, and TLS 1.2.
Secure the systems management CAs
The certificate authority must be a trusted resource in the enterprise. Although the scope of a security breach is limited in a systems management environment, the implications for sensitive data loss and business disruption are serious. A compromised CA means compromised security, as there is no way to ensure the authenticity of digital certificates. Given the importance of certificates and security in systems management environments, make it a top priority to set up and protect the certificate authority server for Puppet, Ansible, Chef and similar tools. Include any access to CA server deployment, setup and configuration in security alerts and auditing processes to preserve CA integrity.