fix: Ignore certificate check on fetch devworkspace template

[vinokurig]

What does this PR do?

In order to fix the x509: certificate signed by unknown authority error ignore certificate check on fetch devworkspace template.

What issues does this PR fix or reference?

https://github.com/devfile/devworkspace-operator/issues/1248

Is it tested? How?

Apply a workspace, from a devfile that has a nested parent devfile which is hosted on a service with self signed certificate:

schemaVersion: 2.2.0
metadata:
  name: sample-using-parent
parent:
  uri: <url to the parent devfile>

parent devfile:

schemaVersion: 2.2.0
metadata:
  name: parent-devfile

PR Checklist

• [ ] E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • [ ] v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • [ ] v8-che-happy-path: Happy path for verification integration with Che

[openshift-ci[bot]]

Hi @vinokurig. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vinokurig Once this PR has been reviewed and has the lgtm label, please assign dkwon17 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/devfile/devworkspace-operator/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[AObuchow]

/ok-to-test

[AObuchow]

I've opened https://github.com/devfile/devworkspace-operator/issues/1248 as the related issue to this PR.

[ibuziuk]

@tolusha could you please review?

[tolusha]

Why not to add configuration with a secret storing extra certificates? This secret can be created by che-operator. It is better than ignoring insecure connections.

[AObuchow]

Why not to add configuration with a secret storing extra certificates? This secret can be created by che-operator. It is better than ignoring insecure connections.

+1, maybe something along the lines of adding into the DWOC config.routing.TLSCertificateSecret (might not be the best name for the field..). The field would let you specify the name and namespace of the secret. The name and namespace could then be used to get the secret and use its contents for the http transport object configuration.

If this approach is taken, we'd have to also modify the DWO controller to watch for Secrets that were created by the Che-Operator. The secrets could maybe contain a label (e.g. controller.devfile.io/tls-cert) that allows us to uniquely identify them. For reference, here we setup a watch for secrets that have been automounted . When a secret is created, deleted or updated, we check which labels it contains, and if it contains an automount-related label, a reconcile is triggered for all running workspaces. A similar approach would have to be taken, but for secrets containing the TLS cert label.

I can help out with this process further or even add extra commits if desired.

[tolusha]

My suggestion:

TLSCertificateSecretRef *types.SecretReference

[vinokurig]

Working on an approach with injecting tls certificate