This is the second in a series of articles on using Acorn with Azure AKS. Part one explains how to get started with Acorn on Azure, and part three discusses running stateful workloads.

Acorn applications can publish ports for HTTP access. For each published port, Acorn generates a unique URL for accessing it. By default, these endpoints are published as HTTP endpoints.

Starting with Acorn 0.3 release, securing the URLs by automatically generating HTTPS endpoints is possible. It is also possible to secure the endpoints associated with custom domains. Acorn can be integrated with Let’s Encrypt, a popular service to generate TLS certificates for securing web applications. 

This hands-on guide walks you through both scenarios. In the first scenario, we will integrate Let’s Encrypt with Acorn to secure automatically generated endpoints <container name>-<app name>-<namespace>.on-acorn.io. The second scenario explains using a custom domain with Acorn and securing the endpoints through an HTTPS URL based on Let’s Encrypt.

Scenario 1 – Securing Automatically Generated Endpoints 

For this tutorial, you must run Acorn in an environment where the Ingress IP address is accessible through the public internet. For details on launching an Azure Kubernetes Service cluster for Acorn, refer to this tutorial. 

We have an AKS cluster with three nodes. 

The Ingress service is configured as type LoadBalancer, which is exposed through a public IP address. 

Let’s install Acorn with the Lets Encrypt service enabled. Replace the email address before running the below command.

acorn install \
  --lets-encrypt enabled \
  --lets-encrypt-tos-agree=true \
  --lets-encrypt-email [email protected] \
  --ingress-class-name nginx \

Create a simple Acorn app that runs a web server and launch it.

containers: {
 "web": {
  image: "nginx"
  ports: publish: "80/http"
  files: {
   // Simple index.html file
   "/usr/share/nginx/html/index.html": "<h1>My First Acorn!</h1>"
  }
 }
}

acorn run -n demo .

Notice that the generated endpoint is a secure HTTPS URL.

Access the URL and verify the certificate to ensure that it is generated by Let’s Encrypt.

Scenario 2 – Securing Endpoints Associated with a Custom Domain

In this scenario, we will take control of DNS by creating an A record for the public IP address associated with the ingress / load balancer. 

First, get the public IP address of the NGINX ingress. In this case, it is 20.235.3.165.

Go to your domain registrar and access the DNS settings to add an A record pointing to the above IP address. For example, I created an A record in GoDaddy, which is the registrar of my domain, cloudnativelabs.in.

Wait for the record propagation to take place, and then test if the DNS resolution works for the domain name. 

Before proceeding further, let’s install cert-manager in our AKS cluster to generate the certificates and the secrets. 

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.10.0 \
  --set installCRDs=true

Ensure that all pods of the cert-manager are in a running state.

With the infrastructure in place, let’s go ahead and install Acorn with a couple of switches that influence DNS management.

acorn install \
  --ingress-class-name nginx \
  --acorn-dns disabled \
  --cluster-domain cloudnativelabs.in

The switch, --acorn-dns disabled stops Acorn from generating the default, on.acorn.io endpoints. The  --cluster-domain cloudnativelabs.in switch instructs Acorn to use the custom domain instead of the default domain. This also means that the DNS management is left to us. 

Before launching an app, let’s create the ClusterIssuer resource based on Let’s Encrypt in the acorn namespace.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: le
  namespace: acorn
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-issuer
    solvers:
    - http01:
        ingress:
          class: nginx

We also need a Certificate in the acorn namespace associated with the endpoint of the application, which is web.cloudnativelabs.in.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: web-cert
   namespace: acorn
spec:
  dnsNames:
  - web.cloudnativelabs.in
  issuerRef:
    kind: ClusterIssuer
    name: le
  secretName: web-tls-secret

Verify that the certificate request is approved and the status is ready.

It’s time to create an Acorn web application with a custom domain. Notice how the domain is associated with the container publishing the port. 

acorn run -p web.cloudnativelabs.in:web  -n demo .

We can now access the web application at https://web.cloudnativelabs.in

This concludes the tutorial on generating secure URLs for Acorn endpoints. To learn more about using acorn, visit our getting started guide, or join us for an upcoming meetup or training. You can also continue this series about running Acorn on Azure with part three, which focuses on deploying stateful applications.

Janakiram is a practicing architect, analyst, and advisor focusing on emerging infrastructure technologies. He provides strategic advisory to hyperscalers, technology platform companies, startups, ISVs, and enterprises. As a practitioner working with a diverse Enterprise customer base across cloud native, machine learning, IoT, and edge domains, Janakiram gains insight into the enterprise challenges, pitfalls, and opportunities involved in emerging technology adoption. Janakiram is an Amazon, Microsoft, and Google certified cloud architect, as well as a CNCF Ambassador and Microsoft Regional Director. He is an active contributor at Gigaom Research, Forbes, The New Stack, and InfoWorld.