“Any Key, Anywhere” 2.0

Lockr 2.0 is now available as a beta release! This eagerly awaited release comes after listening to customer feedback, talking to cloud partners, observing how our platform was being used, and testing some great, internally developed ideas on what the future of secrets management could be. Version 2.0 is all about continuing to deliver on a simple phrase we came up with shortly after launching our original platform:

“Any Key, Anywhere.”

Lockr 2.0 is about delivering any key, in any environment with speed, security and ease. But before we get into all the features of 2.0, let’s look at what brought us to this point to set the ground for why 2.0 is so exciting.

TL DR; (If you want to jump ahead to all the details on 2.0 click here)

When I first had the idea for Lockr, the premise was simple: What if we could create a service that had all the security of an enterprise secrets management solution, yet required no complex setup, and was available at a cost within every site’s budget? What would that system look like?

No one had created anything like it yet, so it was up to us and we set out to build it.

First we wanted to start on a firm foundation, so we worked alongside Townsend Security to make sure their Alliance Key Manager HSM (Hardware Security Module) was at the heart of the system. It is a highly respected, highly capable, and as I like to say “It has a certification for every acronym you can want”. We knew that keeping this as our base, and making sure all values were properly stored in it, would allow us to meet even the strictest enterprise requirements.

From there, we put together a cloud network that allowed for multiple redundancies and failovers on not only the HSMs but for the rest of the network. To be blunt, this had to be designed to always be available. After redundancy came scale. We needed to be able to easily scale the system to meet the demands of our customers. Once we tackled these two, we worked on the setup process.

Normally to setup an HSM it takes a bit of time and a skilled developer. Not only does a network engineer need to setup the HSM, the software developer needs to create the integrations. This is no simple task. Even in the most ideal scenarios it could take a team weeks or more to complete this process. I wanted it to take minutes. We worked on the integrations into Drupal initially and then for WordPress from the premise that everything we did had to simplify the process, so that a first time web designer would be able to setup the service in minutes. We were able to achieve this and more. Through working with the supporting modules in Drupal, we distilled setup down to a few clicks, and all done from within the module admin screen. Users didn’t even need to visit our site first!

So once we had the HSMs that could keep the secrets safely stored, a redundant and scalable cloud network, and integrations that could be setup in minutes we launched Lockr.

It was great to see some of the initial uses. A healthcare startup who needed to meet HIPAA, an enterprise team storing PII for users, and even a large online retailer who needed to scale with ease. We were there to help out teams as they set up their sites, sometimes rolling up our own sleeves and helping out where we could. We were up at midnight for product releases and Black Friday as traffic surges didn’t even get near stressing the system. Overall Lockr v1.0 did what we built it to do.

But we knew that wasn’t enough and after listening to many important voices, we decided to start fresh and rebuild the system from the ground up. As we set out to engineer 2.0, we kept the “Any key, Anywhere” motto in mind and what we were able to build is truly revolutionary.

“I have a need, a need for speed”

One of the first questions we get as people evaluate the platform is “How much does this slow down my site?” Our response is that it’s inherently a slower function to go outside the environment of the site and to a third party service but we are able to keep the service at or under 200 milliseconds per request. Now to most people this seems quick, but in the computer world it’s not going to be winning any Olympic medals. It was still faster than others who offered a similar service, but we pushed ourselves to do better, and our customers deserved it. So for 2.0 we set a goal of sub-100 millisecond requests. We did this by streamlining every pathway within the service, utilizing every cache we could without compromising on privacy, and doing the equivalent of strapping a turbo booster on the HSMs. All these combined to achieve our goal and now the lookup is as quick as any other your site will make.

The fastest trip is one you don’t have to make!

In what I consider to be one of the most revolutionary features of Lockr 2.0, we not only sped up the entire system to perform sub-100 millisecond lookups, we made it so Lockr is positioned anywhere our customers go. The original Lockr platform was built on Amazon’s AWS cloud and while it was plenty fast enough, not everyone who used our service was close to our data centers.

Not only that, in today’s growing age of privacy we needed to make sure we could stay up with data sovereignty regulations and best practices. Originally we did this by launching Lockr in the EU to service customers in Europe who needed to comply with local regulations and for whom a trip across the Pacific Ocean, even at the speed of the backbone of the Internet, was too slow.

So how do we keep data sovereignty when we need it, while speeding up the service by putting it as close as we can to the sites that use it? A patent-pending universal architecture and a mesh network of caches.

