DEV Community

Abhimanyu Selvan
Abhimanyu Selvan

Posted on • Originally published at thecloudodyssey.com

How we leveraged nip.io and custom CA for Otomi

Otomi consists of a complete suite of applications that can be installed in one run on a Kubernetes cluster. It contains several open-source projects like Prometheus, Loki, Istio, cert-manager, external DNS, and much more. All of these applications are configured with sane defaults, making everything work out-of-the-box.

But some of these apps require advanced configuration and dependency management to make them work.

How can we have users try out Otomi with the least amount of effort and without any dependencies?

In this article, I’ll explain how Otomi is configured to be used without the need for a DNS zone. For this, Otomi uses nip.io for DNS name resolution combined with a service LoadBalancer IP, and cert-manager with a custom CA for creating certificates. We not only wanted to demonstrate this solution but also wanted to inspire you to create your test/demo set up by making use of the powerful open-source projects that are available.

The why?

You want your development environment to mirror production as closely as possible. When it doesn’t, you invite more issues showing up in production that didn’t show up in development. Running HTTP when your production site is HTTPS-only is an unnecessary risk.

If you have worked on greenfield cloud-native projects, you would have experienced the pain of testing your application with TLS enabled. It’s easy to spin up an application or micro-service and access this via an IP address or localhost, but this isn’t a fully qualified domain name and doesn’t quite reflect the real-life scenario.

Do you want to manually edit the /etc/hosts file for every new subdomain used for your applications?

Enter nip.io

The nip.io service is a “dead simple wildcard DNS for any IP Address”, and it allows you to map example domain names like otomi.{public-ip}.nip.io to {public-ip}. If you wonder how nip.io knows how to route otomi.{public-ip}.nip.io to my {public-ip}, well, it's because of how nip.io is designed.

It essentially forwards that external DNS request back, telling it to look at the {public-ip}. The advantage is that this is a very easy and powerful solution for generating domain names that map to a local app or Kubernetes cluster.

Otomi + nip.io

When you install Otomi with helm chart installation values, it uses nip.io for DNS name resolution and Self-signed certificates to securely access the application. By default, all the integrated applications are set to the nip.io base domain. Therefore, you can immediately test access without additional configuration such as external-dns.

To configure the application services, Otomi first obtains the external IP address of the load balancer and then uses the public-ip address to configure full qualified domain names (FQDN) in the format https://{application}.{public-ip}.nip.io as shown in the figure below.

ingress.png

Let's take a dig at it

dig.png

You can see that an A record has been created with the public-ip: 34.147.113.155.

Pretty neat isn’t it?

Custom CA

TLS Certificate management is automatically handled by a cert-manager to manage certificates and issuers (installed with pre-configured chart values).

Otomi automatically generates a Certificate Authority (CA) and stores it as a Kubernetes secret {custom-ca}:

Screenshot 2022-03-03 at 17.17.36.png

A ClusterIssuer of type CA is then created that references the custom-ca secret:

Screenshot 2022-03-03 at 17.37.54.png

The custom-ca ClusterIssuer is used to sign new Certificate Sign Requests (CSRs) for each of the integrated applications separately:

Screenshot 2022-03-03 at 17.19.23.png

Note: There is no manual configuration needed whatsoever and all these are handled automatically by Otomi.

Conclusion

Don't worry, we will test it in Production (NOT!!!)

So if you are want to test your web applications like it is in production, then you can make use of the same projects we use in Otomi to build a secure test/demo setup. The primary disadvantage of using a service like nip.io is that you are relying on an external service, which means your development or test loop is coupled with the SLA (or lack thereof) from this service. Also, the use of a Custom CA that is not publicly trusted is not encouraged but doesn't it make it a perfect solution for testing or evaluation purposes? Let us know what you think!

Useful Links:

Top comments (0)