Use Dockerfile-based builds with Supply Chain Choreographer

This topic explains how you can use Dockerfile-based builds with Supply Chain Choreographer.

For source-based supply chains, when you specify the dockerfile parameter in a workload, the builds switch from using Kpack to using kaniko. Source-based supply chains are supply chains that don’t take a pre-built image. kaniko is an open-source tool for building container images from a Dockerfile without running Docker inside a container.

Parameter name	Description	Example
`dockerfile`	The relative path to the Dockerfile file in the build context.	./Dockerfile
`docker_build_context`	The relative path to the directory where the build context is.	.
`docker_build_extra_args`	The list of flags to pass directly to kaniko, such as providing arguments to a build.	- --build-arg=MY_KEY=MY_VALUE

Example 1

To build a container image from the github.com/my-foo/bar repository where the Dockerfile resides in the root of that repository, you can switch from using Kpack to building from that Dockerfile by passing the dockerfile parameter:

$ tanzu apps workload create my-foo \
  --git-repo https://github.com/my-foo/bar \
  --git-branch dev \
  --label app.kubernetes.io/part-of=foo \
  --param dockerfile=./Dockerfile \
  --type web

🔎 Create workload:
      1 + |---
      2 + |apiVersion: carto.run/v1alpha1
      3 + |kind: Workload
      4 + |metadata:
      5 + |  labels:
      6 + |    apps.tanzu.vmware.com/workload-type: web
      7 + |  name: my-foo
      8 + |  namespace: dev
      9 + |spec:
     10 + |  params:
     11 + |  - name: dockerfile
     12 + |    value: ./Dockerfile
     13 + |  source:
     14 + |    git:
     15 + |      ref:
     16 + |        branch: dev
     17 + |      url: https://github.com/my-foo/bar

Example 2

If the context to be used for the build must be set to a different directory within the repository, use the docker_build_context parameter to change that:

$ tanzu apps workload create my-foo \
  --git-repo https://github.com/my-foo/bar \
  --git-branch dev \
  --param dockerfile=MyDockerfile \
  --param docker_build_context=./src

Important
This feature has no platform operator configurations to be passed through the tap-values.yaml file, but if ootb-supply-chain-*.registry.ca_cert_data or shared.ca_cert_data is configured in tap-values, the certificates are considered when pushing the container image.

OpenShift

kaniko can perform container image builds without a Docker daemon or privileged containers. It does require the use of:

Capabilities usually dropped from the more restrictive SecurityContextConstraints (SCC) enabled by default in OpenShift.
The root user.

To overcome the limitations imposed by the default unprivileged SCC, Tanzu Application Platform installs:

SecurityContextConstraints/ootb-templates-kaniko-restricted-v2-with-anyuid with enough extra privileges for kaniko to operate.
ClusterRole/ootb-templates-kaniko-restricted-v2-with-anyuid to permit the use of SCC to any actor binding to that cluster role.

Each developer namespace needs a role binding that binds the role to an actor: ServiceAccount. For example:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: workload-kaniko-scc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ootb-templates-kaniko-restricted-v2-with-anyuid
subjects:
  - kind: ServiceAccount
    name: default

With the SCC created and the ServiceAccount bound to the role that permits the use of the SCC, OpenShift accepts the pods created to run kaniko to build the container images.

For more information, see Set up developer namespaces to use your installed packages.

For more information about SCC, see the OpenShift documentation.

Tanzu Kubernetes Grid and clusters with PSA enabled

Tanzu Kubernetes Grid v1.26 and later clusters with the Pod Security admission feature enabled and set to enforce cannot run kaniko without configuration changes. This is because the webhook requires containers to run as a non-root user and kaniko needs to run as a root user. This kaniko limitation relates to how image builds are run.

To workaround this limitation, label the namespace that kaniko runs as privileged. For example:

pod-security.kubernetes.io/enforce: privileged

For more information about this kaniko limitation, see the kaniko documentation.

For more information about the Pod Security admission feature, see the Kubernetes documentation.