The first step in our ground-up rebuild of Lockr was to not use any service that was proprietary to our cloud infrastructure. By doing this, we were able to create a service that we can stand up in ANY cloud. Do you require Amazon’s AWS, Microsoft’s Azure, Google Cloud Services? Sure thing. On-premises datacenter? You got it. By doing this, we not only open ourselves up for more partnerships with cloud providers (since we can go to their cloud, not invite them to ours) but for the first time, an application can be built around a singular secrets store and launched into any cloud or any datacenter without any changes. Also, with the growing trend of hybrid cloud environments Lockr can be a neutral third party, able to share secrets amongst clouds. Something that, prior to 2.0, would take a significant amount of custom work to deploy for each application.

So now that we can increase speed by putting a presence of Lockr into any cloud, how can we speed that up even further? We borrowed a page from the concept of a CDN (content distribution network) to allow each Lockr POP (point of presence) to act as a local cache. Now when a request comes to Lockr, it is first routed to the closest POP to the website, and if the secret isn’t stored there we retrieve it from the source and cache it locally. This way the next request will be even faster.

Now the privacy hawks out there may be screaming about data sovereignty with a feature like this. Have no fear, we created this cache to be a permission that can be set on a secret by secret basis. Have a secret that can’t leave a certain sovereignty due to regulatory requirements? No problem, Lockr will skip the local caching and even re-route the request so that data only flows into and out of the sovereignty it was originally set. If a secret is allowed to be cached, that cache is only temporary. The data permanence is always in the originating sovereignty. By allowing this to be set on a secret by secret basis, and keeping the permanent storage of the secret in the originating sovereignty, we allow for the data to flow based on how our customers want, and what their local regulations require.

Say hello to Lockr KeyRings™

When we originally launched Lockr, the concept of how we bundled secrets together was on a “per site” basis. When connecting through Lockr via the module or plugin, the user would only be allowed to setup a new site (and along with it trigger a new billing event). We found this tripped up folks, even though we had the concept of development and production; what about local development?

This led us to move from grouping secrets by sites, to grouping them by a new logical structure: KeyRings. A KeyRing is simply a collection of secrets which can be shared amongst multiple environments. Now when registering through the modules or plugins, users will get the choice to connect to an existing KeyRing or create a new one. This should eliminate the confusion around creating multiple sites, triggering unnecessary charges (that we often had to eventually refund), and allow users to have greater control over where and how their keys are used.

We also wanted to move away from the name site as it brought along with it some preconceived notions on how the service should be used. In reality, Lockr can be used by sites, applications, connected devices, even a refrigerator! Why limit what we can do with a universal API by grouping secrets by sites? Now a website and an enterprise application can share a common set of secrets, regardless of the datacenter they’re in. And that’s just the beginning.

As part of the KeyRing creation process we also added in additional security steps to make the entire process even more secure. In order to create a production certificate on a non-partnering host, it will require using two-factor authentication via TOTP (time-based one time password). This is a similar step to the two-factor authentication you’re used to seeing by now on other applications and another way we can ensure that the secrets you have in your production environment are only given to authorized applications.

A whole new platform, same great service

With all this, Lockr 2.0 is, what we believe to be, the greatest secrets storage service out there. We’ve taken all the hassle out of on-boarding and setup of HSMs, provided extra layers of authentication and security to the registration process, created a universal architecture that can create a mesh network spanning regions, sovereignties, and even cloud infrastructure providers. This was no small feat, yet at the core we remain the same platform we’ve always been. Deeply committed to simplifying secrets management in order to protect applications regardless of their size or budget. There are many more features built into Lockr 2.0 that we’re polishing up to release in due time, this is only the beginning. However, this new architecture will provide existing customers an immediate performance boost, and even more simplicity in setting up and managing their application environments. In order to make the switch to 2.0 as smooth as possible, the new network architecture is also backwards compatible. Meaning an update to the new modules and plugins aren’t necessary right away to get the performance boost. Sites can update as they are able. And once they do, they can take advantage of the new features like shared KeyRings. New applications using the Lockr 2.0 plugins and modules will begin to get all the benefits of Lockr 2.0 right away.

Lockr strives to democratize cyber security, and the newest release is a large step in that direction. The new architecture will help us to continue to deliver on our motto “Any Key, Anywhere” and usher in a new way of securing applications regardless of the budget or technical team behind them.