Getting Started

Everything you need to know to get started with Formant.

    Security

    Formant provides end-to-end encryption and identity across all robots, networks, operators, and APIs. 

    The diagram below depicts the Formant security model.

    Provisioning Tokens

    The Formant Agent uses a one-time, short-lived provisioning token to generate a Robot Private Key. This private key is never sent to the cloud. The corresponding Robot Public Key is used to provision the robot and is stored on our backend to verify signed requests from robots.

    Load Balancers, WAFs, and Public vs. Private Subnets

    Our first layer of security is our public-facing load balancer. Attached to the load balancer is a web application firewall that provides protection against DDOS, blacklists bad IPs, and enforces other security measures. We also run our entire API layer in private subnets ensuring no external access to any of our cloud computing instances or databases.

    Enforcing Identity of Robots, Users, and Services

    At the application layer, we authenticate and authorize every API call with the client’s robot, user, or service identity. This design stands in contrast to an "API token" structure, which supports anonymous clients. The identity associated with every API call in the Formant system allows us to support fine-grained access control, permission revocation, and auditing. For additional protection, we ensure that robot and user private keys are never sent on the wire. Service tokens within our backend rely on symmetric encryption and rotate frequently.

    An important implementation detail is how a robot, user, or service proves their identity. For each of these API calls we leverage JSON Web Tokens to confirm the identity of the caller. These are short-lived tokens considered to be industry-standard in modern cloud applications. This architecture makes it so Formant never needs to send a permanent private key across the wire.

    TLS End-to-End

    For many applications deployed to public clouds, TLS termination at the load balancer and HTTP (plain text) traffic would prove sufficient. However, Formant’s cloud employs mutual TLS to ensure encrypted traffic everywhere— between the ingress controller and APIs, as well as between the APIs themselves.

    We leverage several technologies to achieve this. First, our APIs are running within a Kubernetes cluster, which allows us to deploy Istio—an open-source, platform-independent service mesh, which provides traffic management, policy enforcement, and telemetry collection. Within this service mesh, we enable mutual TLS, an Istio feature that allows us to encrypt all traffic between the ingress controller and APIs, as well as between separate APIs. The service mesh also allows us to employ a second layer of defense against misbehaving applications or bad actors with layer 7 (application networking layer) policy rules.

    Customizations for LANs: Encryption via gRPC

    For distributed, on-site LANs, on which the Formant Agent may be running on a separate host, we support an advanced feature to encrypt gRPC traffic between a robot application and the Formant Agent. In most cases, we see the robot application running on the same host as the Formant Agent, in which case plain text traffic is acceptable. However, we do encourage our security-conscious customers to consider using this feature.

    © 2020 Formant • 1999 Bryant St · San Francisco, CA 94110