Formal's Architecture
What is the technical architecture of Formal?
Overview
Formal is built to sustain failure without interrupting the flow of data or compromising data security. Because security and reliability are at the heart of every line of code we write, we believe in Kerckhoffs’ principle — that a developer should only use cryptosystems about which everything is known. Thus, we share as much information about Formal with our customers as possible.
At the heart of Formal is the Formal Sidecar, an easily deployed, cloud-native reverse proxy. Organizations can use Formal Sidecar’s stateless interception technology to understand and control their data.
Formal’s architecture relies on two main parts: a control plane and a data plane. The control plane is SaaS-based, while the data plane is self-hosted. In the self-hosted model, Formal’s users can choose between the Managed Cloud model (where Formal automatically provisions infrastructure in a connected Cloud Account) or the On-Premise model.
Below, you will find more information on Formal’s different deployment models.
Deployment Models
Self-Hosted
In the self-hosted model, the Control Plane is run by Formal, but the Data Plane is deployed and runs on the customer’s infrastructure. This model has one great advantage for the customer: data ownership remains entirely with the customer. All data flows and sensitive information stay inside the customer’s environment where the Formal Sidecar is deployed, creating no risk of leakage.
The deployment of the Data Plane in the customer’s cloud can be done in two ways:
-
Customer-managed: Formal provides a Docker container and the customer manages the infrastructure. Formal can also provide Terraform templates or Helm charts.
-
Formal-managed Cloud: The customer connects their cloud account in one click. Formal will then manage the infrastructure in the customer account.
Self-Hosted, Formal-Managed
As engineers, we at Formal believe that a great developer experience is the foundation of a secure product. That’s why we want to make it very easy for our customers to deploy the Data Plane within their infrastructure. With the managed cloud option Formal offers the best of both worlds, the facility of SaaS usage with the ownership of self-hosted deployment.
Customers can connect their AWS account in one click. Formal will deploy a Cloud Formation Stack that automates the deployment of a cross-account IAM role. This method works by creating an IAM Role in the customer’s AWS account with a specific set of permissions and then specifying which other IAM Roles have the permissions to “assume” that role.
In the Formal AWS account, we create one IAM User and IAM Role per customer. This IAM user can assume that IAM Role and that role is configured to assume the role in the customer’s account. This process is called Role Chaining and again creates a model where the user is maintained separately from the role. This allows Formal to make API calls on behalf of the customer.
An essential aspect of the security of the AWS IAM role we create is that Formal uses an External ID.
In abstract terms, the external ID allows the user that is assuming the role to assert the circumstances in which they are operating. It also provides a way for the AWS account owner to allow the role to be assumed only under specific circumstances. The primary function of the external ID is to address and prevent the confused deputy problem.
Using this IAM role we can create a VPC in the customer infrastructure. We then deploy an ECS Cluster in which the Sidecars will run inside this VPC. We create a VPC peering connection between the Formal Data Plane VPC and the Customer VPC in which the database is running.
Formal can also manage the AWS account for you and create a AWS account under Formal’s organization and leverage AWS Private Link to connect your VPC to the newly created one.
Self-Hosted, Customer-Managed
Formal will provide access to a downloadable Docker image. The customer must then provision their own infrastructure.
Note that OnPrem releases are different from Formal’s Managed releases, and that when you use this model, your version isn’t automatically updated.
How is Formal different?
While Formal is built around familiar proxy concepts, it has some important superpowers setting it apart:
Asynchronous policy enforcement
The Formal Sidecar efficiently handles read requests to the datastore, conducting an asynchronous analysis concurrently. This analysis includes blocking, filtering, or masking results as per applicable policies. By leveraging asynchronous request analysis, the original read operation proceeds seamlessly without experiencing any additional delays.
Stateless
Formal is a reverse proxy like ngnix. By operating at the TCP layer, Formal defers all session state management to the data layer connections themselves. This allows multiple containers to be deployed in a high-availability configuration.
Using Formal
Users can interact with Formal via the console. There is only one console for both admins (e.g. security team and managers) and data consumers (e.g. ICs, business analysts, and data scientists). However, the permissions differ depending on the role.
Admin permissions
With admin permissions, admins can:
- Manage Resources, Sidecars, Policies, Data Consumer Roles, and Groups
- Interact with Logs, Catalog, and Observability
- Integrate Cloud Accounts, SSO, and Encryption Keys
- and more.
Consumer permissions
With the consumer permissions, data consumers can only view their access credentials and each Proxy’s hostname.
Was this page helpful?