Managing SSH server security with Puppet

Edit: In an earlier edition, I credited the wrong newsletter as the source. My apologies to R.I.Pienaar!

In this past week’s DevCo Newsletter, I saw the Rebex SSH Check, which reminded me that I’ve locked down the SSH server security configuration at work, but not at home. Sounds like a good opportunity to blog about the process!

Now, I’m in security, but I’m not all that about the security settings. The names vary from descriptive to really obtuse, and there’s three keys that need managed: ciphers, MACs, and KexAlgorithms (that’s Key Exchange Algorithms, which is the name I’m more familiar with). The key to security is knowing when you don’t know, and seeking out that expertise. I am very thankful for Mozilla’s really great security guidelines, including an OpenSSH guide. There are sections for Modern and Intermediate security, depending on what is available for the systems you are securing. For me, these align with the Red Hat/CentOS EL7 (Modern) and EL6/5 (Intermediate) distros that I use.

The first step is making sure we have a tier in hiera for each OS/release we support, otherwise sshd could fail to restart when it encounters a cipher set name that is unknown to the openssh version in use. That could be bad, especially if we don’t have some form of iLO console to the nodes, though if we have puppet running on a regular basis or through mcollective, we *should* be able to recover. In any case, you definitely want to check run status of your nodes after this change to make sure you don’t discover a problem when you’re trying to troubleshoot some other problem.

I define my hierarchy in hiera itself using the puppet/hiera module, so here is the yaml for hiera to parse as well as the resulting hiera.yaml, the change is in bold:

# portion of hiera/puppet_role/puppet.yaml, which applies to the puppet master
  - 'clientcert/%%{::}{clientcert}'
  - 'puppet_role/%%{::}{puppet_role}'
  - 'osfamily-release/%%{::}{osfamily}-%%{::}{operatingsystemmajrelease}'
  - 'datacenter/%%{::}{datacenter}'
  - 'global'

# /etc/puppetlabs/puppet/hiera.yaml
# managed by puppet
- eyaml
- yaml

:logger: console

  - "clientcert/%{clientcert}"
  - "puppet_role/%{puppet_role}"
  - "osfamily-release/%{osfamily}-%{operatingsystemmajrelease}"
  - "datacenter/%{datacenter}"
  - global

  :datadir: "/etc/puppetlabs/puppet/environments/%{::environment}/hiera"
  :extension: yaml
  :pkcs7_private_key: "/etc/puppetlabs/puppet/keys/private_key.pkcs7.pem"
  :pkcs7_public_key: "/etc/puppetlabs/puppet/keys/public_key.pkcs7.pem"

  :datadir: "/etc/puppetlabs/puppet/environments/%{::environment}/hiera"

:merge_behavior: deeper

This change will need to be put in place on the master, the master service restarted, and no dissimilar configs exist in the wrong location before agents will see the changes we make below (I had a /etc/puppetlabs/code/hiera.yaml that slightly vared from /etc/puppetlabs/puppet.hiera.yaml and it kept winning out till I removed it and restarted pe-puppetserver). You can force the run now, or wait up to two full run cycles before verifying that all your agents see the changes.

The second step is to populate the two OS/release files with the specific sets you want to use. I use saz/ssh, which allows me to use the ssh::server::options parameter to free-hand some stanzas into /etc/sshd_config. These commands replicate my settings, again according to Modern for EL7 and Intermediate for EL6:

mkdir hiera/osfamily-release
cat > hiera/osfamily-release/RedHat-6.yaml << EOF
  'KexAlgorithms'            : 'diffie-hellman-group-exchange-sha256'
  'Ciphers'                  : 'aes256-ctr,aes192-ctr,aes128-ctr'
  'MACs'                     : 'hmac-sha2-512,hmac-sha2-256'

cat > hiera/osfamily-release/RedHat-7.yaml << EOF
  'KexAlgorithms'            : ',ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256'
  'Ciphers'                  : ',,,aes256-ctr,aes192-ctr,aes128-ctr'
  'MACs'                     : ',,,hmac-sha2-512,hmac-sha2-256,'

