Better validation for acorn installs with `--cert-manager-issuer`

[sangee2004]

acorn version v0.8.0-36-g39efa9d3+39efa9d3

Steps to reproduce the problem:

Scenario 1 :

1. I do not have cert-manager installed k8s cluster and have not followed instructions from https://docs.acorn.io/running/certificates#issuing-custom-domain-certs to enable TLS for ingress controller
2. Install acorn using acorn install --acorn-dns=disabled --cluster-domain my.domain.com --cert-manager-issuer=letsencrypt-prod
3. Acorn install succeeds even when there is no ClusterIssuer with name letsencrypt-prod
4. Deploying apps with custom host name also results in "https://" endpoint urls which are not really secure urls.

curl https://s<host>/
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Expected Behavior: Acorn install should fail in this case with error message indicating the absence of cert-manager-issuer

Scenario 2 :

1. Follow instructions form https://docs.acorn.io/running/certificates#issuing-custom-domain-certs to enable TLS for ingress controller
2. Install acorn using acorn install --acorn-dns=disabled --cluster-domain my.domain.com --cert-manager-issuer=letsencrypt-prod
3. Deploy apps with custom host name that does not resolve - acorn run -n santestnew -p <host-name>:webapp ghcr.io/acorn-io/hello-world:v1

Apps get created with "https://" endpoint urls when they do not even get resolved.

Expected Behavior: Ideally we should not provide a "https://" endpoint url in this case .

[Mohitp98]

Hi @sangee2004

I'm interested in contributing to this issue and have a proposed solution for scenario 1. As a newcomer to the project, I'd appreciate your feedback on my approach.

Scenario 1

My solution involves checking if the cert-manager-issuer is provided with acorn install. In this case, the system will verify the existence of the specified ClusterIssuer CRD within the cluster. To achieve this, I plan to introduce a new dependency by looking up the ClusterIssuer resource which falls under github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1

By doing so, we can effectively handle the error and exit the installation if necessary.

Thanks!

[StrongMonkey]

@Mohitp98 Thanks for contributing this issue! I think that's the right way to do 👍

[cjellick]

Senario 1:

Expected behavior

Acorn install should fail in this case with error message indicating the absence of cert-manager-issuer

I don't think we want it to fail. The way it is now means the order of installation vs creation of the clusterIssuer doesnt matter. This is desired. So, I think scenario 1 is behaving as intended.

I do agree scenario 2 is not a good behavior, but I am not sure how that'll work out implementation-wise. If we can look at the resulting ingress object and be able to tell, great. If we would have to inspect cert-manager CRDs, that would not be good as we don't integrate that deeply

[Mohitp98]

Hi @cjellick @sangee2004 @StrongMonkey I have a question regarding Scenario 2:

How do we want to handle it?

• Is it expected to fail and exit the Acorn run workflow if the provided custom hostname is not resolvable?

  OR

• we don't want to create an endpoint with https protocol - in this case, what should be displayed to the user?

[cjellick]

If we can detect it, it would better to just show http instead of https, so the second option I suppose