2018 has been called the breakout year for containers, and for good reason. They have taken the enterprise computing space by storm, completely changing the potential of DevOps. However, they’ve also changed the dynamic of DevOps itself. See, containers typically lack adequate security, something overlooked in DevOps.
Container and Kubernetes security provider, StackRox, released a report called The State of Container Security. They talked to over 200 IT professionals to get their perspectives on container security. It intends to understand how container adoptions trends relate to modern security concerns.
We reached out to StackRox to get a deeper take on their perspectives and concepts about container security. Ali Golshan, CTO and Co-Founder, gave us his insights. Also, be sure to check out the other part of our interview here.
What are the phases of the container lifecycle?
- Why are they different?
- What does this mean from development and security perspectives?
The container life cycle, like most software development life cycles, follows the traditional Build, Deploy, and Run phases. In build, you’re building the code; in deploy, you’re launching the software; and in run, you’re in on-going operations mode.
Across these phases, the mission of security remains the same: harden the environment to reduce the attack surface and find and stop malicious actors who still manage to break in. But the security tactics have to change in the container world because the pace and topology are so different compared to building monolithic applications, and traditional security tools have no awareness of containers.
In each phase, the new security tools and tactics are focused in slightly different areas. During the build phase, the goal is to secure the images and assess the risk profile of your assets. During the deploy phase, the focus shifts to hardening the environment – looking for the misconfigurations and other points of vulnerability and closing down those attack surfaces. After you’ve done all you can to keep out the “bad guys,” you then need to watch the environment to find and stop malicious actors in real time.
Are there any notable examples of attacks on containerize environments?
- In what phase were these containers left exposed? Any insight into why/how?
Two prominent examples of container vulnerabilities and attacks have received extensive coverage. In one, Tesla had its AWS environments hacked, and the attackers were able to load cryptomining software and harvest digital currency. This hack resulted from Tesla’s Kubernetes dashboard being exposed – a misconfiguration in the deploy phase.
The second well-known vulnerability was one published by Shopify. The company documented the vulnerability, along with details on how to prevent it, because it was exploited. For Shopify, the problem was that the company had left metadata exposed on its Kubernetes deployment, and hackers could have used this access to compromise all of the Kubernetes deployments. This vulnerability also falls into the deploy phase, with a misconfiguration at its heart.
Are there security capabilities/features/processes unique to each phase?
- What are they?
- What security components are most critical for protection at each phase?
Given the different security goals for each phase of the container life cycle, the security features and tactics change for each phase as well.
During the build phase, look for features such as vulnerability scanning and management, CI/CD integration, and registry integration. Vulnerability scanning is crucial to building secure code. Integration with CI/CD tools means the container security platform will fail a build that doesn’t comply with secure build processes. Registry integration means you can ensure your systems will allow images only from verified registries.
During the deploy phase, you’re performing security tasks such as compliance, network policy enforcement, and configuration management. Compliance with security best practices, DevOps best practices, and benchmarks from entities such as the Center for Internet Standards help ensure your assets will launch in a secure manner. With network policy enforcement, you can limit which assets can talk to which other assets, to make sure you’re not allowing unnecessary communications paths that leave you exposed. Configuration management provides the checks on how containers, Kubernetes, and other system elements are set up to reduce unnecessary risk.
Where do various DevOps systems come into play in the phases of the container lifecycle?
- As these systems are integrated into containerized environments, how do they uniquely impact the security of the environment?
Containers operate within a broad DevOps ecosystem, and any container security platform must tie into, operate with, and draw from a variety of these system elements. During the build phase, integration with CI/CD tools such as Jenkins and Circle CI provides the mechanism for failing insecure builds, as mentioned previously. Tying into image scanning systems means organizations can use the scanning software of their choice and feed that data into the container security platform. Integration with secrets management systems enables organizations to use the software of their choice, such as HashiCorp Vault, while providing security teams with insights into any weak secrets being used.
During deploy, it’s crucial that the container security platform tie into the orchestrator such as Kubernetes, OpenShift, or Google Kubernetes Engine. This integration enables the configuration management checks into vulnerabilities and exposures in this critical infrastructure. These integrations also help enable the network policy enforcement capabilities.
Integration with container runtimes such as Docker are essential for identifying malicious activity during runtime and preventing the spread of the attack. Once you’ve established a baseline of operations for these container runtimes, the container security platform can then more readily identify aberrant activities.
Across all phases, it’s valuable to tie into DevOps notifications systems such as Jira, Slack, or email so that security teams can readily share crucial remediation details with the development team that can address the problem.