Kubernetes gateway security

Open a cluster and go to Security to decide what its managed gateway lets through to your websites and APIs. Every setting runs at the gateway, before a request reaches your pods, so your apps need no change.

Each setting applies to every hostname of the cluster, or only to the hostnames you pick: the cluster's own hostname, its extra names and your own domains. The section is there once the managed gateway is on; Services of type LoadBalancer are not covered by it.

How changes apply

• Nothing changes until you save. Add, edit, reorder, switch off and remove as much as you like; the section counts your unsaved changes. Review and save lists exactly what changes, and nothing reaches the gateway until you confirm.
• About a minute later it is live. Each rule shows Applying until the cluster reports it, then Applied, or Failed with the reason.
• Two people editing at once. If someone saved after you opened the page, your save is refused, the latest version is loaded and your edit stays on screen, so you can review it again.
• Who can change it. Workspace owners, admins and developers; turning managed rules on needs an owner or admin. Viewers, and support staff helping you, see the settings read-only.

Always on, on every hostname

As soon as any setting on this page is on, the gateway applies these to every hostname of the cluster, whatever each hostname's own settings:

• Paths are cleaned up. Repeated slashes are merged, and a path with an encoded slash or backslash (%2F, %5C) gets 400, so a path cannot be spelled two ways to slip past a rule.
• Dot segments with parameters count as steps. A . or .. segment followed by ; parameters, such as /static/..;/admin, is a step up the path to some servers, so the gateway reads it as one and every rule sees /admin. Written with an encoded ; (%3B), it gets 403.
• The profile's timeouts and header rules apply to every hostname, including ones you gave no settings of their own.
• Your own gateway policies are refused. While anything here is on, the cluster refuses new gateway policies in your own namespaces; see Your own policies.

Review and save lists these when a save turns security on for the first time.

A hostname with settings of its own gets a listener of its own on the gateway. A route of yours pinned to the gateway's main listener, with sectionName: http in its parentRefs, then stops answering on that hostname: Review and save names each such route, and saving waits until you confirm. Remove the route's sectionName to let it answer everywhere.

Overview and security profile

Overview says whether the latest change is applied, and how many requests the gateway refused in the last hour: blocked, rate limited, refused at sign-in, and flagged by managed rules.

The security profile is the base every hostname of the cluster gets:

A blocked path covers everything that starts with it: /.env also blocks /.env.local, and /.git blocks /.git/config. A request for one gets 403. Standard suits most sites; pick Strict for an API or an admin tool that never needs large uploads or slow clients. To serve one of the blocked paths on purpose, add a firewall rule that allows it: an allowed request skips the profile's list.

To fine-tune the profile, edit its Blocked paths: add your own, remove one of the profile's, or go back to the profile's list, with each path marked From the profile or Custom. Under Limits, keep the profile's value, set your own, or turn a limit off: request bodies from 1 to 10,240 MB, time to send headers from 1 to 300 s, idle connections from 5 to 3,600 s, and requests per address from 1 to 100,000 a second. Edits go through the same review before saving, and your own list and limits are kept when you change the profile. Both apply to every hostname of the cluster: to block a path on one hostname only, use a firewall rule.

Firewall rules

Firewall rules run top to bottom for every request, and the first rule that matches decides. A request no rule matches goes on to the profile.

A request matches a rule when it matches every field you filled in, and within a field any one entry is enough. A field left empty matches anything.

• Client addresses: IPv4 or IPv6 addresses or ranges, such as 203.0.113.10 or 198.51.100.0/24. This is the visitor's own address, as it reached the platform's edge.
• Paths: Is exactly compares the whole path; Starts with compares its beginning as text; Matches pattern takes a regular expression that must match the whole path, such as /api/v[0-9]+/internal/.*. A pattern reads the path only, never the query string after ?: on an Allow rule, .*\.css$ lets /site.css?v=2 through but not /.env?x=.css. Patterns stay simple so they stay fast: no look-ahead, look-behind or back-references, at most two counted repeats such as {2,5}, none above 30, and 200 characters at most.
• Methods: GET, POST and the others. None selected matches every method. A Deny or Allow only rule, and a rate limit, that names methods also takes HEAD with GET, and OPTIONS, since servers answer those from the same handlers.
• Headers: each header listed must be on the request with one of its values. Headers the platform sets, such as Host, X-Forwarded-For, Authorization and Cookie, cannot be matched.

Use the arrows to change the order, and the switch to turn a rule off without removing it.

Example: block /.git and /.env

The Standard profile already blocks these. With the profile Off, or to make sure, add a rule:

The empty Firewall rules section offers this rule as an example to start from.

Example: allow /admin only from your office

Everyone else gets 403 on /admin and below, and the rest of the site is untouched. If your office has several addresses, list each on its own line, or the range.

A Deny or Allow only rule scoped to hostnames also applies on the cluster's own hostname, unless you turn off Also apply it on the cluster's own hostname: your other hostnames point to it, so a route without hostnames serves the same pages there, and a request for that hostname would step around the rule. An Allow rule applies only on the hostnames it names. Review and save warns when a route would still serve the rule's pages on a hostname the rule does not cover.

Rate limiting

A rate limit caps how many requests one client address may send: counted per hostname, or per hostname and path when you give a path. Over the limit the gateway answers 429.