There’s one final step: merge settings. You may have noticed the merge_behavior setting in my hiera.yaml above, but that’s defunct. Now you must set the lookup options. I do this in my least specific hiera file, hiera/global.yaml:

    merge: deep
    merge: deep
    merge: deep

If you don’t add this, then you’ll only get the first ssh::server::options values found, even for sub-keys like Ciphers that were not set at the higher tier.

Once all of these changes are in place, your agents should get the new settings and restart sshd. Any new ssh connections to the affected servers will use the specified security sets and ONLY the specified security sets. Existing connections will persist until the server or client end the sessions. We can now use as a KexAlgorithm with an EL6 node, but we would fail to connect to an EL7 node as only diffie-hellman-group-exchange-sha256 is available. If we re-run the Rebex SSH Test, our Modern servers show all green now. Success!

Addendum: Peter Souter notified me on twitter about his mozilla_ssh_hardening module (GitHub only at this time) that enforces the Mozilla recommendations on Ubuntu 16.04, CentOS 7, and CentOS 6. You can use that module to replace some of the work above, as long as you do not require conflicting customizations. I still hope this articles helps you understand the workings of hiera merges and the need for vetted security configurations.

Puppet 5 has arrived!

If you missed the news this past week, the Puppet 5 Platform was released! Read the announcement and the release notes for some great details. Congratulations to everyone at Puppet for getting this new release out the door. I’m looking forward to diving in with it as soon as a Puppet Enterprise release is out, since I’ve converted even my home lab away from Puppet Opensource.

There are a few things I’ve learned from the announcement thread, slack, and my own experiences with it in the last few days. It’s still early, so I am sure this will get out of date quickly, but I hope it helps others in the short term.

  • Puppet 5 AIO provides Ruby 2.4.1, so your tests should use it as well – even if you’re not using AIO puppet, it’s still helpful for any puppet modules.
  • PuppetDB requires postgresql96, but it’s not a dependency on the puppetdb package, since you can install puppetdb and postgresql on different hosts. Version 4.x works with postgresql96, so upgrade that first, then puppet. Detail here.
  • Puppet 5 includes a vendored version of the semantic_puppet gem. In Puppet 4.7 and below, it had a dependency on the external semantic_puppet getm. The gem is used by metadata-json-lint, which is often part of a puppet rspec test setup. Check out the metadata-json-lint README installation section to see how to deal with this. If your tests run against ~> 4.0 then you’re probably okay.
  • There’s a new version of puppetlabs_spec_helper that apparnetly has some issues with spec fixtures and symlinks (from slack, nothing to quote). I haven’t hit this myself, it might already be fixed, but something to be aware of if you have symlink-related issues during testing.
  • The combination of Puppet 5, rpsec-puppet, and the new puppetlabs_spec_helper are more stringent than Puppet 4 is. I’m not sure which of the three components specifically triggers it. I was testing for a resource that required another service, which was not part of the define I was testing (here). With puppet 4, this was fine, but with puppet 5, it started generating errors in this travis run. The fix is simple, through using a pre_condition to provide the service in the catalog, seen in this commit.
  • The first Puppet Enterprise release including Puppet 5 should be out sometime this fall.

That’s all I’ve run into so far. One last thing, here is a .travis.yml for testing component modules with both Puppet 4 and 5. You only need to update the matrix section, if you already have one, but I thought the whole thing might be helpful for those who don’t have tests yet.:

language: ruby
sudo: false
cache: bundler
  on_failure: always
  - master
bundler_args: --without development system_tests
before_install: rm Gemfile.lock || true
script: bundle exec rake test
  fast_finish: true
  - rvm: 2.3.1
  - rvm: 2.4.1

Where to store Puppet files and templates

I haven’t written a blog post in a while because I’ve been bogged down in work and life and not had much time in the lab. To make sure I don’t get too out of practice, I’m going to try writing some shorter tips and tricks articles. Let me know what you think.

