Support insecure registries in non-daemon case

[jromero]

Summary

As a developer, I'd like to be able to publish app images to an "insecure" registry in the non-daemon case.

(NOTE: I mention non-daemon case because the daemon case is controlled/configured via Docker Desktop.)

Currently, this partly works in some local setups because GGCR attempts to detect protocol.

In my current development environment, it doesn't work because I'm routing to the registry from inside a container and thereby referencing it as host.docker.internal which doesn't match GGCR's logic.

A potential solution may be to go to GGCR and request that host.docker.internal be added to their detection logic BUT it seems like this may be desirable in other scenarios. (See prior art).

Proposed Solution

Since there are multiple images at play sometimes, instead of a single global flag --insecure (like kaniko) add a variadic flag + matching character separated env var for insecure registries.

For example:

analyzer --insecure-registry=my-registry.com/here/  --insecure-registry=host.docker.internal

CNB_INSECURE_REGISTRIES="my-registry.com/here/;host.docker.internal"
analyzer ...

Prior Art

• kaniko
• crane

[jabrown85]

Discussion on Feb 11 - Attendees agree and an RFC will be produced to capture details.

[jromero]

Another platform specific use case (Tekton) where this feature would be useful: buildpacks/tekton-integration#31 (comment)

[wanjunlei]

Any progress on this? Or is there a definite plan? Is there anything I can do?

[natalieparellano]

Thank you, @wanjunlei - at this point, I believe what we'd need to move forward is an RFC defining the user interface to the lifecycle (it could build off of @jromero's proposal above or be something different). Would you be interested in helping with that? If so, I'd be happy to help guide you through the process. You can find me as narellano in CNCF Slack for real-time conversation.

[wanjunlei]

I had created an RFC buildpacks/rfcs#229 @natalieparellano .

[wanjunlei]

Hi @natalieparellano , the RFC had merged, what do I need to do next, start coding or update the platform API?

[jjbustamante]

Hi @wanjunlei, the final implementation requires several updates in different repositories. the following tracking issue was created to follow up that work.

The issues there are marked as to be done, so in my opinion you can start working on the lifecycle implementation, later we can work on creating and filling the issues on the other repositories. Also, you can create a draft PR in the spec repository and start collecting feedback there, once the issue is created in the spec repo you can link the PR to it.

[wanjunlei]

Hi @wanjunlei, the final implementation requires several updates in different repositories. the following tracking issue was created to follow up that work.

The issues there are marked as to be done, so in my opinion you can start working on the lifecycle implementation, later we can work on creating and filling the issues on the other repositories. Also, you can create a draft PR in the spec repository and start collecting feedback there, once the issue is created in the spec repo you can link the PR to it.

OK, I will start working on the lifecycle implementation first.

[natalieparellano]

Most of the work was already done in #1140 - but, we need to expose this functionality by declaring the lifecycle supports Platform 0.13

[natalieparellano]

I'm going to close this one out as #1287 will likely add 0.13 to the list of supported Platform APIs.