PCI Migration from PE

Our original PCI implementation was build on Puppet Enterprise (PE). We have since found the Open Source versions of Puppet and Foreman to be a superior combination for us. This page describes how to migrate a running host from PE to the newer system.

Differences

“Mostly in one” architecture

The new pcibuild.oit.ncsu.edu host includes Foreman (GUI and ENC), Puppet, and the TFTP smart proxy needed to manage PXE boots. The Puppet Certificate Authority will remain on pci100pem.unity.ncsu.edu so that existing clients will not need to re-register. When we decommission the Puppet Enterprise software, we will transfer the private key for pci100pem.unity.ncsu.edu to an open source Puppet CA. Only RENV auth will be implemented You can currently authenticate to the console with almost all of the environments available on campus. This was fine when bld100frm was our only foreman server and we were testing many scenarios, but the new system is meant exclusively for PCI.

The line between PCI and ERP systems is currently a little fuzzy, as the security requirements are similar and currently the same build system is used for both environments. Since the build system is in place, staff involved with ERP systems have functioning RENV accounts. No shell access to Server OS On bld100frm, it is necessary to have shell access in order to manage the PCI puppet environment. The requirements fall into two general areas.

Some staff use the servers’ shell to promote new code from github onto the puppet server (the puppet code deploy production command). In the version of Puppet Enterprise that we originally installed, this was the best way to perform this function. In later upgrades, puppet created a “code manager” subsystem that allows these deploy commands to be run from a suitably secured workstation (https://github.ncsu.edu/pcipuppet/pcipem_control/wiki/Installing-Code-Manager-and-puppet-code) With code manager, shell access to the PEM is no longer required.

The second need for shell access was to revoke a host’s certificate in order to re-install that host (the puppet cert clean $fqdn command). Re-installing a host is a normal part of the life-cycle of a machine, and this needs to be administered by every group with hosts in the system.

Puppet enterprise has no published method to do this other than with shell access,/ R10K webhooks replace puppet code deploy In place of manually using puppet code deploy, the new system uses a “webhook” such that when changes are made to github, it informs the Puppet ecosystem which can then automatically incorporate the changes. Easier, more secure, and just as auditable, as github logs who pushed exactly what changes.

Certificates

While we are running both PE and the new pcibuild.oit environments, Certificate Requests will still need to be hand signed using the PE GUI on https://pci100pem.unity.ncsu.edu

When we decommission PE, the CA will mobe to pcibuild.oit and certificates

Organization model for RBAC

Our Role Based Access Control (RBAC) is currently based on creating big whole organization host groups, and using human discretion to ensure that hosts are properly classified and managed.

By switching to Organizations to manage access control and permissions, we immediately gain some ease of use and security benefits. In a nutshell, all objects, including hosts, are more or less invisible to those outside of the organization with which they are associated.

Technical details are in their own document “Managing by Organizations Model”

Edit me