chore: Allow external TLS configuration for ingress/routes

[tolusha]

What does this PR do?

This PR enables external tools (e.g., cert-manager) to inject TLS configuration into workspace ingresses/routes.
When externalTLSConfig=true:

1. The operator applies the provided annotations and labels.
2. For Kubernetes: the operator sets a unique secret name for each ingress (but does not create the secrets; they must be created by the external tool).
3. For OpenShift: the operator respects certificates injected by the external tool to prevent endless reconciliation loops.

Screenshot/screencast of this PR

N/A

What issues does this PR fix or reference?

eclipse-che/che#22935

How to test this PR?

1. Deploy the operator:

OpenShift

Create the CatalogSource and deploy Eclipse Che

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: eclipse-che-22935-4
  namespace: openshift-marketplace
spec:
  image: 'quay.io/eclipse/eclipse-che-olm-catalog:22935_4'
  sourceType: grpc

Deploy cert-manager

helm repo add jetstack https://charts.jetstack.io --force-update
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true  
helm install openshift-routes -n cert-manager oci://ghcr.io/cert-manager/charts/openshift-routes

on Minikube

./build/scripts/minikube-tests/test-operator-from-sources.sh

2. Log into Eclipse Che

3. Create Issuer/Certificate resources

USER_NAMESPACE=<USER_NAMESPACE>

oc apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: test-selfsigned
  namespace: ${USER_NAMESPACE}
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-selfsigned
  namespace: ${USER_NAMESPACE}
spec:
  isCA: true
  commonName: test-selfsigned-ca
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: test-selfsigned
    kind: Issuer
    group: cert-manager.io
  secretName: ca.crt
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: test
  namespace: ${USER_NAMESPACE}
spec:
  ca:
    secretName: ca.crt
EOF

4. Start and stop a workspace

5. Check that:

• all ingresses has the same tls secret (for minikube)
• routes doesn't contain certificates injected (for openshift)

6. Update CheCluster CR
   For minikube:

spec:
  devEnvironments:
    networking:
      externalTLSConfig:
        annotations:
          cert-manager.io/issuer: test
        enabled: true

For OpenShift:

spec:
  devEnvironments:
    networking:
      externalTLSConfig:
        annotations:
          cert-manager.io/issuer-name: test
        enabled: true

7. Start the same workspace workspace again

8. Check that:

• ingresses has its own tls secrets and all secrets are created (for minikube)
• routes contain certificates injected (for openshift)

9. Start a new workspace.

10. Check that:

• ingresses has its own tls secrets and all secrets are created (for minikube)
• routes contain certificates injected (for openshift)

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• Development resource are up to date
• The repository devfile is up to date and works
• Sections What issues does this PR fix or reference and How to test this PR completed
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[batleforc]

Is it possible to append the endpoint name to the secret-name ? It would allow the use of different secret name and allow Cert Manager to inject the certificate in the namespace

[tolusha]

Sorry, I am not very familiar how cert-manager works in details.
Does it create and set the secret? If there there are several ingress, will the same secret used?
What if secret is set TLS config?

[tolusha]

I see, cert-manager doen't set secret, it uses the on from the TLS config.

[batleforc]

Yes, and the best use case is to have one Secret by FQDN/Ingress

[batleforc]

https://cert-manager.io/docs/usage/ingress/

[batleforc]

Yes it is

[tolusha]

Could you provide steps to deploy and configure cert-manager on OpenShift cluster? I would like to test.

[batleforc]

This repo containe the needed step to have Cert manager handle Openshift Routes https://github.com/cert-manager/openshift-routes

[tolusha]

@batleforc
Minor changes, tested.
Please have a look.

[batleforc]

Look's good to me !

[rohanKanojia]

nit, Maybe we can replace assert with require for critical assertions here so that we fail fast.

Suggested change

	assert.Equal(t, 3, len(objs.Ingresses))
	require.Equal(t, 3, len(objs.Ingresses))

[tolusha]

/retest

[vinokurig]

Tested according to the PR description.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rohanKanojia, tolusha, vinokurig

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

Details

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