This chapter is from the book
This chapter is from the book
This chapter is from the book
Working with OCIR
As a fully managed service, OCIR ensures that you can reliably store and serve your container images without managing or scaling the storage and other infrastructure resources typically required for running and operating a container image registry. OCIR supports both public and private access to container images managed by the service. To expose an image publicly, you do not need any resources (such as an Internet gateway or a load balancer) in your tenancy because the service is fully managed. When working with private images, you can efficiently access the registry through a service gateway in your virtual cloud network (VCN), which ensures that the resources that access the images can do so in a highly efficient and secure manner, completely within the OCI network fabric. If an image is exposed publicly, the image can still be accessed over a service gateway by resources inside OCI for better throughput, and the image will also be publicly available over the Internet. Private registries are ideal in environments where Internet access is disallowed for security reasons.
Image Signing
The ease of creating and distributing container images comes with an increased exposure to security vulnerabilities. Container images provide a way to build software packages in layers, with developers building on top of popular open-source images that provide basic functionality and runtimes (such as Java) and then laying down their application binaries and artifacts on top of these base layers to create the final image. From a security perspective, developers need to ensure not only that their own software is secure, but also that every layer in their final container image, including the layers that they built on top of, are secure and free from vulnerabilities. They also must consider the possibility of image tampering, in which a malicious actor injects security vulnerabilities into an image. Therefore, to ensure a secure container supply chain, you must ensure that the container images (and each layer that makes up an image) are free from vulnerabilities and that you can verify that the image came from a trusted source and has not been tampered with.
To ensure the provenance of container images that you use in your environments, the OCIR service supports image signing. Image signing is a way to confirm that the container images you are deploying come from a trusted source and to verify that these images have not been tampered with. With OCIR, you can use asymmetric cryptographic keys to ensure the authenticity of an image’s origin and guarantee its integrity. The developer (or the CI process) building the image pushes the image to OCIR. This creates the image in OCIR and assigns an OCID for the image. Now the developer can sign the image with a master encryption key stored in the OCI Vault service and associate the signature with the image’s OCID. For better security, OCIR supports only asymmetric key algorithms, such as RSA or ECDSA; symmetric key algorithms such as AES are not supported.
When a client such as a Kubernetes cluster validates the signature, the Vault service is checked to ensure that the signature is valid. The service also ensures that the user who pushed the image into the registry had access to the master encryption key at the time the image was signed. The signature is based on the content of the image; any tampering or changes to the image invalidate the signature. This gives users or systems pulling a signed image from OCIR confidence that the source of the image is trusted and that the image has not been tampered with. To further ensure security within the container image supply chain, other OCI services, such as Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE), can be configured to accept only signed images. Figure 3-2 illustrates the signatures for an image in OCIR and shows the results of a signature verification. After an image in OCIR has been signed, the signature can be verified at any time.
)
FIGURE 3-2 OCIR Showing a Repository with Signed Images and Image Signature Verification
Image Scanning
OCIR also supports image scanning to identify vulnerabilities in your container images. These vulnerabilities could be within the application you are developing or within the tools or runtimes that exist on the base layers of the image you are building upon. Image scanning can be enabled on a per-repository basis by adding a scanner to the repository. The scanner looks for vulnerabilities published in the publicly available Common Vulnerabilities and Exposures (CVE) database.
The scanner is powered by the Oracle Cloud Infrastructure Vulnerability Scanning Service, and it also provides a Vulnerability Scanning REST API that you can integrate into your CI pipeline so that a build pipeline can build an image, push it to an OCIR repository, and programmatically get scanning results. This enables you to integrate image scanning into your development pipeline so that you can identify images with vulnerabilities as early as possible and then create CI/CD workflows that can prevent the images from being promoted to critical environments. Figure 3-3 shows the result of an image scan, summarizes the issues found for the image, and gives details on each CVE that has been identified.
When enabling the scanner on a repository that already has images in it, the most recent four images are scanned immediately. The scanner produces a report showing an overall risk assessment for the image based on the scan, as well as the individual vulnerabilities found and their risk levels, with pointers to the CVE database for more information on the vulnerability. OCIR automatically scans the images as new vulnerabilities are added to the CVE database and retains the scan results for a period of 13 months so that the risk level of the image can be assessed over time.
)
FIGURE 3-3 Scan Results for an Image Showing the CVEs That Are Identified on That Image, with Risk Levels, Descriptions, and Links to the CVE Database
Creating Containers from Images
After a container image has been created and pushed to a container image repository, the next logical step is to create a running container from this image. A container runtime, or a container engine, is the software that can run containers on a host operating system.
The container runtime uses the host operating system kernel’s capabilities to create isolated sandboxes for processes with resource limits. The container runtime uses the metadata in the image to configure the isolated execution environment that has been created using the underlying kernel features, union mount the image layers, and configure the mount as the root file system for the isolated environment. Typically, this is done through operating system–level isolation and virtualization, such as with cgroups, namespaces, and chroot in Linux, or Hyper-V in Windows.
Oracle Cloud infrastructure offers several choices to run and manage container workloads, from the basic approach of running and managing containers on compute instances to fully autonomous and serverless offerings.