PCI Migration from PE
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