Introducing the Mysocket portal
Some exciting news today, in this blog post, we’re introducing our new dashboard, portal.mysocket.io. The portal has similar functionality as the mysocketctl CLI tool but also provides access to statistics. Keep on reading; as for you power users, there’s another nice improvement related to tunnel authentication changes.
For the last two months, we’ve mostly focused on building out and proofing the underlying technology. We focused on the tunnels, the proxies, the distributed systems work, CLI and API, as well as the authentication and authorization components for our zero-trust features.
It’s been great to see a steady increase of users and even a handful of power users! At the same time, it became clear we need to start adding some more features focused on improving the user experience. Mysocket started as an API and CLI first service, but as we’re looking at exposing more data, the time has come to also introduce a web portal.
So without further ado, I invite you all to check out our portal at https://portal.mysocket.io/
Existing users can sign in using the same credentials (email address and password) as you’re used to when using the mysocketctl CLI tool. New users can register online now as well.
After logging in, you’ll see a list of all your sockets. From this screen, you can easily create new sockets and edit or delete your existing sockets.
When we click on one of the Sockets we can see all the details for this socket. This page has two tabs, details and statistics. In the details tab, we can easily modify some of the details. For example, we can quickly enable or disable zero-trust for a socket or add or remove, allowed domains and email addresses.
In the Statistics tab, we can see the usage statistics for this socket. We’re collecting various types of statistics and store these in our prometheus system. The API currently exposes a subset of these, specifically requests per second and the bandwidth usage.
One more thing — Short-lived certs for Tunnel authentication
Some of our power users have noticed that when using mysocket on multiple servers, you needed to make sure your key pair was available on all these servers. This was annoying, made it harder to use, and for some, a security challenge. As part of our push to make the service easier to use, we’ve eliminated the need to bring your own key pair.
Don’t worry; the tunnels between your service and our anycast edge servers are still encrypted, just as before. However, we’ve made mysocketctl smarter, and it’s now dealing with this work for you. It will create a local key pair if one doesn’t exist yet on the client-side. When a tunnel is set up, the client will request a short-lived signed certificate from the API. This certificate, combined with the ephemeral local key, is used to authenticate and set up the tunnel. Certificates can only be requested by authenticated clients. All of this is done by the (Go version of the) mysocketctl client. So with this, we’ve both made it easier to use and, using short-lived certs, it’s arguable safer as well.
Wrapping up
That’s it for this update! This sprint was mostly about making mysocket easier to use and exposing more of the performance information to our users. On a personal note, it’s been a while since I did any web development, I’m pretty happy with the result, and I’m hopeful it will make the mysocket services easier to consume. By the way, all of the capabilities you see on the web page are also available through our API. Both the CLI and the portal consume the same API features.
I’m also pretty excited about the introduction of the short-lived certificates for authenticating tunnels. It’s both easier for users and more secure. All around wins!
Please give it a spin, and have a great week!