• Limit: a number of requests per second, per minute or per hour.
• Burst: a client may spend a whole period's allowance at once, then waits for it to refill. A limit of 600 per minute lets 600 requests through in a burst, then about 10 a second.
• Applies to: every hostname or the ones you pick, one path at most, and optionally only some methods.
• Also on the cluster's own hostname: on by default for a limit scoped to hostnames, so a client cannot step around it through the hostname the others point to; it counts there separately. Review and save warns when a route would serve the limited pages on a hostname the limit does not cover.
• Counted per proxy. The gateway runs several proxies and each counts what reaches it, so the platform divides each limit between them: a client's total stays close to the limit. A limit lower than the number of proxies lets one request through per proxy.

Example: rate-limit /api

Each client address may then make 10 requests a second to /api on each hostname; a client over it gets 429 until its allowance refills. Allowed requests and requests that pass a firewall rule still count.

Authentication

Authentication asks for a username and password before any page of a hostname, in the browser's own sign-in prompt. Use it for staging sites and internal tools that should not be public.

• Users: up to 50 per hostname, each with a password of 12 to 128 characters.
• Passwords are entered once and never shown again, in the console or through the API: the platform keeps only a hash. When you edit a user, leave the password empty to keep it. Keep the passwords in your own password manager.
• Also require an address: optional. With addresses listed, a visitor needs an allowed address and a valid password.
• Requests without a valid password get 401.
• Also on the cluster's own hostname: on by default. Your other hostnames point to the cluster's own hostname, so a route without hostnames serves the same pages there too; with this on, that hostname asks for the same sign-in. When several hostnames' sign-ins cover it, only a user they all share, with the same password, from an address they all allow, gets in, and if they share none, the cluster's own hostname lets nobody in. Turn it off only when the cluster's own hostname serves sites anyone may open, and give the protected routes hostnames of their own.
• Never open by mistake: if a stored password cannot be read, the hostname lets nobody in, and Security marks the sign-in Failed, until you set the passwords again.

Sign-in with tokens (JWT) and single sign-on (OIDC) are coming soon.

Example: basic auth for a staging hostname

1. In Authentication, choose Protect a hostname, and pick the staging hostname, such as staging.example.com.
2. Add a user, such as team, with a long password.
3. Review and save. A minute later, the hostname, and the cluster's own hostname, ask for the username and password. Your other hostnames ask for it only if a route serves them the same pages: Review and save warns before saving when a route without hostnames, or with several, would still serve the protected pages on a hostname without sign-in. Give such a route its own hostnames, or protect those hostnames too.

CORS

CORS lets web pages on other origins call a hostname from the browser, such as a single-page app on https://app.example.com calling an API on api.example.com. The gateway answers the browser's preflight requests and adds the CORS headers, so your API does not have to.

Each hostname has one CORS setting. If your app already sends CORS headers itself, leave this off for its hostname.

Managed rules

Managed rules inspect each request for common attacks, such as SQL injection, cross-site scripting and path traversal, with a rule set the platform keeps up to date.

Strictness goes from level 1, with few false alarms, to level 4, the strictest. A higher level catches more attacks and flags more ordinary requests by mistake. Start in Detect only at level 1, watch the count on Overview for a few days, then switch to Block, and raise the level one step at a time.

• Memory. Managed rules add about 600 MB of memory to each gateway proxy, on your worker nodes, and the platform reserves it for them. If no worker node has room, Security says what the nodes lack and the proxy waits: add a worker, use larger workers, or turn managed rules off.
• Applies to. Every hostname, or the ones you pick and, unless you turn it off, the cluster's own hostname too, so requests cannot step around the rules through the hostname the others point to. Review and save warns when a route would serve the same pages on a hostname the rules do not cover.
• Who can turn them on. A workspace owner or admin. Once they are on, anyone who may change the cluster can change the mode and strictness, or turn them off.

Managed rules are being rolled out. Until a cluster can run them, the section shows Coming soon.

Gateway proxies

The managed gateway runs its traffic through proxies on your workers, whether or not any setting here is on.

• How many. One on a single-worker cluster. Once the cluster has two workers, two, one per worker, and as load grows up to one per worker, six at most. A worker whose taints keep other pods off, such as a GPU pool, does not count. No two proxies share a worker while each can have its own, so losing a worker leaves the others serving; while a worker is drained or down, two may share one rather than wait.
• What they reserve. Each proxy reserves 0.2 CPU and 256 MB of memory on a worker, 1 GB with managed rules on, and may use up to 2 CPU.
• Updates and drains. A new proxy starts before the old one stops, and a worker is drained only while another proxy keeps serving, so traffic does not stop.
• More of them. Under Gateway proxies, raise At least and At most, up to 10 each. Never more than one per worker runs: add workers to run more. The cluster grows past the lower bound only while it serves pod metrics.

Your own policies

These settings belong to the managed gateway. While anything here is on, the cluster refuses new gateway policies in your own namespaces, so none can replace these settings. One that was already there when you turned security on still replaces these settings for its routes: Security, and Review and save before you turn it on, list each one by namespace and name. Remove yours to let the cluster's settings apply.

Limits

API

Every PUT carries the revision you read: one without it gets 400, and the write is refused with 409 CONFLICT when someone else saved in between. A user's password is sent only to set or change it, and is never in a response. Use an API token with kubernetes:update to write.

{
  "revision": 4,
  "firewall": [
    {
      "name": "Block secret files",
      "action": "deny",
      "paths": [
        { "type": "prefix", "value": "/.git" },
        { "type": "prefix", "value": "/.env" }
      ]
    }
  ]
}