add ingressHostnamePrefixes to AppDefinition. This is a list that makes sures that these additional prefixes to the specified hostname will also be added in the ingress. This is a property of the AppDefinition since this can be configured on Theia side and may vary between app definitions.
update ingress rules accordingly with additional values from ingressHostnamePrefixes
Testing is easiest with the sub domain based Theia Cloud version, since this one generates all certificates itself.
Our path based minikube test version is configured to reuse the same certificate as generated for keycloak.
We added the hosts.paths.tlsSecretName value, which allows to provide fitting certificates via the secrets for each ingress (manually if needed).
This + the ingress.certManagerAnnotations allows the user to specify the certificates on a (remote) cluster, even without the cert manager.
For getting wildcard certificates from cert-manager we need to configure a DNS01 challenge: https://cert-manager.io/docs/configuration/acme/dns01/
Depending on the DNS provider this requires different configuration, so we cannot really provide a default here.
In the short run being able to provide the tls cert via a secret should be enough to get it working on all providers.
In the long run we have to extend our documentation and maybe the helm values/templates as we learn more about how people want to configure this.
Go to chrome://settings/certificates -> Authorities -> Import -> Select ca.crt -> Trust for identifying websites
Go to Theia Cloud Landing Page
(Accept Keycloak Certificate warning, if any)
Start a session, upload a vsix with a webview sample via drag and drop
Test WebViews
You may also check the ingress yaml to see the added paths
Shutdown 2-01_try-now
Test that the hosts.paths.tlsSecretName and ingress.certManagerAnnotations are working. With these options all use cases should be possible, since we may provide own tls secrets (without cert-manager if required)
Testing paths can be done like this (it's a bit messy, since multiple ingresses requests certs for the base domain, and I think the keycloak one wins, since it's the first one. However for the webviews the right cert is used so that it can be tested. )
Open 2-03_try-now_paths/theia_cloud.tf and add set { name = "hosts.paths.tlsSecretName" value = true }
also see https://github.com/eclipsesource/theia-cloud-helm/pull/57
Closes #296
Testing is easiest with the sub domain based Theia Cloud version, since this one generates all certificates itself.
Our path based minikube test version is configured to reuse the same certificate as generated for keycloak. We added the
hosts.paths.tlsSecretNamevalue, which allows to provide fitting certificates via the secrets for each ingress (manually if needed). This + theingress.certManagerAnnotationsallows the user to specify the certificates on a (remote) cluster, even without the cert manager.For getting wildcard certificates from cert-manager we need to configure a DNS01 challenge: https://cert-manager.io/docs/configuration/acme/dns01/ Depending on the DNS provider this requires different configuration, so we cannot really provide a default here.
In the short run being able to provide the tls cert via a secret should be enough to get it working on all providers. In the long run we have to extend our documentation and maybe the helm values/templates as we learn more about how people want to configure this.
Testing instructions:
WebView VSIX can be created with these two projects: WebView Sample: https://github.com/microsoft/vscode-extension-samples/tree/main/webview-sample WebView based EDitor Sample: https://github.com/microsoft/vscode-extension-samples/tree/main/custom-editor-sample
Check out this branch and https://github.com/eclipsesource/theia-cloud-helm/pull/57
Build the docker images
Local Testing / Sub Domain Based Theia Cloud
kubectl get secret theia-cloud-ca-key-pair -n cert-manager -o jsonpath='{.data.tls\.crt}' | base64 --decode > ca.crtTest that the
hosts.paths.tlsSecretNameandingress.certManagerAnnotationsare working. With these options all use cases should be possible, since we may provide own tls secrets (without cert-manager if required)Testing paths can be done like this (it's a bit messy, since multiple ingresses requests certs for the base domain, and I think the keycloak one wins, since it's the first one. However for the webviews the right cert is used so that it can be tested. )
set { name = "hosts.paths.tlsSecretName" value = true }kubectl get secret theia-cloud-ca-key-pair -n cert-manager -o jsonpath='{.data.tls\.crt}' | base64 --decode > ca.crtFor more testing see this WIP documentation about custom certificates and how to create wildcard certificates with Let's encrypt manually: https://github.com/eclipsesource/theia-cloud-website/pull/32 https://deploy-preview-32--theia-cloud.netlify.app/documentation/moredocumentation/#custom-certificates