TLS: Support for user provided domains

[cjellick]

This is NOT for on-acorn.io domains

This is for the case where user supplies their own cluster domain, or even more likely creates an app with the following publish flag:

-p myapp.mydomain.com:<app deatils>

Supporting this means installing and managing cert-manager and auto-creating the Certificate CRs if the app wants TLS

[cjellick]

We arent going to install cert-manager. User expresses they want TLS. If we find the Certificate CR, then we program it

[andyjeffries]

What's the proposal then for how cert-manager should be installed? Just manually in to the cluster?

I don't know your design goals, but this was feeling to me like "bring me a cluster, give me access, deploy your apps with easy commands". Darren just said in the Webinar:

This feels like "No knowledge of Kubernetes YAML required, FOOTNOTE: unless you want to use your own domain name and use TLS with it". Hopefully it's reconsidered, having Acorn install cert-manager for you unless already installed/available.

[andyjeffries]

Ahhh, I took the wording of the issue to be almost like a "we won't be doing this", but I guess it's just pending, based on:

In the future, Acorn will provide built-in mechanisms to automatically provide certificates for each endpoint. Today, adding a certificate must follow the manual approach.

-- https://docs.acorn.io/running/certificates

[vincent99]

@andyjeffries There's a balance we're trying to find the right line on between batteries-included (you just want a cert, I don't know or care about CertManager) and tolerable-for-cluster-operator-to-install. The more stuff we add to someone's cluster the more they worry about trying it, compatibility between versions issues, should it be cleaned up on uninstall, etc.

CertManager does a lot of stuff and we don't even actually need so one option we're considering is not requiring it at all by doing ACME dances in the controller instead. That's straightforward enough for single name http-01 challenges.

The part CertManager does do that's really useful is taking creds and talking to all the provider APIs for dns-01/wildcards. But we can maybe do a one-time setup _acme_challenge.yourdomain.com CNAME [your-cluster].on-acorn.io yourself step, and then with that we can manage a *.yourdomain.com wildcard without having any creds or provider-specific implementation.

[andyjeffries]

Not requiring (or self-embedding the relevant parts of) cert-manager would be cool.

I definitely lean to the "I have a cluster, but want acorn to manage it as a kind-of/lightweight PAAS for me" camp.

I know about Kubernetes (as former CTO of Civo.com), but I don't want to deal with the minutia of it in my new job as it's not necessary for me.

[cjellick]

Right now, our implementation plans in this area are as follows:

1. Supply a wildcard cert for the on-acorn.io domain associated with the cluster. This will not use cert-manager. It will just use existing go-libraries in our acorn controller
2. For easy cert-manager integration (for those that already have it), allow for the propogation of annotations from the acorn containers to the ingress we create. This solves a lot of use cases, one of which is automatic cert creation through cert-manager: https://cert-manager.io/docs/usage/ingress/#supported-annotations
3. Revisit that last paragraph of Vince's and other possible solutions to see what we want to do.

[denist-huma]

Hello there. Acorn is not finding a TLS secret!? I just tried several times it is not working.

Acorn will automatically inspect each certificate in the Acorn namespace for one that can be used with my-app.example.com. If no TLS secret is found with that FQDN, it will be exposed on HTTP only.

acorn install --cluster-domain sbx.huma.com --ingress-class-name nginx --acorn-dns disabled
acorn run -n todo-app-acorn --publish todo-app-acorn-1.sbx.huma.com:server .

I have a TLS secrets that external secrets operator created from GCP SM.

$ k get secret sbx-huma-com-tls-secret -n todo-app-acorn-cd495f1f-791
NAME                      TYPE                DATA   AGE
sbx-huma-com-tls-secret   kubernetes.io/tls   2      10m

1. there is no .spec.tls section in the ingress
2. I use external-dns so I need to put an annotation. "external-dns.alpha.kubernetes.io/hostname": "todo-app-acorn-1.sbx.huma.com" annotation

$ k get ing -n todo-app-acorn-cd495f1f-791 -o yaml
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      acorn.io/targets: '{"server.todo-app-acorn.sbx.huma.com":{"port":8090,"service":"server"},"todo-app-acorn-1.sbx.huma.com":{"port":8090,"service":"server"}}'
      apply.acorn.io/applied: H4sIAAAAAAAA/8RTwW7bOhD8lYc9S4rkZ7sRgR7anooCRQ+5VTmsyLUkhCIJcuU6EPjvBaUkjW0kPfa2JmeGs+PRDCMxKmQEMQMaYxl5sCYsP6X1phjsDaPviAMImBsI5I/kC7bK5uhcvqJCeyr6acRC2rEBMTfgrOcGxG1Zl9nKGiQ1INIMGaBz+rF4ecL+MuTz7vgAAgbD5A3qP7fHKvvv22DUx0/OfTWB0cg3NQyOBALO/b0HDg5lYrwLDFObS2uYTgwCIGYgPS1R3Q0jBcbRgTCT1hlobEmfB5h8vOnrEnTl5xkwosGOVBLxE72+eUr3+Y31L7pepcfQgwCJNW1UXWO5rwllTWpf3R7KUm52/2+Uwr0qy3q726YtLxVfGzxfJZdqW+8O1SH/UFeJGhzJlMJgOk8hfNEYwvdVznSDOUEGftIUQPycobeBryWrs15BBj2zS5oOuV+JLcoHMiodPqWQxkvbqYzL+TS25NdWxhizRQgE3MA63j26xPvh6TCcIN7HmL14+3vx/4nB+xQ1I09L5bRF9Rl1+kA8iDnG+DsAAP//e5YZReMDAAA
      apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
      apply.acorn.io/owner-name: todo-app-acorn
      apply.acorn.io/owner-namespace: acorn
      apply.acorn.io/owner-sub-context: ""
    creationTimestamp: "2022-08-22T20:05:18Z"
    generation: 1
    labels:
      acorn.io/app-name: todo-app-acorn
      acorn.io/app-namespace: acorn
      acorn.io/managed: "true"
      acorn.io/service-name: server
      apply.acorn.io/hash: ca9e2d99a069eac9ed618f00c2532dda6d009454
    name: server
    namespace: todo-app-acorn-cd495f1f-791
    resourceVersion: "21480806"
    uid: 42579c35-6344-4d36-86f8-bc803ae75259
  spec:
    ingressClassName: nginx
    rules:
    - host: todo-app-acorn-1.sbx.huma.com
      http:
        paths:
        - backend:
            service:
              name: server
              port:
                number: 8090
          path: /
          pathType: Prefix
    - host: server.todo-app-acorn.sbx.huma.com
      http:
        paths:
        - backend:
            service:
              name: server
              port:
                number: 8090
          path: /
          pathType: Prefix

[cjellick]

I have a TLS secrets that external secrets operator created from GCP SM. $ k get secret sbx-huma-com-tls-secret -n todo-app-acorn-cd495f1f-791

It looks like you are creating the secret in the generated namepsace that acorn creates. For this auot-detect feature to work, you want to add the secret to the user-facing namespace (acorn by default).

I use external-dns so I need to put an annotation. "external-dns.alpha.kubernetes.io/hostname": "todo-app-acorn-1.sbx.huma.com" annotation

I didn't realize external-dns relied on an annotation being on the ingress. I am currently working a feature to support the addition of arbitrary user-defined labels and annotations to be added to the resources created by acorn. Should be out in the next week or two.

[denist-huma]

I didn't realize external-dns relied on an annotation being on the ingress. I am currently working a feature to support the addition of arbitrary user-defined labels and annotations to be added to the resources created by acorn. Should be out in the next week or two.

Here is link to its docs Annotate the Service with your desired external DNS name. Make sure to change example.org to your domain.

kubectl annotate service nginx "external-dns.alpha.kubernetes.io/hostname=nginx.example.org."

It looks like you are creating the secret in the generated namepsace that acorn creates. For this auot-detect feature to work, you want to add the secret to the user-facing namespace (acorn by default).

IMHO not intuitive at all. When I feed my TLS secrets to my operator, I create secrets in each namespace, because this allows to cover tenant per namespace case.

[cjellick]

Annotate the Service with your desired external DNS name. Make sure to change example.org to your domain.

Roger that. Hopefully when the annotation feature lands, it will meet your needs.

IMHO not intuitive at all. When I feed my TLS secrets to my operator, I create secrets in each namespace, because this allows to cover tenant per namespace case.

I hear you. That just hits a chicken-and-egg problem of adding the secrets after acorn has created and deployed everything. We have another feature in the queue for being to tell acorn to create its k8s resources in a pre-defined/pre-created namespace rather than a generated one. When that feature lands, you'd be able to drop the tls secret into namespace X and then deploy deploy there.

That said, as the feature stands now, I think you can still might be able to achieve what you desire. You can have a user-facing "acorn" namespace per tenant, rather than just using the default acorn namespace. You'd need setup some RBAC to ensure each tenant can only create acorn Apps in their namespace and no others.

[denist-huma]

do Acorn want me to name a secret some way? It doesn't pick up my secret.

$ k get secrets -n acorn | grep tls
sbx-huma-com-tls-secret        kubernetes.io/tls                     2      6m28s
todo-app-acorn-tls-secret      kubernetes.io/tls                     2      3m20s
$ acorn apps
NAME             IMAGE          HEALTHY   UP-TO-DATE   CREATED   ENDPOINTS                                                                                         MESSAGE
todo-app-acorn   04f157adf923   2         2            94m ago   http://server.todo-app-acorn.sbx.huma.com | http://todo-app-acorn-1.sbx.huma.com => server:8090   OK

Or have to rm app and create again?

[cjellick]

It looks for a match in the SANs against the hostname.

[ibuildthecloud]

Can you provide a dump of the cert (not the private key). Like openssl x509 -in cert.pem -noout -text or the kubectl yaml output and just drop the key field?

[denist-huma]

@cjellick do you want to say what I was doing an unexpected way of deploying? It should I put secrets for my workload into acorn or todo-app-acorn-486a834d-ac4

Acorn creates a bunch of secrets that are empty in the acorn namespace. Are they supposed to be filled? Than why do they have random suffixes? I got confused.

# acorn's
$ k get secrets -n acorn | grep opaq
todo-app-bucket-secret-pwd9h    secrets.acorn.io/opaque               0      5m13s
todo-app-db-jv5h9               secrets.acorn.io/opaque               0      5m13s
todo-app-rc-secret-d79ps        secrets.acorn.io/opaque               0      5m13s

# mine
denis@L560:~/huma/compose-operator-examples/examples/acorn/todo-app$ k get secrets -n acorn | grep Opaq
todo-app-bucket-secret          Opaque                                4      8m31s
todo-app-db                     Opaque                                3      8m31s
todo-app-rc-redis-config        Opaque                                1      8m33s
todo-app-rc-secret              Opaque                                1      8m33s

containers: {
  server: {
    image: "ghcr.io/huma-engineering/compose-operator-examples/todo-app:0.3.0"
    entrypoint: [
      "uvicorn",
      "app:fastapi_app",
      "--host",
      "0.0.0.0",
      "--port",
      "8090",
      "--reload"
    ]
    env: {
      "MINIO_ACCESS_KEY": "secret://todo-app-bucket-secret/aws_access_key_id"
      "MINIO_SECRET_KEY": "secret://todo-app-bucket-secret/aws_secret_access_key"
      "BUCKET": "secret://todo-app-bucket-secret/bucket_name"
      "MINIO_REGION": "secret://todo-app-bucket-secret/region"
      "MONGO_URL": "secret://todo-app-db/connectionString"
      "REDIS_URL": "secret://todo-app-rc-secret/redis_url"
      "MINIO_URL": "s3.amazonaws.com"
      "MINIO_SECURE": "true"
      "MONGO_COLLECTION": "todo-app-db"
      "SIGNED_URL_LIFE": "7"
      "SERVICE_URL": ""
      "SIGNED_URL_BASE": ""
    }
    ports: publish: "8090/http"
  }
}

[denist-huma]

It looks for a match in the SANs against the hostname.

todo-app-acorn-1.sbx.huma.com should accept *.sbx.huma.com TLS cert.

    tls:
    - hosts:
      - todo-app-acorn-1.sbx.huma.com
      secretName: pp-star-sbx-huma-com-secret

I have some issue with external-dns in my test cluster. I will get back tomorrow, it is late night in my place.

[cloudnautique]

Yeah, wild card support hasn't been added/tested. It is on the list of items to add.

[denist-huma]

Do Acorn v0.1.4 support one certificate/tls-secret for 2 dnsNames at the moment? Is it a case of not supporting TLS for default "container.app.domain"?

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: acorn-selfsigned-cluster-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: todo-app-cert
  namespace: acorn
spec:
  secretName: todo-app-tls-secret
  dnsNames:
    - todo-app-acorn-1.sbx.huma.com
    - server.todo-app-acorn.sbx.huma.com
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: acorn-selfsigned-cluster-issuer

$ acorn update -p todo-app-acorn-1.sbx.huma.com:server todo-app-acorn
todo-app-acorn
denis@L560:~/huma/compose-operator-examples/examples/acorn/todo-app$ acorn apps
NAME             IMAGE          HEALTHY   UP-TO-DATE   CREATED   ENDPOINTS                                                                                         MESSAGE
todo-app-acorn   04f157adf923   2         2            15h ago   http://server.todo-app-acorn.sbx.huma.com | http://todo-app-acorn-1.sbx.huma.com => server:8090   OK

https://todo-app-acorn-1.sbx.huma.com/ is working, but https://server.todo-app-acorn.sbx.huma.com/ gives NET::ERR_CERT_AUTHORITY_INVALID

[cloudnautique]

I want to try and reproduce this, you have the single cert with 2 DNS names.

On the ingress resource in the generated todo-app-acorn namespace, can you confirm the secret is not being added in both places?

[denist-huma]

Hey Bill @cloudnautique This my ingress

$ k get ing -n todo-app-acorn-ea8f1b90-143 -o yaml
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      acorn.io/targets: '{"server.todo-app-acorn.sbx.huma.com":{"port":8090,"service":"server"},"todo-app-acorn-1.sbx.huma.com":{"port":8090,"service":"server"}}'
      apply.acorn.io/applied: H4sIAAAAAAAA/8RTy27bMBD8lWLPlCP5BYtAD21PRYGgh9xqH1bk2hJCkQS5ch0I+veCUl62kaS33Fbc2eHsaNhDS4waGUH2gNY6Rm6cjeOncsHOGnfDGA7EEST0W4gUjhRm7LTL0PtsQsXqNKu7FmfKtVuQ/Ra8C7wFucnLXExTjaItyFSDAPTePMyer3B/LYXscLwHCY1lChbNS/dYiC+/Gqu/fvP+p42MVr3JYbElkHCu7z1w9KjSxLvA2FWZcpbpxCABBgEq0GjVXdNSZGw9SNsZI8BgRebcwKTjTV2XoCs9T4AWLR5IJ5LQ0evOo7tPd0y/6HqVGmMNEhSWNNdlifm6JFQl6XWx2ee5mq8Wc61xrfO8XK6WactLxtcCz1fJCDf7oirzrFgu0mj0pJILjT0EivGHwRhvJzp7aOwJBITOUAT5p4faRb6mLM5yBQJqZp84PXI9DVao7snqdPjoQiovZacwjuddW1GYUjkMgxiJQMINTOXdg09zvwPtmxMMu2EQz9o+Dv6nCNwJYPNiYqo+tPE/VtkllArEtxe5ZROzqZOpRZmvcF5ker1KWgRERu7G7BuH+jua9FIDyH4Yhn8BAAD//+V6MipsBAAA
      apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
      apply.acorn.io/owner-name: todo-app-acorn
      apply.acorn.io/owner-namespace: acorn
      apply.acorn.io/owner-sub-context: ""
    creationTimestamp: "2022-08-23T13:41:38Z"
    generation: 15
    labels:
      acorn.io/app-name: todo-app-acorn
      acorn.io/app-namespace: acorn
      acorn.io/managed: "true"
      acorn.io/service-name: server
      apply.acorn.io/hash: ca9e2d99a069eac9ed618f00c2532dda6d009454
    name: server
    namespace: todo-app-acorn-ea8f1b90-143
    resourceVersion: "22156880"
    uid: 7df1f9a6-b7ff-4475-a901-42773a956468
  spec:
    ingressClassName: nginx
    rules:
    - host: todo-app-acorn-1.sbx.huma.com
      http:
        paths:
        - backend:
            service:
              name: server
              port:
                number: 8090
          path: /
          pathType: Prefix
    - host: server.todo-app-acorn.sbx.huma.com
      http:
        paths:
        - backend:
            service:
              name: server
              port:
                number: 8090
          path: /
          pathType: Prefix
    tls:
    - hosts:
      - todo-app-acorn-1.sbx.huma.com
      - server.todo-app-acorn.sbx.huma.com
      secretName: todo-app-tls-secret-c3905a21-d65

TLS secrets seems to be equal inside

$ k get secrets -A | grep tls
acorn                         todo-app-tls-secret                                        kubernetes.io/tls                     3      85m
todo-app-acorn-ea8f1b90-143   todo-app-tls-secret-c3905a21-d65                           kubernetes.io/tls                     3      83m

P.S. I switched to namespaced issuer:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: acorn-selfsigned-issuer
  namespace: acorn
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: todo-app-cert
  namespace: acorn
spec:
  secretName: todo-app-tls-secret
  dnsNames:
    - todo-app-acorn-1.sbx.huma.com
    - server.todo-app-acorn.sbx.huma.com
  issuerRef:
    group: cert-manager.io
    kind: Issuer
    name: acorn-selfsigned-issuer

[cloudnautique]

@denist-huma Here is what I tried, and it seems to be working as expected. Can you let me know if my setup is different from yours?

It looks like the info you last provided, Acorn is recognizing the appropriate certificate to use for each of the domain names. I wonder if this is more of a cert issue?

I have a simple Acornfile with two containers:

containers: web: {
  image: "nginx"
  ports: expose: {
    "80/http"
  }
}

I requested a cert with two dnsNames:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: registry-studio-cert
spec:
  dnsNames:
  - registry.studio-rd.cloudnautique.com
  - telemetry.studio-rd.cloudnautique.com
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: cloudflare-issuer
  secretName: registry-tls-secret

I built the app and launched it:

acorn build -t cert-test .

acorn run cert-test -h
#
#Volumes:   <none>
#Secrets:   <none>
#Containers: web
#Ports:     expose: web:80/http
#
acorn run -p telemetry.studio-rd.cloudnautique.com:web -p registry.studio-rd.cloudnautique.com:web cert-test
#late-resonance
acorn apps
#NAME             IMAGE       HEALTHY   UP-TO-DATE   CREATED   ENDPOINTS                                                                                                                                                      #MESSAGE
#late-resonance   cert-test   1         1            46s ago   http://registry.studio-rd.cloudnautique.com | http://telemetry.studio-rd.cloudnautique.com | http://web.late-resonance.cert-test.local.on-acorn.io => web:80   OK

Here is my ingress:

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      acorn.io/targets: '{"registry.studio-rd.cloudnautique.com":{"port":80,"service":"web"},"telemetry.studio-rd.cloudnautique.com":{"port":80,"service":"web"},"web.late-resonance.cert-test.local.on-acorn.io":{"port":80,"service":"web"}}'
      apply.acorn.io/applied: H4sIAAAAAAAA/8RTwY7TMBD9FTTnOJtuGra1xAFuCAlx2BvpYWJP22gd29iTdqso/47cbrsEqLYnuE3sec9v3rwM0BGjRkaQA6C1jpFbZ+PxU7lg89bdMYYNcQQJQw2BNm3kcMgj97p1IuhcGddriz23P3rKletqkEMN3gWuQS6KrIZIYdcqqkHWsCfIAL03h/zyhNtbCmKzewIJrWUKFs3r7W6WvfvSWv3ho/efbWS06iqHxY5AgkEmESg6+1Zz9KgSQlFgwRT5WnPsG6GcZXpmkABjBirQ0a7HtqPI2HmQtjcmA4MNmamJ6P11bb83/VXTualDixvSIIFDP4G/uHx+Z0/Nn7NsMW5BwsPsoZyVxVqX5bLStFwvdFPeN7SYr8tCqUIX+h6XWKUxJ3S/ypsOIppmjVVVVEKV84SLnlTyIPSGIsjvA2xdTN4xGerojRBBBltmnwg88vZE0KB6IqvT4cuwqZwITLE7HvZdQyHlbxzH7MgBEu7gVD4efIJ8C7Run2FcjWN2kXdLxP+fuj01+dT4/BKT3DiFJndWnPf9r3WuMmDzuuxU3bzum3xfZRBJBeKvJ7lnkGATxelG6PmymuH7UtASk6oMIiP3xx/SONSf0CTfAshhHMefAQAA//9B7GkMBQUAAA
      apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
      apply.acorn.io/owner-name: late-resonance
      apply.acorn.io/owner-namespace: cert-test
      apply.acorn.io/owner-sub-context: ""
    creationTimestamp: "2022-08-23T15:23:42Z"
    generation: 1
    labels:
      acorn.io/app-name: late-resonance
      acorn.io/app-namespace: cert-test
      acorn.io/managed: "true"
      acorn.io/service-name: web
      apply.acorn.io/hash: 7173130fd3395de9f8db32be84f30cc0d0d2a9a5
    name: web
    namespace: late-resonance-bbfa5505-c34
    resourceVersion: "13534"
    uid: 725e1c61-e8b7-4e0a-9d3d-9ed4bc97e0de
  spec:
    rules:
    - host: telemetry.studio-rd.cloudnautique.com
      http:
        paths:
        - backend:
            service:
              name: web
              port:
                number: 80
          path: /
          pathType: Prefix
    - host: registry.studio-rd.cloudnautique.com
      http:
        paths:
        - backend:
            service:
              name: web
              port:
                number: 80
          path: /
          pathType: Prefix
    - host: web.late-resonance.cert-test.local.on-acorn.io
      http:
        paths:
        - backend:
            service:
              name: web
              port:
                number: 80
          path: /
          pathType: Prefix
    tls:
    - hosts:
      - telemetry.studio-rd.cloudnautique.com
      - registry.studio-rd.cloudnautique.com
      secretName: registry-tls-secret-d4951a63-e9a
  status:
    loadBalancer:
      ingress:
      - ip: 192.168.5.15
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

[denist-huma]

@cloudnautique Thank you, I think it works as expected.

• https://todo-app-acorn-1.sbx.huma.com/
• https://server.todo-app-acorn.sbx.huma.com/

• Both return for Chrome: NET::ERR_CERT_AUTHORITY_INVALID, for Firefox MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. That is expected.

What I had before was due to browser's cache, https://github.com/acorn-io/acorn/issues/486#issuecomment-1224082048 is solved.

[cjellick]

Can this issue be closed?

[cloudnautique]

@cjellick The topic of this issue is the Acorn supporting TLS out of the box, so probably can't close yet until we merge the annotations? Or we keep going to provide something completely end to end.

@denist-huma I was able to verify that Wild Card certs do work as expected. From my previous example in https://github.com/acorn-io/acorn/issues/486#issuecomment-1224235479 I changed the cert to:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: registry-studio-cert
spec:
  dnsNames:
  - "*.studio-rd.cloudnautique.com"
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: cloudflare-issuer
  secretName: wc-tls-secret

The certificate secret was applied to the Ingress resource correctly.

I changed the dnsNames to *.cloudnautique.com and it correctly did NOT assign the cert secret to the ingress.

So it does appear wild card support is working.

Please let me know if you are still running into issues.

[cjellick]

Right on. My bad

[denist-huma]

@ibuildthecloud thank you, following you I tried one more time. In my setup I if both the self-signed cert "todo-app-tls-secret" and my *.sbx.huma TLS secrets present in the "acorn" ns, then Acorn do a thing I don't get:

• it uses *.sbx.huma TLS for todo-app-acorn-1.sbx.huma.com
• the self-signed cert "todo-app-tls-secret" for the server.todo-app-acorn.sbx.huma.com

$ k get secrets -n todo-app-acorn-697a2486-a79 | grep tls
pp-star-sbx-huma-com-secret-a1c5d9fc-f76   kubernetes.io/tls                     2      13m
todo-app-tls-secret-c3905a21-d65           kubernetes.io/tls                     3      13m
$ k get secrets -n acorn | grep tls
pp-star-sbx-huma-com-secret    kubernetes.io/tls                     2      18m
todo-app-tls-secret            kubernetes.io/tls                     3      24h

I did acorn rm and acorn run again, no changes. Clear browser data, restart browser not helps.

[cloudnautique]

@denist-huma the cert would need to be for *.todo-app-acorn.sbx.huma.com. Wild cards are only valid for one level.

[denist-huma]

how can I disable the publishing of server.todo-app-acorn.sbx.huma.com? Change the ports: publish: "8090/http" to "ports: expose: "8090/http" or remove it completely from acornfile and supply at run? acorn run -n todo-app-acorn --publish todo-app-acorn-1.sbx.huma.com:server .

[cjellick]

We went back and forth on whether to also create the generated-name endpoint if you explicit set and endpoint. We ultimately decided to create it, but your concern makes sense. We'll change the behavior to not create a generated-name endpoint when you've explicitly set one.

Here's the tracking issue: https://github.com/acorn-io/acorn/issues/383

[denist-huma]

@cjellick Yes that makes sense. :+1: My concern is that acorn should not "make an offer one cannot refuse" :) (c) Godfather

[cjellick]

This issue has a lot of history and went in a couple different directions. We do want to support out-of-the-box, no-cert-manager-needed issuance of certificates for user provided domains. That is tracked here: https://github.com/acorn-io/acorn/issues/206

While the other issue will be the primary tracking issue for this feature, I am going to keep this issue open as a "sibling" issue to that one and when that feature is completed, we will close both these issues.

[cjellick]

Feature is looking good. I opened up two follow up issues: https://github.com/acorn-io/acorn/issues/900 https://github.com/acorn-io/acorn/issues/901

closing this main issue as completed