From Tanzu Application Platform 1.6, the ClusterBuildpack CR has been added. Before that, ClusterBuilder was composed of ClusterStore (OS base image) and ClusterStack (Buildpack set). From 1.6, ClusterBuilder is composed of ClusterStore (OS base image) and multiple ClusterBuildpacks. This makes it easier to update individual Buildpacks.
The update method is described here.
Let's give an example. In TAP 1.7.0, the tanzu nodejs buildpack 2.3.1 is installed as a Node.js Buildpack. However, this Buildpack includes Node.js with CVE-2023-39332 (Critical).
In fact, when you build a Node.js Workload in TAP 1.7.0 with the source-test-scan-to-url Supply Chain, vulnerabilities are detected as follows.
With TAP 1.7.0, you have no choice but to ignore CVE-2023-39332 or stop the Supply Chain until a new version of TAP containing a fixed buildpack is released. However, with the introduction of ClusterBuildpack, you can update the ClusterBuilder without waiting for the release of TAP, as long as a new buildpack is released.
In fact, CVE-2023-39332 was fixed in tanzu nodejs buildpack 2.3.2.
Without waiting for the release of TAP, let's apply this tanzu nodejs buildpack 2.3.2.
ℹ️ As of the time of writing this article, tanzu nodejs buildpack 2.3.2 is included in the latest version of TAP, 1.7.1.
First, relocate the Docker image of the buildpack with the imgpkg command. The original image name can be confirmed from Tanzu Net. If you are using lite dependencies, use the one with -lite at the end, and if you are using full dependencies, use the one without -lite.
Here, we will relocate under ghcr.io/making.
imgpkg copy -i registry.tanzu.vmware.com/tanzu-nodejs-buildpack/nodejs:2.3.2 --to-repo ghcr.io/making/tanzu-nodejs-buildpack/nodejs
Specify the relocated image in .spec.image of ClusterBuildpack. The Service Account specified in .spec.serviceAccountRef must have imagePullSecrets set to pull the relocated image. If you don't know, you can check the Service Account used by the existing ClusterBuildpack with kubectl get clusterbuildpack -ojsonpath='{.items[0].spec.serviceAccountRef}'.
The following is an example of updating the tanzu nodejs buildpack to 2.3.2 when using full dependencies. It is better to use a name format that does not overlap with those bundled with TAP. Here, we use out-of-band- as a prefix, as in the documentation.
kubectl apply -f - << 'EOF'
---
apiVersion: kpack.io/v1alpha2
kind: ClusterBuildpack
metadata:
name: out-of-band-nodejs-2.3.2
spec:
image: ghcr.io/making/tanzu-nodejs-buildpack/nodejs:2.3.2
serviceAccountRef:
name: dependencies-pull-serviceaccount
namespace: tbs-full-deps
---
EOF
If there are multiple buildpacks with the same ID, ClusterBuilder will choose the newer one. As a result, the ClusterBuilder is updated using 2.3.2 instead of the tanzu nodejs buildpack 2.3.1 included in TAP 1.7.0.
When the ClusterBuilder is updated, the images of the Workloads using it are automatically rebuilt. This allows you to pass the vulnerability check of the Supply Chain.
With this method, we were able to update the Buildpack without updating TAP, but please note that there may be errors depending on the version of TAP due to dependencies on the Buildpack API version and SBoM version.