Teleport Application for Unifi
Welcome to the world of remote work, where every day feels like a never-ending nightmare. But fear not! With the power of Teleport and its application gateway, you can make being trapped in a dark windowless room, fun.
While Teleport is an incredible server access tool, it can also be used for application access. In this quick post, I'll cover how I set up a Teleport application for my Ubiquity Unifi controller, which is more complex than you may think; however, it's also not hard.
If you're interested in Teleport and how you can setup applications, check out their documentation.
I use Ubiquity network gear for my home, which powers all things WiFi and ethernet. Part of my Ubiquity setup is an Unifi Controller, which has an API and Web UI. The Unifi controller in my environment is running on a virtual machine and is reasonably isolated. To gain access to this Unifi controller in a secure, Russian roulette-like, way, I was running an NGINX reverse proxy for my Unifi controller with a hand full of self-signed certificates; I also have unbound running providing internal DNS because I am a man who enjoys torture.
The setup has worked for the past few years, but I've always wanted more. The system is clunky with the added bonus of self-signed SSL certificates and configuring NGINX: managing it is like navigating a minefield blindfolded on a motorcycle with two flat tires while on fire.
If you've been reading between the many lines I've scrawled, you may have guessed that the NGINX reverse proxy for my Unifi controller never worked quite right. My reverse proxy for Unifi was buggy, so I used the IP address of my virtual machine when I needed to connect to the controller. It was mostly flawless for everything else, but sometimes the Unifi endpoint would tell me to pound sand; always failing at the most opportune times, always in new and exciting ways.
I deployed Teleport within my home cloud a few months back to access my servers, which has been a techno-godsent; no more dealing with the authorized keys dance of death and I really enjoy the single sign-on options it provides.
Read about my Teleport Ansible inventory bits here.
With Teleport, I could simply bootstrap nodes within my home lab using the join script/token, et viola, everything worked perfectly. Because Teleport for node access worked so well, I thought maybe it could replace my janky reverse proxy setup; so I rubbed some neurons together until I smelled toast and came up with a plan.
While I've known about the application capabilities of Teleport for a while, I hadn't taken the time to set it up and get it operational within my environment, until now.
My reverse proxy was running a simple configuration and kept close to the documentation. While I could have likely resolved all my NGINX + Unifi incompatibilities, I never really tired; this time I wasn't going to let my laziness drive get in the way of my future success.
Initially, I followed the Teleport documentation to deploy the Unifi controller as my first application. The setup was simple and almost worked... While I could connect to the Unifi controller via the application endpoint nothing worked, it literally had the same problem as my reverse proxy.
Here's my initial configuration
app_service: enabled: "yes" debug_app: false apps: - name: unifi uri: "https://10.0.51.50:8443" insecure_skip_verify: true
My initial setup had the same issues as my NGINX reverse proxy; however, I endeavored to not be so damn lazy this time. During the process of RTFM, I discovered I could rewrite certain headers and redirects and I thought to myself, maybe I need to do some rewrites to make this all go; which was probably the issue I had with my existing reverse proxy the whole time...
I Smell Burnt Toast
After spending some time investigating the headers used by the Unifi controller I came up with the following configuration.
app_service: enabled: "yes" debug_app: false apps: - name: unifi uri: "https://10.0.51.50:8443" insecure_skip_verify: true rewrite: redirect: - "10.0.51.50" headers: - "Host: unifi.nocanhazmydomain.blah"
Explanation of the Redirects
- The first rewrite
redirectrule will replace the
Locationheader with the IP address of my Unifi controller.
- The second rewrite
headersrule will replace the
Hostheader with the domain name of my public application. In this case, my application name is
That's it, that's the post. After a little RTFM and 8 lines of YAML, everything works perfectly; I am a happy techno-junky.
To gain access to my controller I first need to authenticate with Teleport. The authentication process is up to your specific setup, I use single sign-on via GitHub.
After I've authenticated, the Teleport application will redirect me to the Unifi login page. Here, I enter my Ubiquity credentials normally.
After authenticating, I'm greeted with the sweet taste of Unifi.
So the simple implementation of Teleport and the use of Applications has eliminated two services in my home environment; I no longer run my NGINX reverse proxy or my unbound server. Teleport provides authentication and manages a secure tunnel to my applications making it a beacon of light in the dark abyss of the pseudo-internet. Needless to say, I'm pretty damn happy I finally decided to not be so damn lazy.
Why would you want to do this?
To quote Teleport itself
You can use Teleport to provide secure access to your cloud provider's APIs. This means that you can prevent unauthorized usage of management consoles and CLI tools with the same RBAC system you use to protect your infrastructure
This capability is pretty neat and works exceedingly well. The ability to create authenticated secure tunnels to applications and have teleport manage everything is powerful. The application setup not only scratches a technical itch of mine but also better enables my drive to do nothing. Deprecating my NGINX reverse proxy and unbound servers means I'm putting more eggs in a single proverbial basket; however, Teleport is like one of those really nice handmade wicker baskets you see in fancy homes, so I'm OK with it.