Puppet - non-root and sudo requirements

By default the SovLabs Puppet plugins (Enterprise and Open Source) rely on connecting to the Puppet infrastructure and the provisioned node using the root account over SSH. In many hardened environments SSH using root is not available. The following details the configuration of the SovLabs puppet module to allow use of non-root users with sudo if necessary.

Limitations

1. puppet.conf file, facter facts and hiera files cannot be written directly by a non-root user. Updates to these files are made using sudo commands detailed below.
2. Due to a VRA bug with empty fields, if you already have a SovLabs puppet configuration defined you will need to create a new one with the puppet.conf and facter file template being empty fields.

Required SovLabs Module Configuration

Puppet Master Configuration

Hiera Configuration

Disable creation of hiera configuration

Purge Node Script

Note this relies on a sudo rule to switch to pe-postgres directly as well as root, this is useful when using a dedicated DB server.

sudo puppet node purge {{Hostname}}.{{PrimaryDnsDomain}}
cd /tmp
sudo -u pe-postgres /opt/puppet/bin/psql --command="delete from certnames where name like '{{Hostname}}.{{PrimaryDnsDomain}}';" pe-puppetdb
sudo -u pe-postgres /opt/puppet/bin/psql --command="delete from reports where certname like '{{Hostname}}.{{PrimaryDnsDomain}}';" pe-puppetdb

Puppet Agent Configuration

A new SovLabs Puppet Agent Configuration needs to be created with the following updated settings

puppet.conf File content

facter file template

Install Script

curl -k https://{{SovLabsPuppet.puppetMasterHostname}}:{{SovLabsPuppet.puppetServerPort}}/packages/current/install.bash | sudo bash -s -- extension_requests:pp_role='{{ Puppet.RoleClass.Override | default: Puppet.RoleClass }}' extension_requests:pp_environment='{{ Puppet.CodeEnvironment }}' agent:environment='{{ Puppet.CodeEnvironment }}' --puppet-service-ensure stopped

sudo mkdir -p /etc/puppetlabs/facter/facts.d
echo -e "---\npuppet_role: {{ Puppet.RoleClass.Override | default: Puppet.RoleClass }}" | sudo tee -a /etc/puppetlabs/facter/facts.d/role.yaml

• This includes updates to allow for blueprint compatibility with the puppet vro plugin. 
• It prevents the service from starting to minimise number of initial runs.
• It adds trusted facts support for pp_role and pp_environment and relies on the corresponding custom properties.
• It adds non-trusted versions of these facts to a facter file using sudo commands (rather than the templated file option in the module)

Run Script

sudo -i puppet agent -t

Post Script

sudo -i puppet resource service puppet ensure=running enable=true

Pre-Remove Script

Only required when the VM is not being destroyed

sudo rpm -e puppet-agent; sudo rm -rf /etc/puppetlabs /opt/puppetlabs

sudo rules required on the Puppet Master and CA

    A standard local user with SUDO permissions to run the following commands:

• sudo puppet node deactivate {{Hostname}}.{{PrimaryDnsDomain}}
• sudo puppet node clean {{Hostname}}.{{PrimaryDnsDomain}}

sudo rules required on the PE Console server

    A standard local user with SUDO permissions to run the following commands if you want the node removed automatically.

• sudo service pe-memcached stop
• sudo service pe-memcached start
• sudo /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production node:del['{{Hostname}}.{{PrimaryDnsDomain}}']

sudo rules required on the Database server

    A standard local user with sudo to another user ( pe-postgres ) able to run the following:

• sudo -u pe-postgres /opt/puppet/bin/psql --command="delete from certnames where name like '{{Hostname}}.{{PrimaryDnsDomain}}';" pe-puppetdb
• sudo -u pe-postgres /opt/puppet/bin/psql --command="delete from reports where certname like '{{Hostname}}.{{PrimaryDnsDomain}}';" pe-puppetdb

Please note that the variables in the {{}} will be replaced with the FQDN of the host we are deleting from puppet.