Security risks accompany every new technology, and containers are no exception. Communication and traffic between containers is often unrestricted. Containers can have unlimited access to processes and files.
Also, containers can amplify kernel threats by sharing the same kernel and host. Poor container maintenance can expose IT environments to a higher risk of penetration. And unverified container images can be an invitation to malicious actors.
Many risks can be reduced, however, if security considerations are baked into the container development process and the responsibility for security is shared. Security used to be something that specialists applied to deployments, but when you move to a DevOps culture, security becomes part of everyone's responsibility.
More organizations are recognizing that sentiment. In the most recent DevSecOps survey by Sonotype, 91% of outfits with mature DevOps practices agreed that security is part of everyone's role. (Sonotype helps organizations source, manage, assemble, and maintain open source and third-party components.)
In that vein, here are practical tips that can be taken during each stage of the development process to make a container deployment more secure.
1. Run static analysis on your container code
When creating a Docker file for a container, include a program line to run a static analysis tool on the container code. The tool can identify coding errors that create security flaws.
But because static analysis has its limitations, it's also a good idea to have a second pair of eyes—another developer or security team member—look at the code for issues, security or otherwise.
[ More from DevSecCon London 2018: Colin Domoney on How to secure your software supply chain | DevSecCon: Container, serverless growth haunts DevOps security ]
2. Check your encryption
If you're working in an environment where compliance with industry or government standards is required, encryption can become an issue for your containers. That's certainly the case with any business that needs to conform with the European Union's General Data Protection Regulation.
In environments with heavy compliance requirements, you should get your hands on a tool to check the level of encryption you're using. It can identify older forms of encryption no longer considered secure.
3. Test for security as well as function
When testing software, developers are usually focused on function or simply whether it works. By broadening testing to include security issues—flagging vulnerabilities in dependencies, for instance—containers can be fortified against attack.
Such testing may not be optional. Vulnerability scanning, for example, is required for PCI compliance.
And for good reason. The use of flawed open-source components as an attack vector has been growing in recent years. According to the Sonotype survey, nearly a third of respondents (31%) said their organizations had a breach that could be attributed to a vulnerability in an open-source component or dependency in the last 12 months. That compares to 20% in 2017 and 14% in 2014.
4. Never patch containers. Destroy them instead.
In most organizations, it's not possible to patch containers, even if a developer wanted to. There can be thousands of them, many of them with very short lives—on average, 2.5 days. Nevertheless, if a vulnerability is discovered in a container, it needs to be destroyed and rebuilt from scratch so the risk of introducing manual errors is eliminated.
5. Use image admission controls
Creating controls that determine if an image passes security muster before it's used can prevent future problems. For example, a policy can be written to prevent the image from running if its password is exposed in the image.
It can also prevent a container from running with greater privileges than it needs for its tasks. Containers run with root privileges for their entire host, not just within the container. So unless the container is controlled, bad actors could use it to do things it shouldn't be doing, such as creating new users and passwords.
6. Make sure your host meets CIS benchmarks
Hosts where containers reside should meet Center for Internet Security best practices. You should test the hosts to see if their configurations meet the CIS benchmarks for your container software and orchestrator, such as Docker and Kubernetes. Such tests can expose potential problems, such as program defaults that are insecure.
7. Limit a container's privileges
If possible, the USER command should be used in the Docker file to limit or eliminate complete root access by the container.
Also, never run a container's privilege flag. The privilege flag was created for accessing Docker from inside a container. In practice, though, there is almost no reason to do that.
Giving a container broad privileges can be particularly nettlesome if an intruder gains control of it. With root privileges and the privilege flag, a malicious actor will be able to extend control outside the container and expand the scope of the attack.
8. Restrict system calls
System calls can be very powerful, so they should be used with care. About a third of the system calls used in containers are superfluous.
For instance, a popular system call is Ptrace. With it, one process can be used to control another, as well as change memory. The call is largely used to debug code, so it has no place in a container after it's deployed.
If it were left in a container and the container were compromised, it would be a jackpot for an attacker. A good Docker profile would prevent a container from running if it contained Ptrace.
Docker has done a good job of creating profiles that address the system call problem. However, the profiles aren't implemented in Kubernetes, and it takes a bit of sweat equity to get them to work with the orchestrator.
9. Create a pod security policy
Pods are used to organize containers in Kubernetes. A pod policy can be used to address security issues such as containers running as root and activating the privilege flag.
Work through the issues
While developers are recognizing the importance of security, they remain hard-pressed to give it the attention it deserves. In the Sonotype survey, almost half the 2,000-plus respondents (48%) said developers know security is important but don’t have enough time to spend on it.
That doesn't have to be the case. The automation used in DevOps to speed up development can be used to incorporate security processes into the continuous integration/continuous development pipeline and make security a manageable part of the process.
Liz Rice spoke about this topic at DevSecCon London.
The DevSecCon London conference and training sessions took place on October 18-19, 2018. DevSecCon Singapore runs February 28-March 1, 2019.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
