What do containers have to do with software testing? You might be tempted to answer “not much.” Containers have become famous primarily as a solution for application deployment, not testing.
In fact, however, containers are just as valuable when it comes to software testing—including but not limited to security tests. Keep reading for an overview of how containers can help you perform better tests and improve the security of your applications and environments.
First, though, let’s take a closer look at a key concept in current container deployment and testing: environment parity.
What is environment parity?
You may encounter a variety of definitions online, but in relation to software deployment and testing, it can be defined as the exact reproduction of the actual deployment environment across the delivery chain. In other words, for true environment parity, a faithful duplicate of the environment in which the software will run must be available at all stages of development, testing, and operations. This makes it possible to provide some basic assurance at all stages of the delivery chain that the software will function as required when it is deployed.
Virtualization and script-based automation make environment parity both possible and practical. The key to this degree of parity is that the deployment environment itself is virtualized—a virtual machine, a set of containers running in a VM, or containers running directly on a cloud platform. Environment parity then consists largely of making a duplicate of the virtual deployment environment available at all stages of the delivery chain. Using script-based automation to set the details of the virtual environment makes it possible to reproduce the exact conditions of deployment.
Either virtual machines or containers can be used for this kind of duplication. Containers can in many ways be more closely tailored to such a task than Virtual Machines (since they are not encumbered with the standard, full-dress features which are generally part of VM deployment), and they have less overhead than VMs.
Streamline the Process
Container-based testing provides an optimal environment for very rapid test cycles. Virtualized test conditions can be rapidly set and changed via scripting, with a high level of assurance that the test environment will match the target deployment conditions.
Containers also allow large-scale automation and parallelization, the two key elements of high-speed, accurate testing in the DevOps world. Virtualization, of course, eliminates most or all manual test setup/takedown tasks; automation makes it possible for the virtualized equivalents of these tasks to be carried out rapidly, and with minimal human supervision or intervention.
Go Parallel for Speed
Parallelization can speed up testing by several orders of magnitude. In a manual, hardware-based test environment, most tests are performed sequentially simply because the limited number of available test machines and test technicians does not allow more than a handful of tests at the most to be performed at the same time.
In a virtualized, automated test environment, there is no built-in limit to the number of test environments that can be created, or the number of test scripts that can be run. Tests which are dependent on prior actions can be placed in sequential scripts based on those dependencies. Individual tests or test sequences which are independent of each other can be run in parallel on separate virtual systems.
Parallel Means More
This does more than simply cut test time down to a fraction of the manual equivalent. It also allows more tests to be run—again, by several orders of magnitude. This can be particularly important in performance testing, where problems may only show up after a large number of repeated operations, or a high volume of traffic.
Massive parallel testing also allows more kinds of tests to be run. Tests which might not have been performed in a manual testing environment (because time and resources were limited, and other tests had higher priority) can be run as a standard part of the test regime in a virtualized, automated environment. This, combined with the much greater number of repeated tests, increases both the range and accuracy of software testing.
Virtualized, container-based testing also provides a more secure environment in which to run tests. What’s at stake when it comes to maintaining test environment security? As it turns out, quite a lot: code, test results—Even the tests being run can tell competitors and hackers much more than you want them to know.
The tools and methods required for environment parity also give you full control over test-system infrastructure, allowing you to control, monitor, or eliminate potential vulnerabilities. Since container environments can be closely tailored, actual elimination of potential points of entry is in many cases fairly easy.
Minimize the Test-Data Footprint
Spinning up containers for one-time tests, then destroying them, allows a high level of security, not only by making it harder for intruders to target specific containers, but also by reducing the amount of test data in memory or storage. Only test results and logs need to be persistent, and they can go directly to high-security storage. Intermediate test results and other sensitive data will disappear with the test container.
As we described above, environment parity allows you to reproduce the actual deployment environment. With regard to testing for security issues, this level of accurate reproduction is extremely important, since security—even more than performance—may be dependent on specific elements of the environment.
An application which is secure in an idealized, sandboxed development environment may turn out to be vulnerable in the deployment environment—and without environment parity, important vulnerabilities may not be detected until it’s too late. When security tests are performed under conditions of full environment parity, however, those same vulnerabilities can be detected and eliminated before deployment.
Virtualization also makes standard security tests easier and faster; script-driven, container-based security testing can be applied at all stages, from the code and unit level to deployment. As with other kinds of testing, automation and parallelization allow far more iterations and types of security tests, as well.
Containers Taking On the Role of Attacker
Along with deploying standard security testing tools in containers, you can use containers to deploy tests targeting potential vulnerabilities specific to your application or its environment. Security test containers can take the role of the attacker with, for example, containers designed to employ specific attack methods or combinations of methods, either with an assigned range of ports to attack, or possibly set up to probe all ports.
Containerization naturally lends itself to security testing based on modeling attacker roles. You can use containers to reproduce different kinds of attackers, different attack methods, and different attack goals, broadening your range of security testing.
A good mix? In many ways, containers and testing are a necessary combination in today’s IT environment.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Announcing Our Series C FundingRead the Blog
Real Time View of Your Cloud Native Applications: Radar v3Read the Blog
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog