[installer]: allow the s3 connection to be insecure

[mrsimonemms]

Description

We often tell people that, if they're unable to use the configuration of the in-cluster Minio that they should deploy their own to their cluster and connect to it over the Kubernetes core DNS. However, this isn't currently possible because the S3 connection expects for it to be over HTTPS. When using a local Kubernetes endpoint, this is likely to be over HTTP.

This allows for an S3 endpoint to use an insecure URL.

The default expectation of it being over HTTPS has not changed.

Fixes #6776
Fixes #9698
Fixes #12416

How to test

Deploy the KubeCon demo instance (run make on an Ubuntu machine). We need this for KubeCon as the default 8Gi PVC is not large enough, so need to configure a larger PVC.

Release Notes

[installer]: allow the s3 connection to be insecure

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[mrsimonemms]

/werft run publish-to-kots

👍 started the job as gitpod-build-sje-demo.1
(with .werft/ from main)

[mrsimonemms]

/werft run publish-to-kots

👍 started the job as gitpod-build-sje-demo.3
(with .werft/ from main)

[mrsimonemms]

/werft run

👍 started the job as gitpod-build-sje-demo.5
(with .werft/ from main)

[aledbf]

@mrsimonemms why? we should not say yes to everything. Having SSL for S3 is not too much to ask.

[mrsimonemms]

@aledbf it's so we can use a Minio instance that's deployed in the cluster, but not the in-cluster configuration that we provide. For the longest time, we've said that people are able to configure their own Minio instance and then talk to it locally, but this is not actually the case - the in-cluster Minio connects via HTTP and this allows a user to configure their own Minio on their machine and route through there.

One example is that this will allow users to configure S3 instances that don't use regions in the URL (eg, DigitalOcean/Storj.io) or where they want to use an in-cluster solution, but an 8Gi PVC isn't big enough (eg #9698 or #12416)

[nandajavarma]

/werft run with-sh-preview=true

👍 started the job as gitpod-build-sje-demo.7
(with .werft/ from main)

[nandajavarma]

Tests looked good! https://werft.gitpod-dev.com/job/gitpod-k3s-installer-tests-head.28