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?

#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]

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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

[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

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 #1248 as the related issue to this PR.

[ibuziuk]

@vinokurig but this means that we are skipping verification of TLS for every single request, no?

[AObuchow]

@ibuziuk this is my understanding as well. Previously, we were only skipping TLS verification for the health check

[AObuchow]

It might make more sense to add a DevWorkspace Operator Config field to allow disabling the TLS verification which users on an air-gapped cluster would toggle on.

[vinokurig]

Added the property, @AObuchow please take a look.

[AObuchow]

Overall looks good to me if we're going with the approach of enabling/disabling TLS verification (one small note in my next comment below about modifying the DevWorkspace Operator Config though). I do think @tolusha's suggestion of using certificates retrieved from a secret is more optimal than my suggestion, though.

Additionally, we have to commit to any changes made to the DevWorkspace Operator Config since these are considered API changes, and we unfortunately can't easily remove any fields we add. So taking my simpler approach first, and then implementing @tolusha's suggestion later on would mean we'd have to keep DisableTLSVerification in the DevWorkspace Operator Config.

Thankfully, though both my suggestion and @tolusha's suggestion would resolve #1248, they both provide different functionality and would not necessarily be redundantly overlapping each other if we were to support both fields in the DevWorkspace Operator Config. So implementing both approaches would not be redundant. @ibuziuk @tolusha @dkwon17 if any of you have any input on whether we should take a simpler approach first or not, please feel free to share.

[AObuchow]

Regarding adding a new DevWorkspace Operator Config field, two areas need to be addressed:

1. Modifications need to be made to mergeConfig() and GetCurrentConfigString() in sync.go.

In mergeConfig() we need to copy over the values of the new DisableTLSVerification field, something like:

	if from.Routing != nil {
		if to.Routing == nil {
			to.Routing = &controller.RoutingConfig{}
		}
		if from.Routing.DefaultRoutingClass != "" {
			to.Routing.DefaultRoutingClass = from.Routing.DefaultRoutingClass
		}
		if from.Routing.ClusterHostSuffix != "" {
			to.Routing.ClusterHostSuffix = from.Routing.ClusterHostSuffix
		}
		if from.Routing.ProxyConfig != nil {
			if to.Routing.ProxyConfig == nil {
				to.Routing.ProxyConfig = &controller.Proxy{}
			}
			to.Routing.ProxyConfig = proxy.MergeProxyConfigs(from.Routing.ProxyConfig, defaultConfig.Routing.ProxyConfig)
		}
+		if from.Routing.DisableTLSVerification != nil {
+			to.Routing.DisableTLSVerification = from.Routing.DisableTLSVerification
+		}
	}

And in GetCurrentConfigString() we need to declare if DisableTLSVerification is enabled. Something like:

	if routing != nil {
		if routing.ClusterHostSuffix != "" && routing.ClusterHostSuffix != defaultConfig.Routing.ClusterHostSuffix {
			config = append(config, fmt.Sprintf("routing.clusterHostSuffix=%s", routing.ClusterHostSuffix))
		}
		if routing.DefaultRoutingClass != defaultConfig.Routing.DefaultRoutingClass {
			config = append(config, fmt.Sprintf("routing.defaultRoutingClass=%s", routing.DefaultRoutingClass))
		}
+		if routing.DisableTLSVerification != nil && *routing.DisableTLSVerification {
+			config = append(config, "routing.DisableTLSVerification=true")
+		}
	}

You can run make test to make sure everything's working as expected. In particular, this test should be passing.

2. The CRDs need to be re-generated since a new field was added to the DevWorkspace Operator Config. Run the following, and add the resulting changes into a separate commit: make generate manifests fmt generate_default_deployment generate_olm_bundle_yaml

[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