X

The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

Oracle Cloud Infrastructure Container Image Scanning, Signing, and Verification

Mickey Boxell
Product Management

We are excited to announce the general availability of container image scanning, signing, and verification. This new suite of capabilities helps you ensure the security of your cloud native software deployments.

Imagine a software development team working to deliver a business-critical application that passes sensitive data. A developer commits code to a continuous integration and continuous delivery (CICD) tool kicking off a build process. Then, the CICD tool pushes the newly built container image to an Oracle Cloud Infrastructure Registry (OCIR) repository and when ready, the new image is deployed to a production Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE) cluster.

While this CICD process sounds reasonable, it is missing few key steps. Critical to shipping compliant and secure containers, system administrators need to ensure that container images have the following characteristics:

  • Are free of known critical vulnerabilities that can cause an accidental system failure or result in malicious activity.

  • Have not been modified since they were published to maintain their integrity.

  • Are only deployed to a Kubernetes cluster and come from a trusted source.

OCI container image scanning, signing, and verification address all these secure container deployment needs.

Scanning images

OCI Registry enables users or systems to push container images to repositories. You can now enable scanning of container images stored in OCI Registry for security vulnerabilities that are published in the publicly available Common Vulnerabilities and Exposures (CVE) database. When repository scanning is enabled, the OCI Vulnerability Scanning service scans any images that you push into the repository and images that are already present. Repositories with scanning enabled are automatically rescanned when new vulnerabilities are added to the list of threats. For every scanned image, you can view the scan results, the risk level for each scan, the description of each vulnerability, and the link to the CVE database.

A screenshot of the Registry page for the cpt root) compartment in the Console.

Signing images

To ensure that images are not modified after being pushed, you can now sign an image in OCI Registry, using master encryption keys stored in OCI Vault. You can view signatures and verify that the image signatures have not changed, ensuring that the integrity of the image has not been compromised.

Deployment verification

Finally, you can configure OCI Container Engine for Kubernetes with a cluster-specific policy to allow only container images in OCI Registry that a particular master encryption key has signed, to be deployed to a cluster. Images without the correct signature are denied.

A graphic depicting the process for building, pushing, scanning, signing, validating, and deploying an image.

Bringing it together with image scanning, signing, and verification

With these tools working together, users or systems can be confident that only resilient images from a trusted source are deployed to their mission-critical Kubernetes clusters. Imagine that the previously mentioned software development team adopts OCI container image scanning, signing, and verification. When a developer commits code, a build process kicks off and their CICD tool pushes the newly built container image to an OCIR repository with scanning enabled. The following process occurs:

  • OCI Vulnerability Scanning service scans the image upon ingestion.

  • A security administrator reviews the vulnerability score.

  • After determining the vulnerability score is acceptable, they sign the image with an asymmetric key, stored in the OCI Vault service.

  • A Kubernetes administrator configures a policy requiring all images deployed to the production cluster to be signed by the security administrator’s key.

  • A developer deploys a manifest to the Kubernetes cluster that references the container image and, because the signature on the image matches the signature in the policy, the image is successfully deployed to the cluster.

Want to know more?

To learn more, see the following resources:

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha