Amazon Web Services is one of the most sought after Internet As A Service (IaaS) providers and it has been so for the past eight years in a row. After all, AWS is, without a doubt, one of the best providers around. Their services have not only been tried and tested, but have also been very reasonably priced. That’s an offer that’s difficult to refuse, especially when the services offered are ones that small businesses sorely need, but cannot afford to acquire physically.
The danger in using AWS isn’t that it’s not secure. In fact, you’ll find in this AWS Podcast that the security features that come with AWS are some of the most secure of their kind. But, the danger lies in the fact that it’s your role as the customer to ensure that the data of your customers is secure. This task involves many aspects such as access management, firewall and network configuration, platform and application management, and of course, operating system configuration.
Containers are quickly replacing traditional cloud-based services because of their ability to transfer applications from one environment to another. The rate of deployment as well as the enhanced debugging allow software developers a much higher rate of production. However, this does not come without drawbacks.
Containerization relies heavily on images that serve as the building blocks for containers. Because of the technology, developers are now more capable of creating their own images. The security risk comes in the fact that images that are composed of multiple layers are susceptible to having open source components slip into the many layers of the image. This is especially true if these components aren’t first correctly scanned and authenticated.
While it’s true that Amazon Security Groups can indeed create security policies for every cluster, they won’t be able to do the same for individual image layers, which makes this solution ineffective. This means that there will simply be too any blind spots in your system because you’re only able to monitor clusters and not their components.
Nipping The Problem In The Bud
It’s not all bad news though. While it’s currently unlikely that we have tools that are able to scan images at a per-layer level, there are measures that businesses can apply in order to ensure the security of the parent images as well as the child images (the subsequent layers of the image). It’s really a matter of being to detect image vulnerabilities as soon as possible and eliminating that particular layer if it’s impossible to fix it.
A basic measure would look like this:
- The developer makes code changes to the parent image
- CD platform builds a container image (or the layer to be added to the parent image)
- CD platform forwards the container image to the staging registry
- CD platform scans the image (or the subsequent layer to be added) through the use of a tool
The tool determines whether the layer passes or fails based on the security policy mapped to the image by the developers. If the image passes the policy evaluation and any other tests defined in the process, the image is forwarded to a production registry at which point, it will then be added to the overall project.
While this process may seem crude, especially when we consider how technologically-advanced we’ve become, it does, however, provide a temporary framework that we can further hone into something efficient later on.
image source: https://images.pexels.com/photos/907607/pexels-photo-907607.png