Oso Self-Hosted Beta: Full-Stack Authorization in Your Own VPC

We’re excited to announce that Oso Self-Hosted is now in private beta! You can check out the documentation here. Oso Self-Hosted is a version of our authorization service that runs directly inside your own AWS account—giving you full control over your infrastructure and data.

Why We Built Oso Self-Hosted

While Oso is SOC 2 certified and we've worked hard to ensure Oso Cloud is secure and reliable, there are situations where a hosted cloud service simply isn't an option.

Some of our customers have told us that while they love the power of Oso Cloud, their internal policies or compliance requirements prohibit them from sending authorization requests outside their network. That means they’re blocked from using Oso—unless we provide a self-hosted solution.

Why We Are Starting with AWS

Our first version of Oso Self-Hosted will run on AWS. Jumping straight to bare metal would introduce too much risk and complexity at once. Instead, as a middle ground, we provide an installable Oso Self-Hosted package that you can run in your own AWS account.

AWS has an entire section dedicated to compliance, including programs like FedRAMP. In practice, that's enough for many customers, as long as they can deploy the solution within their own AWS environment. We’re working on expanding support beyond AWS, so if you're interested, please get in touch.

Oso Self-Hosted Compatibility

Here are the current deployment options for Oso Self-Hosted, with Oso Cloud, our hosted service, as a comparison:

Deploying and Managing Oso Self-Hosted

Our goal with Oso Self-Hosted is to give you more control, so we designed the deployment process to be as transparent as possible. We are using Infrastructure As Code (IaC) for the deployment of most resources, so you can see exactly what is being deployed. We also include a management tool, the Oso Manager, which can handle the Oso-specific management tasks.

This diagram gives an overview of the Oso Self-Hosted Lifecycle:

The Resources/Infrastructure steps are declarative infrastructure as code, with no dynamic setup. This means that Terraform can be swapped out with a similar deployment tool, such as Pulumi or CloudFormation, as long as the set of resources created is the same. Oso Self-Hosted is currently only supported on AWS.

The Management Tasks/Glue are steps that are either Oso specific, or that should be dynamic. For example, bootstrapping secrets are handled here, so that the Terraform configuration is not responsible for managing any sensitive data. This also includes managing Oso environments and Oso authorization tokens. All these tasks are built into the oso-manager CLI tool.

The Oso Service (Entry Point) is the Oso service itself that application clients connect to. When this is running successfully, the Oso Self-Hosted deployment is ready to use.

Oso Self-Hosted Architecture

The main dependencies of Oso Self-Hosted are MSK (Kafka), S3, and SQS. There are two main services deployed, the Oso Service and the Oso Snapshotter. Here’s a diagram of the architecture:

The Oso Service is the main entry point for Oso Self-Hosted and is what Application Clients will connect to from outside the Oso Self-Hosted VPC. Nothing else should be exposed outside the network.

The Oso Service maintains a full copy of all the authorization data on its local volume. At start time, it pulls an initial snapshot from S3 and streams updates from MSK (Kafka) to receive the latest write operations.

The Oso Snapshotter also maintains a full copy of all the authorization data on its local volume. It pulls an initial snapshot from S3 and streams updates from MSK (Kafka) in the same way as the Oso Service. However, it does not receive any user traffic and instead is responsible for periodically generating new snapshots and uploading them to S3. These snapshots are triggered by an SQS/Lambda task on a set schedule.

Oso Self-Hosted Management

In all our design decisions for Oso Self-Hosted, we are drawing a very clear line between which services are specific to Oso, and which services AWS is managing. The goal is to empower our customers, and give them a system they understand and are familiar with, while still providing the benefits of an Oso Service deployment.

To this end, we’ve captured the Oso specific workflows in an oso-manager tool. Everything that is specific to managing Oso itself should be supported by the oso-manager tool, while everything not specific to Oso can be managed using built in AWS tools. Familiar and boring is good—we want to avoid surprises.

Use Cases

Here are some example use cases for Oso Self-Hosted:

• Healthcare IT: Healthcare IT must comply with HIPAA regulations, which can be very complex, and are even more difficult when a third party service is involved.
• Banking and Financial Services: Financial institutions must also comply with regulations like PCI-DSS and GDPR, and often have a lot of internal bureaucracy to meet those regulations that make it more difficult to procure an external hosted service.
• US Government Agencies - Cybersecurity: Cybersecurity applications on the government level may need to be self-hosted not only because of compliance, but also because of how security critical these applications may be. Trusting a third party will always require a certain level of risk tolerance, and if an application is likely to be targeted by a nation-state government with significant resources, any weak link needs to be justified.
• US Government Agencies - Civilian: Government agencies mostly have to deal with compliance regulations, since that is the primary way that IT security gets enforced on government projects that are contracted out. FeDRAMP is one example for cloud services. A self-hosted solution that allows customers to deploy into a FeDRAMP-compliant environment may be enough to unlock these cases.

Next Steps

With Oso Self-Hosted in Beta, we’re looking forward to iterating based on feedback from our customers. Oso Self-Hosted is built to be adaptable, and we’re happy to work with you to ensure it meets your needs.

We’re committed to simplifying authorization, and Oso Self-Hosted allows you to use Oso while keeping full control of your infrastructure. Interested in trying it out? Get in touch with us.