Index ¦ Archives  ¦ Atom  ¦ RSS

Protecting Internal Apps

I've been an early engineer/team member of a few companies/startups, as well as an engineer at Google (and later, a second time, at Waymo). One of the big things I missed in the small companies (well, when they were small) that I remembered from my time at Google was something like CorpSSO.


I don't actually know if that's what it was called, it could be CorpEngSSO or something, but the main gist is that it was an SSO (Single Sign-On) system that sat in front of the entire suite of internal applications and made them available as long as you were logged in.

So what? Why did you want it?

These are some aggressive questions! Okay, okay, I'm getting there.

First, let's talk about the wide suite of internal applications that are much more useful when:

  1. You can make it available "publicly" but it's still limited to members of your organization, and
  2. You know the username and/or email of the user accessing it.

An example of this is a system that provides previews of a PR's changes. It's common to have a CI system that builds your frontend, runs tests, and then drops all those artifacts somewhere (or deletes them). If you throw a static file server in front of those files, then the code author or a reviewer can view that PR's changes live without running any commands.

However, you definitely don't want that available publicly, as it's a potentially buggy, insecure version of your product, but you do want people to be able to view this frontend without necessarily being on-premise or connected to a VPN.

Another example is a tool that allows users to view a dashboard and/or interact with production systems, such as initiating a deployment. Typically, this is initially done through shell scripts, but as the number of configuration options grow (and the chances of getting it wrong grow with them), some sort of an application with a UI becomes useful. That way, you can warn users of possibly mistaken options, group/hide/collapse options together, and generally make deployments easier to understand.

Alright, it's useful, is that it?

Thankfully, no. After a day of chasing multiple issues and an equal number of "well, duh" moments, I got "Vouch Proxy" running against a GitHub organization, and I deployed some static files behind it.

This software mainly relies on nginx (or OpenResty) to handle proxying requests to the correct location based on whether the user is logged in or not. I'll spare explaining what it does in favor of linking to their GitHub project directly, specifically the "What Vouch Proxy Does" section.

The docs are great, though if you're doing anything off the beaten path it can get dicey since it's not a huge project after all.

You got it working, so what?

Well, now I have multiple URLs that I can share with co-workers (and some with personal friends), as well as with external users, that I can be certain won't be accessible by the general public.

All that just to say: If you would like to see Reviewable's upcoming homepage, DM me your GitHub username and I'll give you access. You can DM me on Twitter @fahhem or @reviewableio or hit us up at


© Fahrzin Hemmati. Built using Pelican. Theme by Giulio Fidente on github.