Gateway
Rules that run on every request before it reaches your app.
The gateway is part of Frontline, Teral's edge. It applies an environment's policies to each request. A policy can block a request outright or record more about it. Blocked requests never reach your instances, so they cost you nothing.
You manage policies on the app's Policies page, or through the API.
Policies
A policy has:
- a name, so you recognize it
- a type: Firewall blocks matching requests, Logging records more data about them
- match conditions, which decide which requests the policy applies to
- the environments it applies to: production, preview or both
The gateway goes through the policies in order. The first policy that blocks a request ends the evaluation.
Policies are copied into a deployment when the deployment is created, like other settings. After changing them, deploy again, for example with Redeploy, so the change reaches live traffic.
Match conditions
| Condition | Matches on |
|---|---|
| Path | The URL path without the query string |
| Method | One or more HTTP methods |
| Header | A header being present, or its value |
| Query parameter | A query parameter being present, or its value |
| Remote IP | The client's IP being inside, or outside, a list of addresses and CIDR ranges |
Paths, header values and query values can match in three ways:
- Exact:
/healthz - Prefix:
/api/matches everything below it - Regex:
^/users/[0-9]+$, using RE2 syntax
Each of them can ignore case. Header names never depend on case. Query parameter names do.
The remote IP is the address of the connection that reached Teral. It doesn't come from headers such as X-Forwarded-For, so clients can't spoof it.
Combining conditions
- All conditions of a policy have to match. Several conditions mean and.
- For or, create several policies with the same type and different conditions.
- A policy without conditions applies to every request.