What is an Immutable Infrastructure
The concept of immutable infrastructure is an emerging IT strategy enabled using Docker and containers. Immutable infrastructure is the ability to standardize and freeze as many things as regarding your infrastructure as possible, so you can get consistent and predictable results when running code on it. For example, if you know that every node in your cloud has the exact same virtual networking configuration, your chances of having networking related app problems decreases significantly. Another key element of immutable infrastructure is cleanly and clearly separating the app from the data infrastructure, such that the two layers can be managed independently, but with well understood operational practices.
The ability to instantiate virtual environments has already existed for years, as well as the ability to try and detach the environment from the hardware it uses. Chef, Puppet, and Ansible have all gained popularity as a result of this operating philosophy that application environments should be reproducible.
The advantage of Docker is that it was created after that realization, so the building blocks of Docker really help support this approach.
They contain every moving piece your app might need:
- OS layer binaries and configuration
- Networking layer configuration
- Application layer binaries and configuration
- Runtime layer
While this approach helps a lot with the immutable infrastructure approach, it creates a challenge – the Docker “package” is essentially its own self contained bubble and can become a security hazard, if proper security policies aren’t enforced on it.
In other words, we’ve gotten to a slightly absurd situation:
Deploying software in a classic model often leads to configuration drift, which might mean that the configuration is frequently unknown and, more thus, often exposes organizations to security risk because of its complexity
Deploying software in containerized fashion will handle the configuration drift, however can create these “unknown” packages on which central security policy isn’t enforced
So while this is a challenge for companies looking to adopt containers, here at Twistlock we are focusing on mitigating this issue through security policy enforcement, which we call “container defense policies”. These policies enable an administrator to centrally and declaratively express security policies that apply to hosts, Docker itself, containers, and images. For example, an organization may have a policy that says ‘requires Java 8 or higher’ or ‘prohibit sshd from running in a container’. Twistlock allows organizations to simply select these policy controls within a graphical interface and then enforces them across the organization’s entire container landscape, without the organization having to create and maintain complex scripts or other tooling. Twistlock runs as a container itself, so it’s able to provide this protection across all the places and organization may run containers (e.g. developers’ workstations, AWS, Azure, VMware on-premises) and throughout the entire development lifecycle.
So, if you are considering the benefits of immutable infrastructure and using Docker to help you achieve them, make sure you maintain a strong level of visibility and control over what’s in all those containers and the hosts they’re running on, regardless of where that may be.
- Container Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog