The past decade has seen a massive surge in terms of “cloud” technologies. What used to require on-premises hardware that took up large amounts of space, power and talent to operate efficiently, now can be operated by a small number of DevOps engineers and scaled up or down to meet demand and performance requirements. These new approaches to software deployment have fostered the cloud native principle which centers around the deployment of applications via containers. This new, sweeping technology has brought with it numerous benefits and many more considerations. And perhaps the most important consideration is security.
What are the Four C’s of Cloud Native Security?
The concept of cloud native security is best expressed as four building blocks sometimes referred to as the four C’s: cloud, clusters, containers and code.
Cloud
The cloud is the base of the security layers. Developers cannot simply configure application security at the code level so steps must be taken at the cloud level. Each provider (Azure, GCP, AWS, DigitalOcean, etc.) all make recommendations for running secure workloads in their environments.
Cluster
The next layer is the cluster layer. Kubernetes is the standard orchestration software. A cluster is considered secure when both the configurable components within the cluster and the software running in the cluster are secured.
Container Security
And following the cluster layer is the container security layer, which is the most critical part of application deployment security which we will discuss in-depth later.
Code
The final C is code. Building security into an application’s code is a part of the principle of shifting left or making application security a priority earlier in the application development lifecycle, which in the case of code, is as early as possible.
[caption id="attachment_987460827" align="alignnone" width="1474"]
Image source: Kubernetes.io[/caption]
Container Security & Vulnerabilities
With the speed of adopting containers as the preferred deployment method, security is a large concern. A Tripwire study found that 60 percent of organizations experienced a container security incident and in this study, 94 percent of participating companies said that they had container security concerns. Each container is a virtual machine running imperfect software that may contain multiple vulnerabilities that the development team may be unaware of. When you consider that a large organization may be running hundreds or even thousands of containers in production, you begin to have a measure of the large amount of compounded risk that can exist inside a highly containerized infrastructure.
The good news for development teams is that lots of work is happening in the area of container security in terms of establishing new best-practices and new technologies. Red Hat, Microsoft and many other vendors who publish common containers also publish CVE (common vulnerabilities and exposures) information ranked by severity. These findings show engineers the severity of the vulnerabilities that are present in packages in their containers so they can be mitigated before making their way to production.
This standardization of vulnerability findings has helped DevOps engineers to automate the entire security process. Before, humans needed to comb through code to find security threats and issues, but now scanning for these issues can become a stage in any code delivery pipeline allowing companies to deliver secure code faster than ever.
With the rapid adoption of containerization as the preferred software deployment choice, ensuring that those containers remain secure is one of the most important things that DevOps engineers can do to provide value to a company and one of the most important things companies can invest in to bring peace of mind to their users and anyone else who holds a stake in that software.
