Sample build strategies should be secure by default

[SaschaSchwarze0]

The sample build strategies in this project define to skip certificate validation when pushing to the target registry. This is done by default and not configurable. See:

• Buildah: https://github.com/redhat-developer/build/blob/2e19beaca342a85570410adc9845a26226879dc7/samples/buildstrategy/buildah/buildstrategy_buildah_cr.yaml#L31
• Kaniko: https://github.com/redhat-developer/build/blob/2e19beaca342a85570410adc9845a26226879dc7/samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml#L26
• Source2Image: https://github.com/redhat-developer/build/blob/2e19beaca342a85570410adc9845a26226879dc7/samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml#L45

We should ship samples that are secure by default. This means that certificate validation should NOT be disabled by default. Instead, it should be enabled. We could introduce a flag on the build cr to skip it.

[sbose78]

Yes the yet-to-be used spec.parameters section is for such not-so-common parameters that don't make sense to be strongly typed in the API but nice-to-have. :-)

A bit of history around why the SSL verification has been turned off : pushes to the registry were failing in case of internal registries because the service account didn't have th CA certificates mounted.

We need to define a contract so that the build controller can always look for CA certificates in a specific object. That way, we can actually hardcode SSL verify to true ( because that's the good practice!).

[zhangtbj]

I also agree we should be export this parameter to end-user. If I am the end-user, I want the SSL is always enabled to make sure the security.

And I have a question. about the history, Shoubhik.
When you talking about the internal registries, do you mean you faced some problem when you try to enable SSL for openshift internal registry?

And when you talking about the contract, do you mean it is a CA cert which is stored in SA? Or is there any document or link to introduce the background?

Thanks a lot! :)

[qu1queee]

I dont think this is high prio for now, if you folks allow me, I would like to add the icebox label.

[ghost]

So this means, there currently is no possibility to use a custom CA for my private container registry, or did I get that wrong?

[SaschaSchwarze0]

So this means, there currently is no possibility to use a custom CA for my private container registry, or did I get that wrong?

Nothing out of the box, but you can try to customize the build strategy, see https://kubernetes.slack.com/archives/C019ZRGUEJC/p1645000201441049?thread_ts=1644959006.747239&cid=C019ZRGUEJC for the idea.

[xiaocode]

So this means, there currently is no possibility to use a custom CA for my private container registry, or did I get that wrong?

Nothing out of the box, but you can try to customize the build strategy, see https://kubernetes.slack.com/archives/C019ZRGUEJC/p1645000201441049?thread_ts=1644959006.747239&cid=C019ZRGUEJC for the idea.

Could you post the article here plz?I can not enter this slack workspace...

[SaschaSchwarze0]

Hi @xiaocode, you can join that Slack workspace here: https://slack.k8s.io/

The referenced post is:

Okay, we are currently discussing a change where the push operation is not anymore performed by the build strategy step but instead by shipwright logic. This will enable us to offer capability like what you mention in a strategy-independent way. Your scenario fits very well. But, this will take some more time until this lands.
For the time being, you will need to extend the Kaniko build strategy. Basically you'll need a step before build-and-push which takes the certificate from an environment variable coming from a secret, and stores it in a file in a shared volumeMount also used by the build-and-push step. And then use the corresponding Kaniko argument. I don't have the time now to try that out.