Introducing Security and Integrity in CI/CD Pipeline
With the Oracle Cloud Infrastructure’s (OCI) newly added container image scanning, signing, and verification features, all the business-critical, cloud-native applications processing sensitive data can now be securely deployed into the Oracle Kubernetes Container Engine (OKE), without upsetting the existing CI/CD action timeline.
Until now, the deployment cycle only comprised of committing code to CI/CD tool, followed by having the newly built container image pushed to an OCI Registry repository (a.k.a. OCIR), and lastly, deploying the image to the OCI Kubernetes Container Engine cluster (OKE). The pipeline although appeared logical, it lacked three critical considerations pertaining to the security of the classified data.
- Protection against the known critical vulnerabilities capable of inviting unwarranted system failures, induced accidentally, or by cyber attackers
- Protection against unwanted modifications
- Trusted sourcing and strict deployment to a Kubernetes cluster
And, this is precisely where the OCI container image scanning, signing, and verification come into play, in meeting all the security requirements of a successful container image deployment. To gauge its significance, let us decrypt each of the security features separately in the coming section, followed by assessing the ‘symbiotic’ effect of the three operating together.
The OCI Vulnerability Scan for container images
In the chronological order, the first security feature in the series is scanning the container images placed in the OCI Registry, against the CVEs – Common Vulnerabilities and Exposures database – available in public domain. Upon enabling the repository scanning, the OCI Vulnerability Scan service begins scrutinizing any image pushed into the repository, as well as the existing ones that were there prior to enabling the service.
Smartly enough, the OCI Vulnerability Scanning service also automatically reruns when a new vulnerability is introduced in the CVEs database. Besides, all scanned container images have a separate scan report/results, with the level of risk detected, an explanation for each vulnerability, and the hyperlink to the vulnerability recorded in the CVE database.
OCI Vault-powered container image signing
For preventing the container images to accept any alterations following the push, administrators / developers can now sign them in the OCI Registry, leveraging the master encryption keys available in the OCI Vault. Users may also discover signatures, and readily authenticate the integrity of the images depending on the altered or unaltered properties of the signatures.
Using cluster-specific policies for verification
The third and final security feature is the ability of the users to configure OCI Container Engine for Kubernetes via cluster-specific policies in permitting only the unique master encryption key signed container images in the OCI Registry, and their deployment to a cluster. Note: Any container image devoid of the correct signature is rejected.
The symbiosis of scanning, signing, and verification
Once all the three features are enabled to operate in cohesion, and create the intended robust security symbiosis, users / systems will be guaranteed regarding the safety and integrity of their container images, that are also reliably sourced – deployed into their business-critical Kubernetes clusters.
To reimagine the earlier deployment cycle – however this time, having enabled the new OCI container image scanning, signing, and verification security features, the scenario will be a bit different. After the commitment of the code, the building process will begin, with CI/CD tool pushing the new container image into OCIR repository, resulting in the below security events to set in motion:
- A thorough scanning of the container image via the OCI Vulnerability Scanning service post ingestion
- The vulnerability score made public to the administrator / developer
- Upon learning the vulnerability score to be within limits, users signing the container image with the help of the OCI Vault service
- A cluster-specific policy is set by the Kubernetes administrator that will bind the container images deployed in the production cluster to have signed with a particular master encryption key
- The user will also deploy a manifest to the Kubernetes cluster containing the references to the container image. And, due to the signature on the image being ‘true’ to the user-defined policy, the container image is effectively deployed to the targeted cluster
