Managed Stack Images

Feature of the month

Managed Stack Images

This month, we talk about HyScale’s Managed Stack Images that allows automatic security patching, quick image scanning & a lot more

October 14, 2020 - by Jayalakshmi Elango

Vulnerability management tools for stack images

The origin of the container images plays a significant role in securely deploying any application onto Kubernetes. Most containers are short-lived and frequently redeployed, making it difficult to ensure security and determine whether your container image is built from up-to-date and trusted sources.

In the container world, images come from various project upstreams and are not always trustworthy. Several container images are readily available in public image repositories. These random images are sometimes pulled from unverified publishers across various upstreams, leading to security risks at the time of production and compromises on security.

In the pre container era (VM world), ops teams used to be responsible for performing security patching and providing regular updates with the upstream packages.

Whereas in the container world, containers are ephemeral. When deploying at a large scale, the container count is greater than the VM count, making it difficult to keep track of each container image deployed overall in an organization and ensuring security for these application container images.

Manual security patch checking becomes a tedious process for the ops team, especially when there is an increase in stack images. This rapid scaling up of images tend to put the deployed application to security scrutiny.
Also, manually monitoring the stack image usage between application teams is a daunting task. Getting granular details like the current patch version, checking for aged/deprecated images, and warning respective application teams to update their stack image is difficult as there is no centralized system to track these changes.

To get fast builds during Kubernetes application deployments, reducing image-based security threats is crucial. Building a centralized solution that consistently scans stack images for known vulnerabilities and automatically patches them for critical security vulnerabilities, then notifies the respective application team to take the new patch update can be the optimal approach.

With this centralized system, you can:

  1. Keep track of a particular stack image usage across various applications
  2. Monitor aged / deprecated images

Ensuring security of vulnerable stack images

Before we get to how HyScale ensures security, let’s first understand the risks of a security breach and what it might cost us. There is a lot of manual effort involved in deploying containers whenever a new patch update is available. Rebuilding the application with the latest image is a must, which is a time-consuming process.

Any critical issues or vulnerability management tools is reported under the CVE database, i.e., common vulnerability management process and exposure database. For instance, we have seen examples of real cases like Heartbleed CVE-2014-0610, CVE-2019-5736, that underwent major security breaches and required immediate attention.

Even a few hours’ time delay in fixing an issue may lead to many critical problems, and result in intruders accessing the entire application and exploiting it.

Updating the images to the new security update is a non-negotiable to ensure that the application’s security does not get affected at runtime.

HyScale’s Managed Stack Images

“Managed Stack Images are the base container images on which the HyScale platform automatically performs security patching, notifying respective application teams in case of any vulnerability threats.”

This feature was built with the primary goal of notifying the users of any abnormality in realtime, regardless of the base stack images’ severity level. HyScale automatically scans through all the images daily for any new patch updates.

If a new patch update is available, it will notify the users accordingly with an alert message saying, “New patch available for your stack image from upstream. Do you want to update your application?”

This way, you can easily keep your images up-to-date, without having to pull from an unknown repository, or having to maintain the images and patching yourself.

– Who is responsible for handling security vulnerabilities inside the image

If you have picked up a stack image from some official container registry maintained by direct vendors, they will respond to relevant vulnerability disclosures on a timely basis and rollout updates frequently. So what’s critical is the speed at which the update is applied to a running and affected application.

For instance, if the ‘mysql’ package has some vulnerabilities the OS package vendor, who wrote or distributed the MySQL code, fixes the issue and rolls out a new security patch immediately with all the security solutions and updates.

– Structure of the Managed Stack Image

HyScale enterprise platform has pre-installed OS images. It provides an option to import distroless images as well from external and use it as a base image. Think of its structure as a stack of objects. OS image as a base, then stack image, and finally, application artifacts at the top level where the users take care of this stage.

If you take a deeper look at any microservice container image, there are broadly three categories of packages installed inside.

  1. OS level packages – packages that come along with the chosen operating system
  2. Stack packages – jdk, python, tomcat etc.
  3. Application artifact – war files, jar files, python packages, go binary, etc. This is the variable part where the code resides
HyScale's Managed Stack Image with vulnerability management

Fig: Internal view of container image

Security Vulnerability Management

The HyScale platform takes care of the entire package security. Inside each container image, there are several packages, from OS packages to stack packages and application artifacts packages.

Let’s look at a sample scenario where we want to containerize a Java application, we need to create a binary file, but those binary files can be more than 1. Here, the OS Image is the base image upon which the stack packages are installed. Each container image consists of an ‘n’ number of packages with specific versions.

OS Image : ubuntu 18.04 or debian jessie or alpine or distroless
Stack Image: OS Image + Jdk 11 + Tomcat 8.5
Artifact : web. war

Example of a Java web application

Cyber security container images with trust images from trusted source, quick patch and Kubernetes image pull policy

As depicted above, any package can be subject to vulnerability issues at any point of time. Package one can have issues on a particular day and package two on some other day and so on, which is unpredictable.

Here’s a quick checklist for ensuring security inside every container image,

  • Update the packages frequently
  • Keep the OS minimal, as fewer packages lead to less no of issues
  • Check on new updates and perform a security patch as soon as possible

The HyScale Advantage

The key difference Hyscale brings in when compared to other platforms is the automatic process of checking container images regularly. Our platform capabilities do not just stop with the scanning and notifying of the vulnerability issues. HyScale ensures continuous monitoring and automatic patch updates.

In a nutshell, HyScale’s Managed Stack Images is responsible for handling packages, and managing security vulnerabilities inside the OS packages & stack packages. It helps users identify security issues and is responsible for security patching and quickly fixing of issues.

Build a secure ecosystem with
HyScale’s Managed Stack Image