Container drift
1. Container drift
When your container has a container layer, it can write to that layer and make changes. This can be convenient, but it can also introduce dangerous container drift. In this video, we’ll examine container drift and how to deal with it. Let’s investigate! A container layer is a writable space in a container. But, this space poses security risks. The more the container writes to this space, the less it has in common with the original image it was created from. When the container writes to the container layer, the container changes. That’s container drift. One way to find vulnerabilities is by scanning for them. If containers can’t be changed or updated, scanning images would prevent vulnerabilities from being introduced at runtime. When a container has a writable container layer that can be changed, scanning the image won’t help much. So, while having a writable layer can give the container some flexibility, it can also introduce vulnerabilities. Vulnerable images don’t pose an active threat by themselves. But, they can introduce vulnerabilities to a live environment. Imagine the following scenario: A developer team needs to deploy a resource quickly, so they use an image from an outdated container library. The image had been previously scanned and was free from vulnerabilities and malware. So, they dispatch the container with the added image. When they dispatch the image, they discover new vulnerabilities in the image. Now, there’s a vulnerability in the live environment. Even a popular, commonly-used container library can contain thousands of images with malware. This malware might include cryptocurrency miners, back doors, website redirectors, and DNS hijackers. These consume resources and increase operational costs. They also give attackers opportunities to gain information and hijack your website. Container images are layered. The container layer is a writable layer that allows changes to be made. As the container writes to this space, it becomes different from the image it originated from. To prevent the problems associated with container drift, you need to prevent the drift itself. Drift prevention stops files from running if they’re not part of the original image. You can use drift prevention to keep your container immutable, meaning no new executables can be added. Code needs to be updated to keep up with changes to technology. When these changes happen, you can build a new image and deploy it. But, make sure to keep the old image available in case you need to go back, so you can redeploy it. When you’re building containers, you should also keep a list of their components. These components include the software built into the container. A software bill of materials, or SBOM, is a machine-readable list of each piece of software and its components involved in the supply chain. An SBOM will provide information on applications and components running in your container, and software information for all third party libraries you’re using. An SBOM can also track software and its components. It can track where they come from, and what security vulnerabilities they contain. And, it enables protectors to stop vulnerabilities from being exploited. SBOMs usually follow the Software Package Data Exchange, or SPDX standard. SBOM documents may contain: package information, file information, snippet information, any other licensing information detected, Information on the relationships between SPDX elements, annotation information, and review information. Container drift can compromise your containers’ security, but you can prevent it. You can use the knowledge you learned in this video to keep containers secure throughout your cloud security career.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.