SIMP – Let in the Light

Back to Listing

Ryan Russell-Yates

Hanover, MD, 14 January 2016


Configuration Management and Server Management have always gone hand-in-hand for me. In the beginning of my career, I was fortunate to learn Puppet and Linux at the same time which engaged me with both development and operational disciplines. This was my introduction to DevOps.

My first pure Linux DevOps job required me to use SIMP in production prior to it’s official Open Source release. With a SIMP framework in place, it was easy to take security and compliance for granted because it was all done for me. Not everything about using the SIMP framework was easy. I was often irritated when my newly developed application wasn’t running as I thought it should. I was tormented, troubleshooting the same few issues at first. “Why can’t I connect on this port? Why does my service keep dying? Why can’t my system user access things?” Usually, I could resolve these particular issues within an hour and successfully launch my application in the development environment. What I took for granted was that I rarely, if ever, experienced deviation in my applications from development to production. Two years passed, and I grew accustomed to a method and style of development built on a compliance framework.

 

Now, I have a much wider customer base and work with all types of organizations to integrate necessary components into their existing systems. I’m currently working with a customer to automate security hardening of servers already living in production. I know that integration can come with quick successes or it can bring extended challenges that take ongoing effort to work through.

 

Many of these organizations are transitioning to DevOps by writing Puppet code and deploying applications automatically. With all the foundational prerequisites in place, the application is deployed and configured almost like magic. The application just seems to self-deploy to the development and test environments. The organization often claims they’ve reached continuous integration.

 

Then the application deploys from test to production. The DevOps team didn’t bother to make the security and compliance baseline exact mirrors between development and production. The team is supporting a deployment to production and discovers, “our firewall doesn’t allow that,” and “our antivirus thinks the application is a threat.” The myriad of problems going from a vanilla CentOS 7 install to a fully secure network and OS in production can be astounding. Many organizations are guilty of treating development environments as wild-west commodities, ready to be created and destroyed at a moment’s notice while the production servers are regarded as holy relics, where thou shalt not change nor understand security and compliance configuration.

 

I didn’t understand that we were working in Rugged DevOps until I started working around DevOps that ignored security and compliance. If you thought your application was pristine in the development environment, but the security stance in the production environment destroyed your successful deployment, you’re not really doing Continuous Integration. You may have the Dev and Ops teams together, but you somehow forgot the Security team that also supports the product. You’ve completely forgotten to configure an integral part of your system as part of your infrastructure in the beginning, rather than the end. Now you’re back to meetings and stovepipes trying to make sure team A is supporting team B properly. And so I discover that the SIMP problem of “Why can’t I connect on this port?” is a far easier problem to tackle than “How do I get 93 different firewall settings on 1,400 different systems?

 

SIMP by default provisions dark, lifeless boxes. The kind of server that sees nothing but DNS and SSH, with no entry granted because root login is disabled and every other user isn’t allowed a login thanks to PAM. Each and every server is hardened to a point of almost utter despair. Nothing runs, and every 30 minutes, it returns to that state of lifelessness. This is what a completely hardened system looks like. It is a system attempting to block out everything it does not recognize, and by default it recognizes nothing.

 

So, I learned to soften instead of harden. If I want a user login, I create a user (or even better, use the included SIMP LDAP). Then I just add a single PAM entry allowing my user group access. Now, I have a door in my dark, lifeless system. I then add my application, and I add it in the default Puppet way: user, package, service, file. My lifeless box has sprung forth with life. The only thing missing is light. I install Apache (pre-configured with SSL) and add an iptables rule to allow port 443. Now I’ve got a functioning https web application. I’ve just systematically configured the doors, a living application and a window into my server, turning this void into a breathing ecosystem. Deploying from Development to Production from here is easy, because I create life from the same lifeless black boxes in development that I do in production. I don’t have any compliance or security deviation between environments, because it all starts locked down frmo the beginning.

 

Learn to give a dark place life, rather than creating life and hoping it can live in a dark place.

 

Here is a very simplified example of what giving my application life might look like:

class ‘simp-life’ {

###########

#Door – a login

###########

user {‘simp-life’: ensure => present}

pam::groupaccess::modify { ‘simp-life’: ensure => present}

###############

#Life – an application

###############

package{‘simp-life’: ensure => present}

file {‘/opt/simp-life/config.xml’:

ensure  => present,

source  => ‘Puppet:///modules/simp-life/config.xml’

require => Package[‘simp-life’]

}

service {‘simp-life:

ensure => present,

require => File[‘/opt/simp-life/config.xml’],

}

########################

#Window – Allowing the outside in

########################

include ‘apache:ssl’

apache::ssl::setup {‘default’:}

iptables::add_tcp_stateful_listen {‘allow_life’:

dports => ‘443’,

}

}

 

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others

puppet, simp

Share this story

We work with these Technologies + Partners

puppet
gitlab
simp
beaker
redhat
`
AFCEA
GitHub
FOSSFeb