Whether you love or hate the term, ‘serverless’ is one of the hottest new trends in the cloud computing world. Despite what the name may suggest, there are certainly still servers running your code, the real innovation here is that you do not need to manage these servers you just publish your code to be run by the serverless infrastructure. This architecture can be better described as FaaS: functions as a service or BaaS: backend as a service. Amazon leads this innovation with its Lambda service and other cloud providers have followed suit, including Google with Google Cloud Functions and Microsoft with Azure Functions.

Of course, this innovation is not restricted to proprietary offerings from large vendors, there are a number of open source projects offering serverless frameworks including Kubeless, Nuclio, OpenFaas, OpenWhisk, among many others.

A couple of years ago if an organization wanted to adopt the serverless architecture then they would have needed to engage with a vendor such as Amazon however today a growing number of open source projects address that need which leads me to the subject of this blog.

One of the most common trends we have seen in the industry is one that is rarely spoken about, in fact, it is so common now that it’s really the norm: Vendorless.

To best describe the term let’s walk through the way that most organizations started building their container infrastructure:

  • Linux as the foundation of their infrastructure: Pick your favorite distribution
  • Ansible (or Puppet, Chef, etc) to deploy the infrastructure
  • Docker to run containers
  • Jenkins to run the build pipeline
  • Kubernetes to handle container orchestration
  • Prometheus for monitoring
  • Elasticsearch + Fluentd + Kibana (EFK) for logging and analytics

The common theme here is obviously open source. A few years ago, with the exception of Linux, this list would look very different, either build using a monolithic solution form vendors such as IBM and Oracle or comprised of a number of proprietary products. Today the majority of cloud infrastructure deployments are built using open source solutions.

Getting started with an open source project such as Jenkins is simple, you can download a container image or packages for most Linux distributions and follow great documentation provided by the upstream project. There are often support forums or online communities using IRC or Slack. To get started you don’t need to call a vendor, sign an NDA, fill out an evaluation request to obtain a time-limited eval key and then be hounded by sales. You can get started without even talking to a vendor.

Most of the container projects we have seen today start ‘vendorless’ in this manner. But as deployments move from simple POCs and development environments to production that is often when vendors do get involved, typically the driver is the need for commercial support or to obtain value-added features. In the example we used above of Jenkins, we see many organizations move from Jenkins community edition to Cloudbees Jenkins Enterprise or from upstream Kubernetes to Red Hat OpenShift. So thankfully, speaking as a vendor, there is still a role for vendors, however, they typically get involved a little later in the project lifecycle and have to really earn their seat at the table with added features, certifications and support.

While open source solutions have historically provided the core layer of infrastructure, there have been areas in which organizations would need to look at proprietary solutions. The most notable of which is the security which had until recently remained the bastion of commercial vendors.

For container infrastructure there are typically two key security needs:

  1. Image Security - Analyzing images to ensure they do not contain vulnerabilities and are in compliance with your organization’s operational and security policies.
  2. Runtime Security - Real-time monitoring of containers to ensure report on or block malicious activity at the network, system or storage layers.

We have spoken at length about the first area: image security and covered how the open source Anchore Engine can quickly and easily be integrated into your CI/CD pipeline, container registries and Kubernetes infrastructure to ensure that only images that meet your organization’s policies are deployed.

Over the last decade, it has become clear that open source technologies provide the right foundation for infrastructure and at Anchore we believe that security and analysis tools should be open source so that anyone can inspect the code to validate that the results are fair and accurate. And since security tools typically are granted the highest level of privilege in terms of access and control of resources you need the mantra of “Trust but verify” is especially true.

With Anchore Engine we ensure that only the right content, from known sources configured in the right way, is promoted from your CI/CD system and deployed in production but once deployed unknown vulnerabilities or misconfigurations can lead to a container being exploited.

The traditional approach to security monitoring involved looking for known signatures is network traffic, files, etc. Similar to the approach taken in the early days of antivirus software where security vendors played an endless game of cat and mouse with virus authors, requiring the antivirus software to be continually updated with new signatures and new viruses were detected in the wild. Over time these solutions evolved to use heuristics in addition to signature mapping. A similar technique is used by the Falco project which takes a more behavioral approach to detection. While there are many different ways that a container could be compromised all of which would need to be explicitly monitored for Falco looks at what is happening once the attacker has compromised the container allowing you to report and then block anomalous behaviors. For example, why would a reverse proxy container need to write a file into the /bin directory, why would a PostgreSQL container make an outbound network connection, why would your Redis server spawn a shell process?

With the addition of Anchore Engine and Sysdig Falco you can build an open and secure container infrastructure.