15 posts tagged with "launch"

Happy Friday! It's the final day of Launch Week! In case you missed the previous days, you can catch up here: Day 1, Day 2, Day 3 and Day 4.

Throughout the week, we've talked about various nuts & bolts upgrades to the Warrant platform that bring improved performance, resiliency, and safety to the APIs and core authorization service.

Today, we're excited to introduce Warrant templates, a repository of pre-defined and purpose-built object types schemas designed to get you up and running with Warrant in minutes. Simply pick a template that matches your application use-case and deploy it into your Warrant environment using the CLI. Each template also ships with a test suite with sample tests, making it easy to iterate.

Welcome to Day 4 of Launch Week! In case you're just joining us, check out what we launched on Day 1, Day 2, and Day 3.

Yesterday's post detailed many of the enhancements we've made to Warrant over the past few months to improve overall performance and resiliency in production. Today's post is going to focus exclusively on testing and correctness, which are equally (if not more) important in an authorization service.

Happy hump day! Day 3 of launch week is focused entirely on some exciting performance and reliability upgrades for Warrant. In case you missed the previous days, here are the links: Day 1 and Day 2.

From the beginning, we've envisioned Warrant as a globally distributed, highly performant and highly available authorization service that developers can easily plug into their applications without worry. Building such a cloud service is tough. We're thankful to our customers who have entrusted us with powering their authorization and helped us evolve Warrant over the past year+ into a service that now processes millions of API requests per day while maintaining 99.995% availability (or < 30m of downtime per year).

Welcome to day 2 of our first Launch Week! On day 1, we introduced the new and improved v2 Warrant API. In case you missed it, you can catch up on the details here. Now let's get into day 2!

Warrant Query Language (WQL)​

In a recent blog post, Why Google Zanzibar Shines at Building Authorization, we detailed why Google Zanzibar is extremely well-suited to handling application authorization. One of the key reasons we covered is that Zanzibar is a stateful, centralized authorization service. This means the authorization rules for an application (along with any other data necessary to make authorization decisions for the application) are stored centrally in Zanzibar, making it possible to query access rules for a user or resource in real time without the need to consult another data source. This allows developers to not only audit users' access rules but to also query Zanzibar directly from their application to fetch only the resources a user has access to.

Today, we're excited to introduce the Warrant Query Language (WQL), a declarative, SQL-like language for querying Warrant for lists of access controlled data from the context of an application. In particular, WQL is there to help developers answer two types of queries from within their applications:

1. Which objects of type T does user U have access to?
2. Which users have access to object O?

Hey everyone! It's finally time to kick off our first ever Launch Week! Before we get started, for those of you who don't know: At Warrant, we're building authorization and access control infrastructure for developers.

The team has been hard at work over the past few months iterating on our platform in close partnership with our customers. We've improved many areas, from developer experience to performance and reliability, while also adding a slew of new features and can't wait to share more about everything we've built. Now let's get started!

On this inaugural day of Launch Week, we're excited to announce two huge releases:

• v1.0 of Warrant OSS, the open source, self-hostable authorization service powering Warrant
• Our v2 API, with tons of new features and improvements to both performance and developer experience

Let's get into the details!

Today, we're excited to announce that Warrant is officially open source! Check out the repo here.

A quick recap​

We started Warrant in June 2021 with the goal of bringing enterprise-grade access control to all applications. Warrant began as a simple API which developers could integrate into their apps in order to implement and manage role based access control (RBAC). Over time, with feedback from customers, we've iterated considerably on the core platform, evolving it into a complete access control system that supports everything from RBAC to more modern access control paradigms like fine grained access control (FGAC), attribute based access control (ABAC) and relationship based access control (ReBAC).

Our cloud-first and API-first approach has enabled us to build a system that is highly-scalable and performant, to the tune of millions of customer API calls per month. As we look ahead, we want to establish a better community and better practices around application access control, and believe that making Warrant open source is the best path forward.

Maintaining separate environments for development/testing and production is a common practice on most engineering teams as a way to improve team productivity, prevent bugs, and speed up release cycles by giving the team more confidence in the changes being made before they're released to customers. For many teams, this often goes beyond the basic production and test environments that Warrant currently supports, including individual developer environments that allow each developer to work independently with their own, separate set of data. Today, we're excited to introduce custom environments and access control across all environments!

What is it?​

Custom Environments​

Teams can now create their own custom environments in addition to the pre-existing production and test environments. While production and test work for some teams, others need more environments like staging or QA. Some organizations also want to distinguish between development and test environments if they run automated tests. Other customers have even mentioned wanting to keep their data models separate for different internal applications. With custom environments, you can set up your Warrant environments to mirror your development workflow and your applications & their different environments.

Environment Permissions​

Teams can now also limit who has access to each environment. For example, organizations may only want to give a subset of team members access to the production environment, or developers with their own environment might want to limit who has access to it so that their data isn't modified by anyone else. With environment permissions, you can now control who can and can't access your environments in Warrant.

Today, we're excited to launch support for Pricing Tiers and Feature Flags!

While our core platform has always supported the ability to implement custom pricing tiers and feature flags, it required a lot of upfront work for teams to implement. We strongly believe these are common problems encountered at every software company so we built native support for pricing tiers and feature flags into Warrant.

What is it?​

Pricing Tiers​

Figuring out how to price your SaaS product is a complex enough problem by itself, often requiring several iterations of experimentation to determine. Tiered pricing (or pricing tiers) is a common pattern for SaaS startups to charge customers for their product today. In this approach, a company grants customers access to premium and enterprise level features only if the customer is subscribed to a paid or enterprise plan. This strategy comes with its own set of challenges: What should I include in my free tier? How much should I charge for a pro/premium tier? What features should be considered enterprise features? With Warrant's built-in support for pricing tiers, you can easily limit access to premium features in your product based on each customer's subscription, giving you the flexibility to control which features are available in a pricing tier and match changing customer personas. You also have the ability to grant/revoke access to individual features per user or customer for one-off scenarios.

Feature Flags​

Software teams looking to iterate quickly and frequently release functionality with reduced risk typically make abundant use of feature flags. Warrant now has built-in support for feature flags, so teams can incrementally release features individually to customers. Common uses for feature flags might be enabling a beta feature for certain users or rolling out a feature only to specific customer segments. When bugs arise, feature flags can be useful for quickly disabling a faulty feature, allowing teams to avoid performing a complete deployment rollback or scrambling to release a fix.

Building and maintaining a role-based access control (RBAC) model at a growing company can be a challenge as your application evolves with continually changing product requirements. As requirements and features are updated, your access model needs to keep up. Today, we're excited to introduce a new concept and features to help you manage your RBAC model with less complexity: implied roles and permissions.

What is it?​

Many RBAC models involve some sort of inheritance, where an admin role may have all the permissions of a lesser role plus more admin-specific permissions. This can involve duplication of permission assignments across roles and quickly turn your roles and permissions into a complex mess that's difficult to manage.

We've eliminated the need for this duplication and made it simpler to manage complex RBAC models via API or Dashboard with the concept of implied roles and permissions. With implied roles and permissions, you can define a role or permission that will automatically be implied when a user is assigned a particular role or permission. For example, a manager and basic role can be implied by the admin role so any user with the admin role will automatically be granted the capabilities of both the manager and basic roles.

The two primary ways to view, manage and enforce an access model in Warrant include APIs and the admin dashboard. Today we're introducing a third way, geared towards power users, especially those that ❤️ automation: a native command-line interface (CLI).