An Introduction to DevOps

DevOps also automates the process of software integration, testing, deployment and infrastructure changes. It aims to establish a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably."

Image courtesy of Kharnagy under CC 4.0. 

Typically, in a Windows environment, once there's about 5 systems, a Domain Controller will be employed to automate and manage certain tasks. However, in Linux environments, we often find environments of 20 systems or more managed individually. This demands much more overhead, so DevOps automation or environment orchestration makes a lot of sense.

The tools usually used for this type of automation are Ansible, Chef, Puppet, or Salt as well as the recent introduction in Microsoft Windows 2016 of Desired State Configuration (DSC).

Cloud service providers also have various flavours of the above. In AWS it's called OpsWorks, and is based on Chef. Azure has various DevOps tools but the core is based on Ansible, Google Cloud Platform has Consul.

Now what does this mean from an operational and security perspective?

Operationally, it means we can configure profiles for different system types and automate the configuration of those systems according to their functions. One can create a server, allocate a web server profile and the orchestration manager updates and hardens the system, installs required software, configures the system accordingly, and finally deploys the server with little to no manual intervention.

Here's an example of a Chef recipe so you can see how it works. This simple recipe checks to see if Apache is installed and, if the package doesn't exist, it installs it, enables and runs the service:

#Install & Enable Apache

package "apache2" do

action :install

end

service "apache2" do

action [:enable, :start]

end

We can build security into the templates used by the orchestration system such that security baselines are automatically implemented on all systems. For this to be successful, we need to ensure the people scripting the templates understand the security requirements and can translate these into configurations. We also need to ensure changes to these templates are monitored; a mistake could render all systems of a given profile insecure, or worse, a malicious actor could automate the deployment of malware.

In considering the recommendations below, it's clear we're looking at a scripting tool which goes through various iterations and versions and can be quite powerful. It's worth mentioning that managing the process is similar to a software development lifecycle (consider that develop is the first part of DevOps).

Anyone looking to deploy DevOps software should consider employing version control and rules which ensure functionality is developed and scripts are reviewed and approved by appropriate parties prior to their implementation into production. Adequate testing outside development should also be performed prior to deployment.

 At a minimum a successful DevOps deployment needs the following:

• Strong access controls restricting access to authorised users only
• Individuals writing templates that are knowledgeable about security
• Changes to templates are approved via change control
• Changes to templates are subject to peer review and testing
• Integrity checking on the template files to identify out-of-band changes
• A version control system

Many non-cloud environments will already use tools for configuration automation. The auto-deployment and scaling functionality provided by cloud platforms mandates greater automation of assurance as misconfigurations are also scalable and expensive.