A few days ago, someone asked a great question on the puppet-users mailing list about the location of config files in the roles/profile pattern. It’s a good question, and we can go deeper because it assumes the location of config files outside of that pattern, too. I’m going to explain where I keep my config files, and templates, in the various types of modules. There’s no single correct answer here, this is just a framework for me.

To start, let’s describe the types of modules. Component modules describe a single application/technology/thing and are designed to be consumed by end users. This is pretty much anything on the forge, such as puppet/hiera to manage a Hiera implementation or puppetlabs/apache to manage apache, vhosts, etc. There’s also a sub-type of these modules, Private Components. The line here is blurry, but think component modules that are not designed to go on the forge. This could be a module for a company’s internal application, very similar to a traditional component module, or an cluster of custom facts. Pretty much anything that’s not a Component module, or our final type: Profile modules. This last type is the collection of classes that make up your role/profile pattern implementation. They’re often simply called profile, but maybe there is more than one module if you have a lot of business groups using the puppet system. They differ from both types of component modules in that they contain the business logic of your implementation and are where you compose the collection of component modules that you use. I wrote an article on what goes in a role or profile, too.

In Component modules, the relevant configuration files or templates for the component are collected. In an ssh module, you’d have the ssh_config and sshd_config data; a sudo module would have sudoers and a template for sudoers.d/ files. Private Component modules vary quite a bit in functionality, but I treat them like regular component modules. If the module is for custom facts, there’s no need to put files or templates in it. If it’s for an internal app, the configuration files are stored in that module.

Your Role/Profile modules are a little more complicated. If you have a component module for apache, you likely have a profile class for apache, perhaps profile::apache or profile::somegroup::apache. The component module probably has its own file or template, but it may accept alternative files and templates. In this case, I create a sub-directory with the module subclass name, such as files/apache or templates/apache,  and add the file(s) there, e.g. templates/apache/vhosts.erb.

This is a pretty simple layout. The only real difficulty is when you have a private component modules and a profile for that component: do you put the file/template with the profile or the component module? I tend to lean toward the private component modules first, but I’ve done both.

I hope this helps and I’d love to hear of any other layouts you’ve had success with!

Using PowerCLI from the PowerShell Gallery

As you’ve surely seen, I love me some PowerCLI. So I was really happy when I saw that PowerCLI is now available on the PowerShell Gallery! What this means is that it is no longer a package you install on a server, it’s a set of modules you load from the gallery. When there’s a new version available, you just go get it. Because it’s now a bunch of files, not only do you not need to go to to find the download link, you can also install it without requiring administrative access! That’s pretty awesome when you’re a tenant on a system, and it’s pretty awesome for the owners of the system, too (no needing to punt all your PowerCLI users so the files aren’t locked during an upgrade). I fill both roles from time to time, so I’m really happy about this improvement! Read more about the change in this VMware PowerCLI Blog article by Kyle Ruddy.

The article will guide you through the setup just fine, so I won’t dwell on that part very much, but if you’ve followed my PowerShell Profile article, there’s one small change to make: uninstall the old version of PowerCLI, then edit your posh profiles with notepad $profile and remove whatever version of the profile you used. Leave anything else you have added and close it out. Remember to do this once in PowerShell and once in PowerShell ISE if you use both.

Now, install the modules as the blog article recommends.

Find-Module -Name VMware.PowerCLI
Install-Module -Name VMware.PowerCLI -Scope CurrentUser

That’s it, you’re done! The modules will automatically be loaded as needed. You should be able to start typing Connect-VIServer and see autocomplete working by tabbing it out in regular PowerShell, in the typeahead dialog in ISE, or however your PowerShell UI displays it. If you hit enter, the containing sub-modules are loaded immediately on-demand. You can import the entire suite of modules with Import-Module VMware.PowerCLI,in your profile if you’d like, but it adds about 10 seconds to PowerShell startup on my laptop for minimal gain vs on-demand loading. However, it does give you the look of the old PowerCLI desktop shortcut, if you so desire it.

