This is related to #127 but not specific to Backstage.
Problem:
Currently, we rely on the default TLS certificate baked in the ingress-nginx controller image to establish TLS sessions for all incoming connections. This works for accessing web UIs from browsers as long as they click on the accept risk button.
This is not so easy for applications. When we want to point an application to the https port on the ingress-nginx service, it will raise an TLS error because it's self-signed and SANs will not match.
To overcome this kind of TLS issues, many applications provide an option to skip TLS verification steps altogether. This is obviously not a good practice.
A better approach would be to provide the CA cert to applications so that they can use it to verify certs.
Unfortunately, this approach is currently impossible in idpbuilder because we rely on the default ingress-nginx certificate. Even if we extract the certificate and make it available for applications to verify against, it will fail because subject name does not match our target names (*.cnoe.localtest.me).
We need to generate our own cert, specify it in the ingress-nginx configuration, then make it available somewhere in the cluster.
Possible solutions:
Use cert manager to generate self-signed cert for ingress-nginx to use. This means we have to embed manifests like we do now for core packages. This also means we will have a pod essentially doing nothing after the initial install.
Generate it in idpbuilder CLI. Since this is a one-time operation, we could generate it in CLI for ingress-nginx to use.
This is related to #127 but not specific to Backstage.
Problem:
Currently, we rely on the default TLS certificate baked in the ingress-nginx controller image to establish TLS sessions for all incoming connections. This works for accessing web UIs from browsers as long as they click on the accept risk button.
This is not so easy for applications. When we want to point an application to the https port on the ingress-nginx service, it will raise an TLS error because it's self-signed and SANs will not match.
To overcome this kind of TLS issues, many applications provide an option to skip TLS verification steps altogether. This is obviously not a good practice.
A better approach would be to provide the CA cert to applications so that they can use it to verify certs.
Unfortunately, this approach is currently impossible in idpbuilder because we rely on the default ingress-nginx certificate. Even if we extract the certificate and make it available for applications to verify against, it will fail because subject name does not match our target names (
*.cnoe.localtest.me).We need to generate our own cert, specify it in the ingress-nginx configuration, then make it available somewhere in the cluster.
Possible solutions:
Use cert manager to generate self-signed cert for ingress-nginx to use. This means we have to embed manifests like we do now for core packages. This also means we will have a pod essentially doing nothing after the initial install.
Generate it in idpbuilder CLI. Since this is a one-time operation, we could generate it in CLI for ingress-nginx to use.