Provide a way to specify a lifecycle or remove the hardcoded value during build

[andrew-su]

#Problem
In an attempt to use ghcr.io/vmware-tanzu/function-buildpacks-for-knative/functions-builder:0.2.0 to build a function (generated from some templates) using the func CLI. I ran into the following from func build -v:

[truncated]
pulling image quay.io/boson/lifecycle:0.13.2
0.13.2: Pulling from boson/lifecycle
Digest: sha256:b4493261d2be3e0aad701851f7a74d8ccc4dde18901d48469b77605da6fbfd65
Status: Image is up to date for quay.io/boson/lifecycle:0.13.2
Using build cache volume pack-cache-asfgd_x_latest-6f529a43b780.build
===> ANALYZING
Running the analyzer on OS linux with:
Container Settings:
  Args: /cnb/lifecycle/analyzer -gid 0 -log-level debug -daemon -stack /layers/stack.toml -run-image paketobuildpacks/run-jammy-base:0.1.8 -launch-cache /launch-cache localhost:5001/asfgd/x:latest
  System Envs: CNB_USER_ID=1001 CNB_GROUP_ID=1000 CNB_PLATFORM_API=0.9
  Image: quay.io/boson/lifecycle:0.13.2
  User: root
  Labels: map[author:pack]
Host Settings:
  Binds: /var/run/docker.sock:/var/run/docker.sock pack-cache-asfgd_x_latest-6f529a43b780.launch:/launch-cache pack-layers-wyanjsaagv:/layers pack-app-fkpaonxjjd:/workspace
  Network Mode: 
[analyzer] ERROR: failed to : set platform API: platform API version '0.9' is incompatible with the lifecycle
Error: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 11

I noticed that quay.io/boson/lifecycle:0.13.2 lifecycle is hardcoded into the pack options. However, the builder I was trying to use already specifies what lifecycle it needs. This may have caused a conflict between them.

Proposal:

1. Remove the hardcoded line and let pack determine the lifecycle from the builder.
2. Provide a way to specify a different lifecycle.

[andrew-su]

I removed the lifecycle and rebuilt the CLI locally and it was able to successfully build my function.

[lance]

/kind enhancement

[grafvonb]

/assign

[lance]

@grafvonb we discussed this in the WG call this week, and I think the immediate fix is to add the vmware builders to the list of trusted builders in

func/buildpacks/builder.go

Lines 37 to 41 in ea79cf0

	trustedBuilderImagePrefixes = []string{
	"quay.io/boson",
	"gcr.io/paketo-buildpacks",
	"docker.io/paketobuildpacks",
	}

That will address the immediate issue (along with this being a partial fix: #1403).

The longer term solution, I believe, will be to allow for global configuration of trusted builders using func config. Using an environment variable or a flag to override use of the internal lifecycle has security implications that we'd rather avoid.

[grafvonb]

@lance ok, got it, since it got an enhancement label I thought it was released for implementation. My idea was similar, means to make this available via a flag for func build or via configuration block in func.yaml. Your idea with func config is even better.

So please let me when the long term solution is "stable" 😄 (do we have a way here to recognize that?). Thx.

[lance]

@grafvonb happy to iterate on that long-term idea here (or in GH Discussions). Starting here for now and we can move it someplace else if we feel it needs wider visibility or a better format than just a bunch of comments.

I could see a func config builder command that allows the user to add/update/delete trusted builder image tags. But we'll also need to be thinking about runtime and build strategy in this context. E.g. the configuration option must allow the user to indicate whether the builder is for s2i or buildpack builds, and what runtime(s) it supports.

/cc @knative/func-reviewers @knative/func-writers @knative/functions-wg-leads

[wizpresso-steve-cy-fan]

@lance Please also add gcr.io/buildpacks/builder as trusted maybe, as I want to use the dotnet runtime