Blogs

Introduction

Security in the company's own IT infrastructure is becoming more and more important. However, the main focus is more on net hardening against external threats and less on the security of the methods and software used in the company. As more and more companies rely on microservices, new, currently still too much neglected attack vectors are emerging that exploit the lack of security of the images used by CRI.

This article aims to answer the comprehensive question, which dangers and challenges can emanate from an image, which obstacles there are in securing the protection targets (CIA) and ways to overcome them.

How microservice becomes a major uncertainty

At first glance, obtaining an image to be used in a microservice environment is relatively simple. The first step is to determine which image is required for the intended application, for example a web server. The next step already includes a search in a comprehensive image database. If a suitable image is found, it can be downloaded and used directly.
If the process described above, which is admittedly very broken, is similar to the process you are using, chances are that your images could have major security holes.

• Imagine making your own image

To minimize the security risk, we go back to the very first step, the determination of which image is needed. If it is only a web server, as in the described case, it is a good idea to create the image itself in order to be able to determine the artifacts used and their versions and to close possible security gaps already during the creation of the image.
Of course, it is as clear to you as it is to me, that it is exhausting to build an image yourself. But there are some advantages that speak for this way, so you can make sure that only the most necessary packages are installed. This can save a lot of time and space, especially if the container concerned is scaled up. Another big point is the question of trust, of course you can view a configuration file in many places, but who guarantees that this is really the right file and that nobody has changed anything? However, once you ask this question of trust, you are forced to move on, the next step in this sequence is unfortunately: "Do I trust the base image?
Of course, many base images are provided by the official site, and on a smaller scale, with a view to risk assessment, this is sufficient in most cases, provided of course that one trusts the official site. However, for larger scales, it may make sense to create your own base image at least once to really keep full control. In some application areas you can only trust your own company completely.
If the way to go is to create the artifacts on your own, you have to deal with the verification of the artifacts. Here, the use of hash values is advisable.
PGP keys are a good way to do this, they have the advantage over other hashes that the corresponding keys are stored online and thus offer double security against attackers.

• Images are like a box of chocolates; you never know what you will get

If the creation of your own image is not an option after all, either because the setup of the required service is too complex and/or time-consuming, you must of course also have already finished images available, since you do not want to constantly reinvent the wheel within the company. Additionally, some resources are not available at all, either because the image setup is not really documented, or the service is not open source.
However, with the procurement of these finished images it comes to many safety related uncertainties, then you must ask yourselves the question: "Do I trust the author of the image? If you answer the question with no, you have three options. The first option is to find another image of an author you can trust, more about this later. The next option would be to check the contents of the image in question "by hand", but this can prove to be a big-time challenge, especially with larger and more complex images that have many dependencies to different libraries. This possibility exists only under the condition that the author has also provided sources for his image. The third possibility is then the independent creation of the image as described above.
If you can answer yes to the question whether you trust the author of the image, you must always be aware that you are entering a chain of trust. Because by the fact that you trust the author you must bring inevitably to each confidence, which was brought by the author confidence.

• Image Verification

If an image has been found whose author is trustworthy enough and whose sources have been thoroughly checked, the next step is to check whether the image received really corresponds to the previously checked image.
Of course, it would be easy now if you could download the found image directly by specifying the name of the desired image and the corresponding tag. However, this could lead to further complications, over which the author does not need to have direct control this time. It is not possible to identify the content of the image described by a tag, and the reference of the tag can be overwritten by another image at any time. Therefore, the control over the selection of the used images cannot be ensured, since the tags can be changed both consciously and subconsciously.
In order to be able to maintain the desired version and thus the quality of the images used, references should always be given with digests, as these clearly refer to the desired content and cannot be overwritten.
Besides the danger of using a tag whose reference has already been overwritten, there are of course also attackers who have an interest in infiltrating false images. To counter this danger, the use of hash values is a good idea, as in almost every field of verification.

• Honey, did you take out the trash?

After the image creation has been completed in any way, the question arises where the image will be stored so that it can always be implemented quickly and easily in the appropriate environment.
For this specific use case the container registry is used. This is very flexible and can also be mapped using a separate container. However, comfortable solutions also disregard many security aspects.
So, you should give the container registry the same protection goals as all other important data. Additionally, it is a good idea to check newly added images for malware before they are added to the registry. Among other things the registry should always be updated and held on the newest conditions, in order to ensure that all relevant safety updates are brought in and again discovered safety gaps are closed.
The so-called "House Keeping" should also not be completely ignored, this is the method of regularly sorting out old and no longer used images from the registry. Here it is important to minimize unnecessary redundancies and to avoid them in the best case. A further advantage of a tidy and clean Registry is the ensuring that no old images with well-known safety gaps remain available. For example, an attacker who breaks out of the container could reload an old and defective image and cause even more damage.

Conclusion

In conclusion, all that remains is the sobering realization that the moment we ask the question of trust, we enter a rabbit hole. In the future, everyone will have to decide for themselves where they want to draw the line. Especially if you are aware that a lack of trust always leads to more invested time and costs. Therefore, chains of trust will become more and more important in the future and the market will have to react accordingly.