In traditional cloud native environments, actions such as building and deploying applications will usually involve working directly with images hosted in one or more registries. Customers wishing to track changes in those images, in order to identify security and compliance issues, would need to set up an automatic process of constantly scanning them by connecting to all of the different registries that store images.
Red Hat’s Openshift Container Platform (OCP) allows users to build environments that work more efficiently for large and diversified setups, by using Image Streams instead of regular images when building and deploying applications. From a security perspective, this requires a different approach for tracking security issues that should work natively with OpenShift.
Using Image Streams wisely can help create automatic, well controlled, and easy to maintain CI/CD workflows.
What are Image Streams exactly?
Image Streams are an abstraction layer that provides mapping between image stream tags and actual images stored either in the internal OpenShift registry or in any external registry.
Image stream can also be looked at as pointers to actual images. A single image stream may consist of multiple tags, each of them pointing to an image from a different registry.
They can be created either manually or automatically:
- Manually by using OpenShift’s command line for creating an image stream
oc create imagestream stream-nameand then importing an image to an image stream tag by runningoc import-image stream-name:stream-tag --from image:tag
- Automatically by pushing an actual image to the internal OpenShift registry, which is common practice when building images in OpenShift using its build strategies.
Once created, Image Streams can be referenced by all deployments and builds within the same project, and used just like a regular image without making any special configurations to support it.
These are several benefits to using Image Streams in OpenShift:
Security
- Isolation: Since image streams are scoped to a specific project, OpenShift objects (deployment, build…) from project A will not be able to use image streams from project B. This creates automatic isolation between code bases, and also prevents accidental use of the wrong image version or tag.
- Access Control: Role Based Access Control (RBAC) policies can be used to provide various access levels to an image stream, such as allowing an image stream to be used only by deployments using a specific service account.
Automation
Image Streams provide out-of-the-box automation to your pipeline and deployment life cycle by leveraging Periodic Updates and Image Change Triggers. Image stream tags can be configured to automatically detect changes in the upstream registry based in a configurable interval, import new images and rebuild or redeploy the application with the updated image.
Maintenance and Scale
Updates to images are done in the scope of the image stream object. referencing image stream names in builds and deployments eliminates the need for updating configurations in cases such as:
- Replacing the actual image used be the deployment
- Moving an image to a different registry
- Changing the registry credentials.
If you have multiple deployments using the same image stream, you will only need to make a single change the image stream object and all deployments will be updated automatically. This makes it much easier to keep images up to date, make sweeping changes, and manage large-scale deployments that draw on images created by different teams (or even by 3rd party ISVs).
What about managing vulnerabilities?
As great as Image Streams are, they are still a virtual entity that only points to an image in a remote registry. If a user wants to get a vulnerability report for her image stream, she will need to configure the upstream registry in her scanning solution and scan the actual image being referenced. This can be tedious when working with multiple registries, especially in a multi-region/multi-cloud/hybrid environment.
Additionally, if a user is using image streams in her deployments and wants to get the consolidated security status of such a deployment, she will find it very difficult to correlate it to the actual image being used, since the actual image and the image stream tag will usually not have the same name.
Since we wanted to ease the process of scanning and monitoring deployments using image streams in the Aqua platform, we took a different approach by treating image streams just like any other registry.
To that end, we’ve added a new, seamless integration called “OpenShift Container Registry” for searching and scanning image streams across all OpenShift projects. Using this integration doesn’t require the user to provide any credentials or URLs.
The Aqua platform automatically discovers and connects to the image stream engine, providing the same experience and feature set as when scanning regular images from regular registries.
Thanks to this unique integration, users can now:
- Search all image streams within a specific OpenShift project.
- Easily track and monitor for security issues in their deployments.
- Configure a single integration for scanning images from all active registries.
- Use an image stream consistently across all the deployment cycle to not just scan images but also manage Image Assurance policies (that determine what constitutes acceptable risk) by image streams instead of image by image individually.
- Automatically scan image streams whenever a change is made, which is very similar to webhook/notification features available in other registries.
In the dynamic, fast-paced cloud native world, enabling this new capability becomes crucial for always being on top of the security status of your applications.
