Containers and Cybersecurity: Ansible, Kubernetes, More to Consider
Containers are a very big deal in enterprise computing right now. If your organization isn’t already using them, then trends indicate it probably will soon. This application virtualization technology has had profound implications for some companies that have embraced DevOps, and there is plenty of potential for it to have a similar impact on security operations.
To understand why, it’s good to start with an understanding of just what containers are. A modern application is a collection of pieces of code: the main application itself, configuration files, and custom files on which it depends. These tend to be unique to the application as it’s configured to be deployed on a given server.
A container bundles all of these things up into an image that can be saved and deployed quickly, consistently, and automatically across multiple servers. If differences exist in the operating system details between the development and production servers, the container insulates the application from them, making application movement between development and operations very fast and straightforward.
So what are the implications for security in all of this? One is that containers can allow vulnerabilities to quickly propagate if developers trust that all code in an image has been properly reviewed and updated. Conversely, a more positive implication is that specific network and application configurations can be tested, saved as images, and then automatically deployed when an attack, malware, or other problem takes the network or application delivery system down.
Because container technology is still relatively new, many IT managers are reluctant to depend on it. They also worry about complexity. But fear not: At Interop19, the Network Orchestration Hands-on Showcase decided to do a proof of concept that showed just how simple a container deployment can be — and why containers can be important to even a smaller organization. The demonstration involved primary and secondary network links with monitoring and network control applications deployed on the simplest of servers — Raspberry Pis.
Here, we’ll look at the individual components used in the showcase and how each could be used by a security team to replicate the work done at Interop. Most are software, a couple are languages (or language-like), and one is hardware. (To help those who are interested in replicating its experiment, the Interop Demonstration Lab team has placed all of its containers and support code on GitHub.)
The demonstration network team had a number of criteria for its work — criteria that made for creative tension, if not outright conflict between goals. According to network architect and team leader Glenn Evans, the demonstration had to be practical, linked to a group of sessions at the conference (in this case, the network automation crash course), and something attendees could understand and learn from quickly. The demonstration they hit on – to automate the response to a network disruption – fulfilled all three, Evans says, while the architecture they chose allowed attendees to …