If, for some reason, the module is not found by PowerShell after installation, check out the value of $env:PSModulePath. It should include %USERPROFILE%\Documents\WindowsPowerShell\Modules, e.g. `C:\Users\rnelson0\Documents\WindowsPowerShell\Modules`, which is where Install-Module installs the files to. If it does not, you’ll need to modify it. Mine was funky because I apparently edited the environment variable portion of my windows install, even though I don’t remember it.

To keep up with PowerCLI from the Gallery, just run Update-Module -Name VMware.PowerCLI once in a while. Easy peasy. Enjoy!

vRealize Orchestrator Workflows for Puppet Enterprise

Over the past three years, my Puppet for vSphere Admins series has meandered through a number of topics, mostly involved on the Puppet side and somewhat light on the vSphere side. That changed a bit with my article Make the Puppet vRealize Automation plugin work with vRealize Orchestrator, describing how to use the plugin’s built-in workflows to perform some actions on your VMs. However, you had to invoke the workflows one by one, and they only worked on existing VMs. That is not good enough for automation! Today, we will start to look at how to integrate the Puppet Enterprise plugin into other workflows to provide end-to-end lifecycle management for your VMs.

What is the lifecycle of a VM? This can vary quite a bit, so the lifecycle we will work with today is made to be generic enough for everyone to use, but flexible enough that everyone can expand on it. It consists of:

  • Provisioning
    • Updating ancillary systems prior to VM creation (IPAM, DNS, etc)
    • Deploying a Virtual Machine
    • Installing Puppet Enterprise on the VM
    • Using Puppet Enterprise to provision services on and configure the VM
    • Add the new VM to a vCenter tag-based backup system
  • Decommission
    • Delete the VM (removes from backups)
    • Purge the record from PE
    • Update ancillary systems after VM removal (IPAM, DNS, etc)

Continue reading

Enterprise Linux 7.3 makes some backwards-incompatible changes to interface names

Today, I was caught off guard by a change in Enterprise Linux 7.3. Apparently, systemd was assigning interface names like eno16780032 based on “garbage” data. I’m not really a fan of ANY of the names the modern schemes generate, what was the problem with eth#? But that’s beside the point. What hit me was that starting in 7.3 the garbage data is now being discarded and this results in a change in interface names. All this, in a point release. Here’s KB 2592561 that details the change. This applies to both Red Hat EL and CentOS, and presumably other members of the family based on RHEL 7.

The good news is that existing nodes that are updated are left alone. A file is generated to preserve the garbage data and your interface name. Unlike other udev rules, this one ONLY applies to existing systems that want to preserve the naming convention:

[root@kickstarted ~]# cat /etc/udev/rules.d/90-eno-fix.rules
# This file was automatically generated on systemd update
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:95:de:4e", NAME="eno16780032"

As you can see, it’s based on the MAC. That’s the bad news. If you plan to use the node as a template to deploy other VMs, the resulting VMs will effectively receive “new” interfaces based on the new MAC, resulting in ens192 instead of eno16780032. This definitely introduces at least one minor issue: the eno16780032 configuration is left intact and the interface is missing, so every call to systemctl restart network generates an error. It can also cause other issues for you if you have scripts, tools, provisioning systems, etc., that are predicting your nodes will have interface names like ens192. This is not difficult to remedy, thankfully.

Continue reading

Connecting Puppetboard to Puppet Enterprise

Last week, I moved the home lab to Puppet Enterprise. One of the things I love about PE is the Console. However, I am a member of Vox Pupuli and we develop Puppetboard (the app AND the module) so it is convenient for me to use it and tie it into PE as well. Though the two overlap, each has functionality the other doesn’t. I really love the count of agent runs by status on the Puppetboard Overview page, for instance. After my migration, however, my previously-working puppetboard just gave me HTTP 500 errors. Fixing it took some wrangling. Thanks to Tim Meusel for his assistance with the cert issue.

First, let’s look at the existing manifest and hiera data for my profile::puppetboard class:

Continue reading