IK.AM

Tanzu Application Platform 1.6から、ClusterBuildpack CRが追加されました。
それ以前は ClusterBuilder は ClusterStore (OSのベースイメージ) と ClusterStack (Buildpack集) から構成されていました。
1.6からは ClusterBuilder は ClusterStore (OSのベースイメージ) と複数の ClusterBuildpack で構成されます。
これにより、個別のBuildpackのアップデートが行いやすくなりました。

更新方法は
https://docs.vmware.com/en/VMware-Tanzu-Application-Platform/1.7/tap/tanzu-build-service-dependencies.html#update-dependencies-7
に記載されています。

実例を挙げます。TAP 1.7.0ではNode.jsのBuildpackとしてtanzu nodejs buildpack 2.3.1がインストールされています。
しかし、このBuildpackに含まれるNode.jsには CVE-2023-39332 (Critical) が存在します。

実際に、TAP 1.7.0でNode.jsのWorkloadをsource-test-scan-to-urlのSupply Chainでビルドすると、次のように脆弱性が検出されます。

TAP 1.7.0のままではCVE-2023-39332を無視するか、この脆弱性がFixされたbuildpackを含む新しいTAPのバージョンがリリースされるまでSupply Chainをストップさせるしかありません。
しかし、ClusterBuildpack が導入されたことにより、新しいbuildpackさえリリースされていれば、TAPのリリースを待たずにClusterBuilderを更新できます。

実際に、CVE-2023-39332は tanzu nodejs buildpack 2.3.2 でFixされました。

TAPのリリースを待たずに、このtanzu nodejs buildpack 2.3.2を適用してみます。

まずはbuildpackのDockerイメージを imgpkg コマンドでrelocateします。元となるイメージ名はTanzu Netから確認可能です。
lite dependenciesを使用している場合は末尾に-liteがつくものを、full dependenciesを使用している場合は-liteがつかないものを使用します。

ここでは ghcr.io/making 配下にrelocateします。

imgpkg copy -i registry.tanzu.vmware.com/tanzu-nodejs-buildpack/nodejs:2.3.2 --to-repo ghcr.io/making/tanzu-nodejs-buildpack/nodejs

relocateしたイメージを ClusterBuildpack の .spec.image に指定します。
.spec.serviceAccountRefに指定するService Accountは、relocateしたイメージをpullできるimagePullSecretsが設定されている必要があります。
わからない場合はkubectl get clusterbuildpack -ojsonpath='{.items[0].spec.serviceAccountRef}'で既存のClusterBuildpackが使用しているService Accountを確認できます。

以下はfull dependenciesを使用している場合に、tanzu nodejs buildpackを2.3.2に更新する例です。
名前の形式は、TAPに同梱されるものと被らないようにする方が良いでしょう。ここではドキュメント同様に out-of-band- をprefixとして使用しています。

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

同じIDを持つbuildpackが複数ある場合、ClusterBuilder はより新しいものを選びます。
これにより、TAP 1.7.0同梱のtanzu nodejs buildpack 2.3.1ではなく、2.3.2を使って ClusterBuilder が更新されます。

ClusterBuilder が更新されると、それを使用しているWorkloadのイメージは自動で再ビルドが行われます。これにより、Supply Chainの脆弱性チェックもパスできます。

この手法で、TAPをアップデートすることなくBuildpackを更新することができましたが、BuildpackのAPIバージョンやSBoMのバージョンの依存関係があるため、TAPのバージョンによっては最新のBuildpackだとエラーが起きる可能性がある点に注意してください。