Support disabling shared workspace endpoint TLS secret when externalTLSConfig is enabled for DevWorkspace endpoints

[simxr]

Description

Summary

When external TLS handling is enabled for DevWorkspace endpoints, DevWorkspace routing should avoid creating an additional shared workspace-level TLS secret unless it is strictly required / make it configurable.

Observed with:

• Eclipse Che Operator Helm chart: 7.116.0
• DevWorkspace Operator: v0.40.0

In a CheCluster configured with:

devEnvironments:
  networking:
    externalTLSConfig:
      enabled: true

DevWorkspaceRouting can still create a shared TLS secret in the workspace namespace:

workspace-<devworkspace-id>-endpoints

This secret is owned by the generated DevWorkspaceRouting resource.

In observed deployments, this secret can copy/reuse TLS material from the main Eclipse Che TLS certificate. If this copied certificate material becomes stale, expires, or diverges from the active Che/external TLS configuration, workspace namespaces may retain stale certificate material for the Che/workspace domain.

This is especially risky in wildcard-certificate deployments. If both a valid wildcard certificate and a stale workspace-level certificate match the same requested SNI, the ingress controller may select the stale or more specific certificate, resulting in an expired or unintended certificate being served.

This creates split TLS ownership:

externalTLSConfig.enabled: true
  -> endpoint/ingress TLS is expected to be handled externally through configured annotations/labels

DevWorkspaceRouting
  -> still creates workspace-<id>-endpoints TLS secret
  -> may copy/reuse Che TLS certificate material

The request is to avoid creating this shared endpoint TLS secret when external TLS is enabled, or provide a clear way to disable/control this behavior.

---

Relevant CRD Context

In DevWorkspace Operator v0.40.0, external TLS configuration exposes:

networking:
  externalTLSConfig:
    enabled: boolean
    annotations: map[string]string
    labels: map[string]string

This allows platform teams to attach annotations and labels for ingress/route TLS automation.

However, there does not appear to be a first-class field in DevWorkspaceRouting or DevWorkspaceOperatorConfig to control whether the shared workspace-level endpoint TLS secret should be created, reused, or skipped when TLS is handled externally.

Cleanup controls such as workspace.cleanupOnStop and workspace.cleanupCronJob help remove stale resources, but they are cleanup mechanisms, not controls over whether the shared TLS secret should be created.

---

Current Behavior

For secured/exposed workspace endpoints, DevWorkspaceRouting may create:

workspace-<devworkspace-id>-endpoints

This can happen even when external TLS handling is enabled through CheCluster.devEnvironments.networking.externalTLSConfig.

This creates ambiguity around:

• whether external TLS automation or DevWorkspaceRouting owns endpoint TLS
• whether generated ingress/route resources still need this secret
• whether copied TLS material is renewed with the same lifecycle
• whether stale TLS material can remain after workspace lifecycle events

---

Expected Behavior

When external TLS handling is enabled, DevWorkspace routing should either:

1. avoid creating the shared workspace-<devworkspace-id>-endpoints TLS secret, or

2. provide an explicit option to disable creating this shared secret, or

3. ensure the secret is not referenced by generated ingress/route resources and is safely cleaned up when unused.

The desired ownership model is:

External TLS enabled
  -> generated ingress/route receives configured annotations/labels
  -> external TLS mechanism owns certificate lifecycle
  -> no additional shared endpoint TLS secret is created unless explicitly required

---

Why This Matters

A shared endpoint TLS secret can leave stale or overlapping TLS material in workspace namespaces.

In wildcard-certificate deployments, stale workspace-level certificates can create SNI collision risk where both the wildcard certificate and an older workspace-level certificate match the same requested hostname.

This can cause:

• stale or expired certificates being served
• confusing certificate selection behavior
• endpoint access failures
• browser/WebSocket failures for secured endpoints
• dependency on manual cleanup or scheduled cleanup jobs

The broader issue is that generated shared TLS material can remain present even after TLS lifecycle has been delegated to external ingress/route-level automation.

---

Reproduction / Validation Steps

1. Deploy Eclipse Che Operator Helm chart 7.116.0 with DevWorkspace Operator v0.40.0.

2. Configure the CheCluster with external TLS handling enabled:

devEnvironments:
  networking:
    externalTLSConfig:
      enabled: true
      annotations:
        <external-tls-annotation-key>: <value>
      labels:
        <external-tls-label-key>: <value>

3. Start a workspace with one or more secured exposed endpoints.

4. Inspect generated routing resources and secrets:

kubectl get devworkspacerouting -n <workspace-namespace>
kubectl get ingress,route -n <workspace-namespace>
kubectl get secret -n <workspace-namespace>

5. Check whether a shared endpoint secret exists:

workspace-<devworkspace-id>-endpoints

6. Verify whether generated ingress/route resources reference this secret or whether TLS is already delegated externally through annotations/labels.

7. Stop/delete the workspace and confirm whether the shared endpoint secret is removed reliably.

---