routing…
guide
From a new account to a gateway carrying traffic under a policy you wrote. Roughly thirty minutes, most of it waiting on your cloud provider.
You need a cloud account you can deploy into, and permission to create a VPC-attached instance in it. Telaron deploys gateways into your own network rather than hosting them, so the fabric runs inside your perimeter and your packets never traverse ours.
Alpha access
The platform is in closed alpha. Accounts are provisioned on request rather than self-serve, so start with a conversation and we will open one for you.
A cluster is a group of gateways in one region, and it is the unit everything else attaches to. Create one from Command Center, or POST to the clusters endpoint. Nothing is deployed yet — a cluster is a declaration of where the fabric will exist.
Each cluster issues short-lived enrolment tokens. A token is what lets a gateway prove which cluster it belongs to on first contact, so it is the one secret in this flow worth handling carefully. Mint it when you are ready to boot the appliance, not before.
Bring up a gateway in your VPC with the enrolment token in its startup configuration. It dials the control plane over TLS, presents the token, and registers itself against the cluster. Gateways reach your project in one of two ways — Telaron provisions them when you onboard, or you launch one from a cloud marketplace listing — and neither is available yet, so this is the step where the path stops today. See Current limits.
Spokes are the workload networks that reach the fabric. On GCP a spoke is a VPC peered with the network your gateways run in, plus a route that sends its traffic through them. Telaron can build both, but that step is not running yet, so today you create the peering and the route yourself — see Current limits.
A policy names the hosts that may talk to each other and on which ports. Policies are versioned and inert until activated, so you can stage a change and cut over deliberately. See the policy section below for the document shape.
Policies are YAML. A document declares endpoints, which name individual hosts, and rules, which allow, deny or log a directed flow between two of them. Every rule names endpoints declared in the same document, so a policy is readable on its own without a lookup elsewhere.
version: 1
endpoints:
- name: app-server
ip: 10.20.0.11
- name: database
ip: 10.30.0.42
rules:
- from: app-server
to: database
protocol: tcp
port: 5432
action: allowProtocol is one of tcp, udp, icmp or any. Action is one of allow, deny or log. A port belongs only to a tcp or udp rule — icmp and any carry no port, and a document that gives them one is rejected rather than quietly ignoring the field.
Endpoints are single hosts, not ranges
An endpoint names one IPv4 address. A prefix is rejected when the policy is submitted, with an error naming the endpoint and the value. This is a current limit of the datapath rather than a syntax preference — see Current limits.
Creating a policy stores it. Creating a version stores a new revision of it. Neither takes effect on its own — activation is a separate call, and it is what pushes the compiled configuration to the gateways in the cluster. A policy you have written but not activated enforces nothing, deliberately, so that authoring and cutover are two decisions rather than one.
Everything Command Center does goes through the same public API, so anything you can click you can script. Mint an API key from Command Center, send it as a bearer token, and name your organisation in the tenant header on every request.
curl https://api.dev.telaron.io/api/v1/clusters \
-H "Authorization: Bearer $TELARON_API_KEY" \
-H "X-Tenant-ID: $TELARON_TENANT_ID"API keys carry the permissions of the role you grant them, and every call is recorded in your audit log. Treat a key as you would a long-lived credential: scope it, rotate it, and delete it when the automation that used it is retired.