Project: Skipper (Orchestration & Management / Service Proxy)
File: filters.md

The parameters can be strings, regex or float64 / int `string` is a string surrounded by double quotes (`"`) `regex` is a regular expression, surrounded by `/`, e.g. `/^www\.example\.org(:\d+)?$/` `int` / `float64` are usual (decimal) numbers like `401` or `1.23456` `time` is a string in double quotes, parseable by ) Filters are a generic tool and can change HTTP header and body in the request and response path. Filter can be chained using the arrow operator `->`. Example route with a match all, 2 filters and a backend: ``` all: * -> filter1 -> filter2 -> "http://127.0.0.1:1234/"; ``` Several filters support template placeholders (`${var}`) in string parameters. Template placeholder is replaced by the value that is looked up in the following sources: request method (`${request.method}`) request host (`${request.host}`) request url path (`${request.path}`) request url rawquery (`${request.rawQuery}`, encoded request URL query without `?`, e.g. `q=foo&r=bar`) request url query (if starts with `request.query.` prefix, e.g `${request.query.q}` is replaced by `q` query parameter value) request headers (if starts with `request.header.` prefix, e.g `${request.header.Content-Type}` is replaced by `Content-Type` request header value) request cookies (if starts with `request.cookie.` prefix, e.g `${request.cookie.PHPSESSID}` is replaced by `PHPSESSID` request cookie value) request IP address `${request.source}` - first IP address from `X-Forwarded-For` header or request remote IP address if header is absent, similar to predicate `${request.sourceFromLast}` - last IP address from `X-Forwarded-For` header or request remote IP address if header is absent, similar to predicate `${request.clientIP}` - request remote IP address similar to predicate response headers (if starts with `response.header.` prefix, e.g `${response.header.Location}` is replaced by `Location` response header value) filter context path parameters (e.g. `${id}` is replaced by `id` path parameter value) Missing value interpretation depends on the filter. Example route that rewrites path using template placeholder: ``` u1: Path("/user/:id") -> setPath("/v2/user/${id}") -> <loopback>; ``` Example route that creates header from query parameter: ``` r: Path("/redirect") && QueryParam("to") -> status(303) -> setResponseHeader("Location", "${request.query.to}") -> <shunt>; ``` Sets the response status code to the given value, with no regards to the backend response. Parameters: status code (int) Example: ``` route1: Host(/^all401\.example\.org$/) -> status(401) -> <shunt>; ``` No operation, only to comment the route or a group of filters of a route Parameters: msg (string) Example: ``` route1: * -> comment("nothing to see") -> <shunt>; ``` Annotate the route, subsequent annotations using the same key will overwrite the value. Other subsequent filters can use annotations to make decisions and should document the key and value they use. Parameters: key (string) value (string) Example: ``` route1: * -> annotate("never", "gonna give you up") -> annotate("never", "gonna let you down") -> <shunt>; ``` Sets the incoming `Host: ` header on the outgoing backend connection. It can be used to override the `proxyPreserveHost` behavior for individual routes. Parameters: "true" or "false" "true" - use the Host header from the incoming request "false" - use the host from the backend address Example: ``` route1: * -> preserveHost("true") -> "http://backend.example.org"; ``` Replace all matched regex expressions in the given header. Parameters: header name (string) the expression to match (regex) the replacement (string) Example: ``` enforce_www: * -> modRequestHeader("Host", "^zalando\.(\w+)$", "www.zalando.$1") -> redirectTo(301); ``` Set headers for requests. Header value may contain . If a template placeholder can't be resolved then filter does not set the header. Parameters: header name (string) header value (string) Examples: ``` foo: * -> setRequestHeader("X-Passed-Skipper", "true") -> "https://backend.example.org"; ``` ``` // Ratelimit per resource Path("/resource/:id") -> setRequestHeader("X-Resource-Id", "${id}") -> clusterClientRatelimit("resource", 10, "1m", "X-Resource-Id") -> "https://backend.example.org"; ``` Same as , but appends the provided value to the already existing

Removes a header from the request Parameters: header name (string) Example: ``` foo: * -> dropRequestHeader("User-Agent") -> "https://backend.example.org"; ``` Same as , only for responses Parameters: header name (string) the expression to match (regex) the replacement (string) Example: ``` donotavoid_caching: * -> modResponseHeader("cache-control", "no-cache", "cache") -> "https://zalando.de"; ``` Same as , only for responses Example: ``` setcookiewithpathparam: Path("/path/:id") && Method("GET") -> setResponseHeader("Set-Cookie", "cid=${id}; Max-Age=36000; Secure") -> redirectTo(302, "/") -> <shunt> ``` Same as , only for responses Same as but for responses from the backend Set headers for requests using values from the filter context (state bag). If the provided key (second parameter) cannot be found in the state bag, then it doesn't set the header. Parameters: header name (string) key in the state bag (string) The route in the following example checks whether the request is authorized with the oauthTokeninfoAllScope() filter. This filter stores the authenticated user with "auth-user" key in the context, and the setContextRequestHeader() filter in the next step stores it in the header of the outgoing request with the X-Uid name: ``` foo: * -> oauthTokeninfoAllScope("address_service.all") -> setContextRequestHeader("X-Uid", "auth-user") -> "https://backend.example.org"; ``` Same as , but appends the provided value to the already existing ones. Same as , except for responses. Same as , except for responses. Copies value of a given request header to another header. Parameters: source header name (string) target header name (string) Example: ``` foo: * -> copyRequestHeader("X-Foo", "X-Bar") -> "https://backend.example.org"; ``` Same as , except for responses. The filter accepts an optional variadic list of acceptable origin parameters. If the input argument list is empty, the header will always be set to `*` which means any origin is acceptable. Otherwise the header is only set if the request contains an Origin header and its value matches one of the elements in the input list. The header is only set on the response. Parameters: url (variadic string) Examples: ``` corsOrigin() corsOrigin("https://www.example.org") corsOrigin("https://www.example.org", "http://localhost:9001") ``` Filter which assigns the value of a given header from the incoming Request to a given query param Parameters: The name of the header to pick from request The name of the query param key to add to request Examples: ``` headerToQuery("X-Foo-Header", "foo-query-param") ``` The above filter will set `foo-query-param` query param respectively to the `X-Foo-Header` header and will override the value if the queryparam exists already Sets an X-Flow-Id header, if it's not already in the request. This allows you to have a trace in your logs, that traces from the incoming request on the edge to all backend services. Flow IDs must be in a certain format to be reusable in skipper. Valid formats depend on the generator used in skipper. Default generator creates IDs of length 16 matching the following regex: `^[0-9a-zA-Z+-]+$` Parameters: no parameter: resets always the X-Flow-Id header to a new value `"reuse"`: only create X-Flow-Id header if not already set or if the value is invalid in the request Example: ``` -> flowId() -> "https://some-backend.example.org"; -> flowId("reuse") -> "https://some-backend.example.org"; ``` Standard proxy headers. Appends the client remote IP to the X-Forwarded-For and sets the X-Forwarded-Host header. Same as , but instead of appending the last remote IP, it prepends it to comply with the approach of certain LB implementations. Replace all matched regex expressions in the path. Parameters: the expression to match (regex) the replacement (string) Example: ``` rm_api: Path("/api") -> modPath("/api", "/") -> "https://backend.example.org"; append_bar: Path("/foo") -> modPath("/foo", "/foo/bar") -> "https://backend.example.org"; new_base: PathSubtree("/base") -> modPath("/base", "/new/base) -> "https://backend.example.org"; rmapiregex: Path("/api") -> modPath("^/api/(.*)/v2$", "/$1") ->

``` Replace the path of the original request to the replacement. Parameters: the replacement (string) The replacement may contain . If a template placeholder can't be resolved then empty value is used for it. Creates an HTTP redirect response. Parameters: redirect status code (int) location (string) - optional Example: ``` redirect1: PathRegexp(/^\/foo\/bar/) -> redirectTo(302, "/foo/newBar") -> <shunt>; redirect2: * -> redirectTo(301) -> <shunt>; ``` Route redirect1 will do a redirect with status code 302 to https with new path `/foo/newBar` for requests, that match the path `/foo/bar`. Route redirect2 will do a `https` redirect with status code 301 for all incoming requests that match no other route see also Same as , but replaces all strings to lower case. Removes the query parameter from the request URL, and if the first filter parameter is `"true"`, preserves the query parameter in the form of `x-query-param-<queryParamName>: <queryParamValue>` headers, so that `?foo=bar` becomes `x-query-param-foo: bar` Example: ``` -> stripQuery() -> "http://backend.example.org"; -> stripQuery("true") -> "http://backend.example.org"; ``` Set the query string `?k=v` in the request to the backend to a given value. Parameters: key (string) value (string) Key and value may contain . If a template placeholder can't be resolved then empty value is used for it. Example: ``` setQuery("k", "v") ``` Delete the query string `?k=v` in the request to the backend for a given key. Parameters: key (string) Key may contain . If a template placeholder can't be resolved then empty value is used for it. Example: ``` dropQuery("k") ``` Filter which assigns the value of a given query param from the incoming Request to a given Header with optional format string value. Parameters: The name of the query param key to pick from request The name of the header to add to request The format string used to create the header value, which gets the value from the query value as before Examples: ``` queryToHeader("foo-query-param", "X-Foo-Header") queryToHeader("access_token", "Authorization", "Bearer %s") ``` The first filter will set `X-Foo-Header` header respectively to the `foo-query-param` query param and will not override the value if the header exists already. The second filter will set `Authorization` header to the `access_token` query param with a prefix value `Bearer ` and will not override the value if the header exists already. Filters that provide access to TLS data of a request. This filter copies TLS client certificates encoded as pem into the X-Forwarded-Tls-Client-Cert header. Multiple certificates are separated by `,`. Example: ``` -> tlsPassClientCertificates() -> "http://10.2.5.21:8080"; ``` These filters are meant for diagnostic or load testing purposes. Generate response with random text of specified length. Parameters: length of data (int) Example: ``` -> randomContent(42) -> <shunt>; ``` Generate response of specified size from repeated text. Parameters: text to repeat (string) size of response in bytes (int) Example: ``` -> repeatContent("I will not waste chalk. ", 1000) -> <shunt>; ``` Generate response of specified size from repeated bytes. Parameters: bytes to repeat (hexadecimal string) size of response in bytes (int) Example: ``` -> repeatContentHex("00", 100) -> <shunt> ``` ``` // Create binary response using size equal to the number of bytes to repeat, i.e. repeat once -> repeatContentHex("68657861646563696d616c", 11) -> <shunt> ``` Add prefix and suffix to the response. Parameters: prefix (string) suffix (string) Examples: ``` -> wrapContent("foo", "baz") -> inlineContent("bar") -> <shunt> ``` ``` // JSON array of 100 zeros -> wrapContent("[", "0]") -> repeatContent("0, ", 297) -> <shunt> ``` Add prefix and suffix to the

Parameters: prefix (hexadecimal string) suffix (hexadecimal string) Examples: ``` -> wrapContentHex("68657861", "6d616c") -> inlineContent("deci") -> <shunt> ``` ``` // 1G of gzip-compressed text -> setResponseHeader("Content-Encoding", "gzip") -> wrapContentHex( "1f8b08000000000004ffecd6b10d00200804c05598c5b80a852d0ee422762ce61c2657d212f8bf9915bb6f9f8c51b9c26c1feec13fc80379a80ff4210ff0000ff0000ff0000ff0000ff0000ff0000ff0000ff0000ff0000ff0000ff0000ffce781070000ffffecd6810c000000c0207feb737c8ba2f8cd6f7ef39bdffce637bf", "7dc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077ce0ff81000000ffffecd6810000000080207feb418ea278ce739ef39ce73ce739cf7de0f581000000ffff010000ffff5216994600ca9a3b" ) -> repeatContentHex("7dc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077cc0077ce0ff81000000ffffecd6810c000000c0207feb737c8ba278ce739ef39ce73ce739cf", 8300624) -> <shunt> ``` You may use https://github.com/AlexanderYastrebov/unrepeat to decompose binary file into prefix, repeating content and suffix. Enable adding artificial latency Parameters: latency in milliseconds (int) or in `time` as a string in double quotes, parseable by ) Example: ``` -> latency(120) -> "https://www.example.org"; -> latency("120ms") -> "https://www.example.org"; ``` Enable bandwidth throttling. Parameters: bandwidth in kb/s (int) Example: ``` -> bandwidth(30) -> "https://www.example.org"; ``` Enables adding chunking responses with custom chunk size with artificial delays in between response chunks. To disable delays, set the second parameter to "0". Parameters: byte length (int) time duration (time.Duration) Example: ``` -> chunks(1024, "120ms") -> "https://www.example.org"; -> chunks(1024, "0") -> "https://www.example.org"; ``` Same as , but on the request path and not on the response path. Same as , but on the request path and not on the response path. Same as , but on the request path and not on the response path. The tarpit filter discards the request and respond with a never ending stream of chunked response payloads. The goal is to consume the client connection without letting the client know what is happening. Parameters: time duration (time.Duration) Example: ``` -> tarpit("1s") -> <shunt>; ``` The example will send every second a chunk of response payload. The absorb filter reads and discards the payload of the incoming requests. It logs with INFO level and a unique ID per request: the event of receiving the request partial and final events for consuming request payload and total consumed byte count the finishing event of the request any read errors other than EOF The absorbSilent filter reads and discards the payload of the incoming requests. It only logs read errors other than EOF. The uniformRequestLatency filter introduces uniformly distributed jitter latency within `[mean-delta, mean+delta]` interval for requests. The first parameter is the mean and the second is delta. In the example we would sleep for `100ms+/-10ms`. Example: ``` -> uniformRequestLatency("100ms", "10ms") -> "https://www.example.org"; ``` The normalRequestLatency filter introduces normally distributed jitter latency with configured mean value for requests. The first parameter is (mean) and the second is as in https://en.wikipedia.org/wiki/Normal_distribution. Example: ``` -> normalRequestLatency("10ms", "5ms") -> "https://www.example.org"; ``` The histogramRequestLatency adds latency to requests according to the histogram distribution. It expects a list of interleaved duration strings and numbers that defines a histogram. Duration strings define boundaries of consecutive buckets and numbers define bucket weights. The filter randomly selects a bucket with probability equal to its weight divided by the sum of all bucket weights (which must be non-zero) and then sleeps for a random duration in between bucket boundaries. Example: ``` r: * -> histogramRequestLatency("0ms", 50, "5ms", 0, "10ms", 30, "15ms", 20, "20ms") -> "https://www.example.org"; ``` The example above adds a latency between 0ms and 5ms to 50% of the requests between 5ms and 10ms to 0% of the requests between 10ms and 15ms to 30% of the requests and between 15ms and 20ms to 20% of the requests. The uniformResponseLatency filter introduces uniformly distributed jitter latency within `[mean-delta, mean+delta]` interval for responses. The first parameter is the mean and the second is delta. In the example we would sleep for `100ms+/-10ms`. Example: ``` -> uniformRequestLatency("100ms", "10ms") -> "https://www.example.org"; ``` The normalResponseLatency filter introduces normally distributed jitter latency with configured mean value for responses. The first parameter is (mean) and the second is as in https://en.wikipedia.org/wiki/Normal_distribution. Example: ``` -> normalRequestLatency("10ms", "5ms") ->

``` The histogramResponseLatency adds latency to responses according to the histogram distribution, similar to . The `logHeader` filter prints the request line and the header, but not the body, to stderr. Note that this filter should be used only in diagnostics setup and with care, since the request headers may contain sensitive data, and they also can explode the amount of logs. Authorization headers will be truncated in request and response header logs. You can log request or response headers, which defaults for backwards compatibility to request headers. Parameters: no arg, similar to: "request" "request" or "response" (string varargs) Example: ``` -> logHeader() -> "https://www.example.org"; -> logHeader("request") -> "https://www.example.org"; -> logHeader("response") -> "https://www.example.org"; -> logHeader("request", "response") -> "https://www.example.org"; ``` The `logBody` filter logs the request or response body in chunks while streaming. Chunks start with `logBody("request") $flowid: ` or `logBody("response") $flowid: `, such that you can find all chunks belonging to a given flow. See also filter. Note that this filter should be used only in diagnostics setup and with care, since the request and response body may contain sensitive data. Logs can also explode in the amount of bytes, so you have to choose a limit. You can log request or response bodies. This filter has close to no overhead other than the I/O created by the logger. Parameters: type: "request" or "response" (string) limit: maximum number of bytes to log (int) Example: ``` -> logBody("request", 1024) -> "https://www.example.org"; -> logBody("response", 1024) -> "https://www.example.org"; -> logBody("request", 1024) -> logBody("response", 1024) -> "https://www.example.org"; ``` Configure backend timeout. Skipper responds with `504 Gateway Timeout` status if obtaining a connection, sending the request, and reading the backend response headers and body takes longer than the configured timeout. However, if response streaming has already started it will be terminated, i.e. client will receive backend response status and truncated response body. Parameters: timeout Example: ``` -> backendTimeout("10ms") -> "https://www.example.org"; ``` Configure read timeout will set a read deadline on the server socket connected to the client connecting to the proxy. Skipper will log 499 client timeout with context canceled. We are not able to differentiate between client hang up and read timeout. Parameters: timeout Example: ``` -> readTimeout("10ms") -> "https://www.example.org"; ``` Configure write timeout will set a write deadline on the server socket connected to the client connecting to the proxy. Skipper will show access logs as if the response was served as expected, but the client can show an error. You can observe an increase in streaming errors via metrics or a in opentracing proxy span you can see Tag `streamBody.byte` with value `streamBody error` or in debug logs something like `error while copying the response stream: write tcp 127.0.0.1:9090->127.0.0.1:38574: i/o timeout`. Parameters: timeout Example: ``` -> writeTimeout("10ms") -> "https://www.example.org"; ``` Provides a unix-like `tee` feature for routing. Using this filter, the request will be sent to a "shadow" backend in addition to the main backend of the route. Example: ``` -> tee("https://audit-logging.example.org") -> "https://foo.example.org"; ``` This will send an identical request for foo.example.org to audit-logging.example.org. Another use case could be using it for benchmarking a new backend with some real traffic. This we call "shadow traffic". The above route will forward the request to `https://foo.example.org` as it normally would do, but in addition to that, it will send an identical request to `https://audit-logging.example.org`. The request sent to `https://audit-logging.example.org` will receive the same method and headers, and a copy of the body stream. The `tee` response is ignored for this shadow backend. It is possible to change the path of the tee request, in a similar way to the filter: ``` Path("/api/v1") ->

"^/v1", "/v2" ) -> "http://api.example.org"; ``` In the above example, one can test how a new version of an API would behave on incoming requests. The same as , but does not follow redirects from the backend. This filter provides a unix-like tee feature for routing, but unlike the , this filter feeds the copied request to the start of the routing, including the route lookup and executing the filters on the matched route. It is recommended to use this solution instead of the tee filter, because the same routing facilities are used for the outgoing tee requests as for the normal requests, and all the filters and backend types are supported. To ensure that the right route, or one of the right set of routes, is matched after the loopback, use the filter together with the predicate, however, this is not mandatory if the request is changed via other filters, such that other predicates ensure matching the right route. To avoid infinite looping, the number of requests spawn from a single incoming request is limited similarly as in case of the . Parameters: tee group (string): a label identifying which routes should match the loopback request, marked with the predicate Example, generate shadow traffic from 10% of the production traffic: ``` main: * -> "https://main-backend.example.org"; split: Traffic(.1) -> teeLoopback("test-A") -> "https://main-backend.example.org"; shadow: Tee("test-A") && True() -> "https://test-backend.example.org"; ``` See also: The filter, when executed on the response path, checks if the response entity can be compressed. To decide, it checks the Content-Encoding, the Cache-Control and the Content-Type headers. It doesn't compress the content if the Content-Encoding is set to other than identity, or the Cache-Control applies the no-transform pragma, or the Content-Type is set to an unsupported value. The default supported content types are: `text/plain`, `text/html`, `application/json`, `application/javascript`, `application/x-javascript`, `text/javascript`, `text/css`, `image/svg+xml`, `application/octet-stream`. The default set of MIME types can be reset or extended by passing in the desired types as filter arguments. When extending the defaults, the first argument needs to be `"..."`. E.g. to compress tiff in addition to the defaults: ``` -> compress("...", "image/tiff") -> "https://www.example.org" ``` To reset the supported types, e.g. to compress only HTML, the "..." argument needs to be omitted: ``` -> compress("text/html") -> "https://www.example.org" ``` It is possible to control the compression level, by setting it as the first filter argument, in front of the MIME types. The default compression level is best-speed. The possible values are integers between 0 and 9 (inclusive), where 0 means no-compression, 1 means best-speed and 11 means best-compression. Example: ``` -> compress(11, "image/tiff") -> "https://www.example.org" ``` The filter also checks the incoming request, if it accepts the supported encodings, explicitly stated in the Accept-Encoding header. The filter currently supports by default `gzip`, `deflate` and `br` (can be overridden with flag `compress-encodings`). It does not assume that the client accepts any encoding if the Accept-Encoding header is not set. It ignores * in the Accept-Encoding header. Supported encodings are prioritized on: quality value provided by client compress-encodings flag following order as provided if quality value is equal `gzip`, `deflate`, `br` in this order otherwise When compressing the response, it updates the response header. It deletes the `Content-Length` value triggering the proxy to always return the response with chunked transfer encoding, sets the Content-Encoding to the selected encoding and sets the `Vary: Accept-Encoding` header, if missing. The compression happens in a streaming way, using only a small internal

The filter, when executed on the response path, checks if the response entity is compressed by a supported algorithm (`gzip`, `deflate`, `br`). To decide, it checks the Content-Encoding header. When compressing the response, it updates the response header. It deletes the `Content-Length` value triggering the proxy to always return the response with chunked transfer encoding, deletes the Content-Encoding and the Vary headers, if set. The decompression happens in a streaming way, using only a small internal buffer. Example: ``` -> decompress() -> "https://www.example.org" ``` Serves static content from the filesystem. Parameters: Request path to strip (string) Target base path in the filesystem (string) Example: This serves files from `/srv/www/dehydrated` when requested via `/.well-known/acme-challenge/`, e.g. the request `GET /.well-known/acme-challenge/foo` will serve the file `/srv/www/dehydrated/foo`. ``` acme: Host(/./) && Method("GET") && Path("/.well-known/acme-challenge/*") -> static("/.well-known/acme-challenge/", "/srv/www/dehydrated") -> <shunt>; ``` Notes: redirects to the directory when a file `index.html` exists and it is requested, i.e. `GET /foo/index.html` redirects to `/foo/` which serves then the `/foo/index.html` serves the content of the `index.html` when a directory is requested does a simple directory listing of files / directories when no `index.html` is present Returns arbitrary content in the HTTP body. Parameters: content (string) content type (string) - optional Example: ``` -> inlineContent("<h1>Hello</h1>") -> <shunt> -> inlineContent("[1,2,3]", "application/json") -> <shunt> -> status(418) -> inlineContent("Would you like a cup of tea?") -> <shunt> ``` Content type will be automatically detected when not provided using https://mimesniff.spec.whatwg.org/#rules-for-identifying-an-unknown-mime-type algorithm. Note that content detection algorithm does not contain any rules for recognizing JSON. !!! note `inlineContent` filter sets the response on request path and starts the response path immediately. The rest of the filter chain and backend are ignored and therefore `inlineContent` filter must be the last in the chain. Returns arbitrary content in the HTTP body, if the response has the specified status code. Parameters: status code (int) content (string) content type (string) - optional Example: ``` -> inlineContentIfStatus(404, "<p class=\"problem\">We don't have what you're looking for.</p>") -> "https://www.example.org" -> inlineContentIfStatus(401, "{\"error\": \"unauthorized\"}", "application/json") -> "https://www.example.org" ``` The content type will be automatically detected when not provided. Block a request based on it's body content. The filter max buffer size is 2MiB by default and can be overridden with `-max-matcher-buffer-size=<int>`. Parameters: toblockList (List of strings) Example: ``` -> blockContent("Malicious Content") -> "http://example.com"; ``` Block a request based on it's body content. The filter max buffer size is 2MiB by default and can be overridden with `-max-matcher-buffer-size=<int>`. Parameters: toblockList (List of hex string) Example: ``` -> blockContentHex(`000a`) -> "http://example.com"; -> blockContentHex("deadbeef", "000a") -> "http://example.com"; ``` The filter sed replaces all occurrences of a pattern with a replacement string in the response body. Example: ``` editorRoute: * -> sed("foo", "bar") -> "https://www.example.org"; ``` Example with larger max buffer: ``` editorRoute: * -> sed("foo", "bar", 64000000) -> "https://www.example.org"; ``` This filter expects a regexp pattern and a replacement string as arguments. During the streaming of the response body, every occurrence of the pattern will be replaced with the replacement string. The editing doesn't happen right when the filter is executed, only later when the streaming normally happens, after all response filters were called. The sed() filter accepts two optional arguments, the max editor buffer size in bytes, and max buffer handling flag. The max buffer size, when set, defines how much data can be buffered at a given time by the editor. The default value is 2MiB. The max buffer handling flag can take one of two values: "abort" or "best-effort" (default). Setting "abort" means that the stream will be aborted when reached the

Setting "best-effort", will run the replacement on the available content, in case of certain patterns, this may result in content that is different from one that would have been edited in a single piece. See more details below. The filter uses the go regular expression implementation: https://github.com/google/re2/wiki/Syntax . Due to the streaming nature, matches with zero length are ignored. In order to avoid unbound buffering of unprocessed data, the sed* filters need to apply some limitations. Some patterns, e.g. `.*` would allow to match the complete payload, and it could result in trying to buffer it all and potentially causing running out of available memory. Similarly, in case of certain expressions, when they don't match, it's impossible to tell if they would match without reading more data from the source, and so would potentially need to buffer the entire payload. To prevent too high memory usage, the max buffer size is limited in case of each variant of the filter, by default to 2MiB, which is the same limit as the one we apply when reading the request headers by default. When the limit is reached, and the buffered content matches the pattern, then it is processed by replacing it, when it doesn't match the pattern, then it is forwarded unchanged. This way, e.g. `sed(".*", "")` can be used safely to consume and discard the payload. As a result of this, with large payloads, it is possible that the resulting content will be different than if we had run the replacement on the entire content at once. If we have enough preliminary knowledge about the payload, then it may be better to use the delimited variant of the filters, e.g. for line based editing. If the max buffer handling is set to "abort", then the stream editing is stopped and the rest of the payload is dropped. Like , but it expects an additional argument, before the optional max buffer size argument, that is used to delimit chunks to be processed at once. The pattern replacement is executed only within the boundaries of the chunks defined by the delimiter, and matches across the chunk boundaries are not considered. Example: ``` editorRoute: * -> sedDelim("foo", "bar", "\n") -> "https://www.example.org"; ``` Like , but for the request content. Example: ``` editorRoute: * -> sedRequest("foo", "bar") -> "https://www.example.org"; ``` Like , but for the request content. Example: ``` editorRoute: * -> sedRequestDelim("foo", "bar", "\n") -> "https://www.example.org"; ``` Enable Basic Authentication The filter accepts two parameters, the first mandatory one is the path to the htpasswd file usually used with Apache or nginx. The second one is the optional realm name that will be displayed in the browser. MD5, SHA1 and BCrypt are supported for Basic authentication password storage, see also . Examples: ``` basicAuth("/path/to/htpasswd") basicAuth("/path/to/htpasswd", "My Website") ``` The `webhook` filter makes it possible to have your own authentication and authorization endpoint as a filter. Headers from the incoming request will be copied into the request that is being done to the webhook endpoint. It is possible to copy headers from the webhook response into the continuing request by specifying the headers to copy as an optional second argument to the filter. Responses from the webhook will be treated as follows: Authorized if the status code is less than 300 Forbidden if the status code is 403 Unauthorized for remaining status codes Examples: ``` webhook("https://custom-webhook.example.org/auth") webhook("https://custom-webhook.example.org/auth", "X-Copy-Webhook-Header,X-Copy-Another-Header") ``` The webhook timeout has a default of 2 seconds and can be globally changed, if skipper is started with `-webhook-timeout=2s` flag. Tokeninfo handled by another

The filters just validate the response from the tokeninfo service to do authorization as defined in the filter. If skipper is started with `-oauth2-tokeninfo-url` flag, you can use this filter. The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. There are two rejection scenarios for this filter. If the token is not successfully validated by the oauth server, then a 401 Unauthorised response will be returned. However, if the token is successfully validated but the required scope match isn't satisfied, then a 403 Forbidden response will be returned. If any of the configured scopes from the filter is found inside the tokeninfo result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokeninfoAnyScope("s1", "s2", "s3") ``` If skipper is started with `-oauth2-tokeninfo-url` flag, you can use this filter. The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. There are two rejection scenarios for this filter. If the token is not successfully validated by the oauth server, then a 401 Unauthorised response will be returned. However, if the token is successfully validated but the required scope match isn't satisfied, then a 403 Forbidden response will be returned. If all of the configured scopes from the filter are found inside the tokeninfo result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokeninfoAllScope("s1", "s2", "s3") ``` If skipper is started with `-oauth2-tokeninfo-url` flag, you can use this filter. The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. There are two rejection scenarios for this filter. If the token is not successfully validated by the oauth server, then a 401 Unauthorised response will be returned. However, if the token is successfully validated but the required scope match isn't satisfied, then a 403 Forbidden response will be returned. If any of the configured key value pairs from the filter is found inside the tokeninfo result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokeninfoAnyKV("k1", "v1", "k2", "v2") oauthTokeninfoAnyKV("k1", "v1", "k1", "v2") ``` If skipper is started with `-oauth2-tokeninfo-url` flag, you can use this filter. The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. There are two rejection scenarios for this filter. If the token is not successfully validated by the oauth server, then a 401 Unauthorised response will be returned. However, if the token is successfully validated but the required scope match isn't satisfied, then a 403 Forbidden response will be returned. If all of the configured key value pairs from the filter are found inside the tokeninfo result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokeninfoAllKV("k1", "v1", "k2", "v2") ``` Tokenintrospection handled by another service. The filters just validate the response from the tokenintrospection service to do authorization as defined in the filter. The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported

If one of the configured and supported claims from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokenintrospectionAnyClaims("https://accounts.google.com", "c1", "c2", "c3") ``` The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. If all of the configured and supported claims from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokenintrospectionAllClaims("https://accounts.google.com", "c1", "c2", "c3") ``` The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. If one of the configured key value pairs from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokenintrospectionAnyKV("https://accounts.google.com", "k1", "v1", "k2", "v2") oauthTokenintrospectionAnyKV("https://accounts.google.com", "k1", "v1", "k1", "v2") ``` The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. If all of the configured key value pairs from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` oauthTokenintrospectionAllKV("https://accounts.google.com", "k1", "v1", "k2", "v2") ``` The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. Second and third arguments are the client-id and client-secret. Use this filter if the Token Introspection endpoint requires authorization to validate and decode the incoming token. The filter will optionally read client-id and client-secret from environment variables: OAUTHCLIENTID, OAUTHCLIENTSECRET If one of the configured and supported claims from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` secureOauthTokenintrospectionAnyClaims("issuerURL", "client-id", "client-secret", "claim1", "claim2") ``` Read client-id and client-secret from environment variables ``` secureOauthTokenintrospectionAnyClaims("issuerURL", "", "", "claim1", "claim2") ``` The filter accepts variable number of string arguments, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. Second and third arguments are the client-id and client-secret. Use this filter if the Token Introspection endpoint requires authorization to validate and decode the incoming token. The filter will optionally read client-id and client-secret from environment variables: OAUTHCLIENTID, OAUTHCLIENTSECRET If all of the configured and supported claims from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to

Examples: ``` secureOauthTokenintrospectionAllClaims("issuerURL", "client-id", "client-secret", "claim1", "claim2") ``` Read client-id and client-secret from environment variables ``` secureOauthTokenintrospectionAllClaims("issuerURL", "", "", "claim1", "claim2") ``` The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. Second and third arguments are the client-id and client-secret. Use this filter if the Token Introspection endpoint requires authorization to validate and decode the incoming token. The filter will optionally read client-id and client-secret from environment variables: OAUTHCLIENTID, OAUTHCLIENTSECRET If one of the configured key value pairs from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` secureOauthTokenintrospectionAnyKV("issuerURL", "client-id", "client-secret", "k1", "v1", "k2", "v2") ``` Read client-id and client-secret from environment variables ``` secureOauthTokenintrospectionAnyKV("issuerURL", "", "", "k1", "v1", "k2", "v2") ``` The filter accepts an even number of variable arguments of type string, which are used to validate the incoming token from the `Authorization: Bearer <token>` header. The first argument to the filter is the issuer URL, for example `https://accounts.google.com`, that will be used as described in to find the configuration and for example supported claims. Second and third arguments are the client-id and client-secret. Use this filter if the Token Introspection endpoint requires authorization to validate and decode the incoming token. The filter will optionally read client-id and client-secret from environment variables: OAUTHCLIENTID, OAUTHCLIENTSECRET If all of the configured key value pairs from the filter are found inside the tokenintrospection (RFC7662) result for the incoming token, it will allow the request to pass. Examples: ``` secureOauthTokenintrospectionAllKV("issuerURL", "client-id", "client-secret", "k1", "v1", "k2", "v2") ``` Read client-id and client-secret from environment variables ``` secureOauthTokenintrospectionAllKV("issuerURL", "", "", "k1", "v1", "k2", "v2") ``` The filter parses bearer jwt token from Authorization header and validates the signature using public keys discovered via /.well-known/openid-configuration endpoint. Takes issuer url as single parameter. The filter stores token claims into the state bag where they can be used by oidcClaimsQuery() or forwardTokenPart() Examples: ``` jwtValidation("https://login.microsoftonline.com/{tenantId}/v2.0") ``` This filter is experimental and may change in the future, please see tests for example usage. The filter parses (but does not validate) JWT token from `Authorization` request header on response path and increments the following counters: `missing-token`: request does not have `Authorization` header `invalid-token-type`: `Authorization` header value is not a `Bearer` type `invalid-token`: `Authorization` header does not contain a JWT token `missing-issuer`: JWT token does not have `iss` claim `invalid-issuer`: JWT token does not have any of the configured issuers Each counter name uses concatenation of request method, escaped hostname and response status as a prefix, e.g.: ``` jwtMetrics.custom.GET.example_org.200.invalid-token ``` and therefore requires approximately `count(HTTP methods) count(Hosts) count(Statuses) * 8` bytes of additional memory. The filter does nothing if response status is 4xx or route is opt-out via annotation or state bag value. The filter requires single string argument that is parsed as YAML. For convenience use . Examples: ``` jwtMetrics("{issuers: ['https://example.com', 'https://example.org']}") // opt-out by annotation annotate("oauth.disabled", "this endpoint is public") -> jwtMetrics("{issuers: ['https://example.com', 'https://example.org'], optOutAnnotations: [oauth.disabled]}") // opt-out by state bag: // oauthTokeninfo* and oauthGrant filters store token info in the state bag using "tokeninfo" key. oauthTokeninfoAnyKV("foo", "bar") -> jwtMetrics("{issuers: ['https://example.com', 'https://example.org'], optOutStateBag: [tokeninfo]}") ``` The filter takes the header name as its first argument and sets header value to the token info or token introspection result serialized as a JSON object. To include only particular fields provide their names as additional arguments. If this filter is used when there is no token introspection or token info data then it does not have any

Examples: ``` forwardToken("X-Tokeninfo-Forward") forwardToken("X-Tokeninfo-Forward", "accesstoken", "tokentype") ``` The filter takes a header name and a field as its first and second arguments. The corresponding field from the result of token info, token introspection or oidc user info is added as corresponding header when the request is passed to the backend. If this filter is used when there is no token introspection, token info or oidc user info data then it does not have any effect. To forward multiple fields filters can be sequenced Examples: ``` forwardTokenField("X-Tokeninfo-Forward-Oid", "oid") -> forwardTokenField("X-Tokeninfo-Forward-Sub", "sub") ``` Enables authentication and authorization with an OAuth2 authorization code grant flow as specified by . Automatically redirects unauthenticated users to log in at their provider's authorization endpoint. Supports token refreshing and stores access and refresh tokens in an encrypted cookie. Supports credential rotation for the OAuth2 client ID and secret. The filter consumes and drops the grant token request cookie to prevent it from leaking to untrusted downstream services. The filter will inject the OAuth2 bearer token into the request headers if the flag `oauth2-access-token-header-name` is set. The filter must be used in conjunction with the filter where the OAuth2 provider can redirect authenticated users with an authorization code. Skipper will make sure to add the `grantCallback` filter for you to your routes when you pass the `-enable-oauth2-grant-flow` flag. The filter may be used with the filter to perform authz and access control. The filter also supports javascript login redirect stub that can be used e.g. to store location hash. To enable the stub, add preceding filter with `oauthGrant.loginRedirectStub` key and HTML content that will be served to the client instead of `307 Temporary Redirect` to the authorization URL. The filter will replace `{{authCodeURL}}` placeholder in the content with the actual authorization URL. See the for step-by-step instructions. Examples: ``` all: -> oauthGrant() -> "http://localhost:9090"; ``` ``` singlepageapp: -> annotate("oauthGrant.loginRedirectStub", ` <!doctype html> <html lang="en"> <head> <title>Redirecting...</title> <script> if (window.location.hash !== null) { localStorage.setItem('original-location-hash', window.location.hash); } window.location.replace('{{authCodeURL}}'); </script> </head> </html> `) -> oauthGrant() -> "http://localhost:9090"; ``` Skipper arguments: | Argument | Required? | Description | | -- | | -- | | `-enable-oauth2-grant-flow` | yes | toggle flag to enable the `oauthGrant()` filter. Must be set if you use the filter in routes. Example: `-enable-oauth2-grant-flow` | | `-oauth2-auth-url` | yes | URL of the OAuth2 provider's authorize endpoint. Example: `-oauth2-auth-url=https://identity.example.com/oauth2/authorize` | | `-oauth2-token-url` | yes | URL of the OAuth2 provider's token endpoint. Example: `-oauth2-token-url=https://identity.example.com/oauth2/token` | | `-oauth2-tokeninfo-url` | yes | URL of the OAuth2 provider's tokeninfo endpoint. Example: `-oauth2-tokeninfo-url=https://identity.example.com/oauth2/tokeninfo` | | `-oauth2-secret-file` | yes | path to the file containing the secret for encrypting and decrypting the grant token cookie (the secret can be anything). Example: `-oauth2-secret-file=/path/to/secret` | | `-oauth2-client-id-file` | conditional | path to the file containing the OAuth2 client ID. Required if you have not set `-oauth2-client-id`. Example: `-oauth2-client-id-file=/path/to/client_id` | | `-oauth2-client-secret-file` | conditional | path to the file containing the OAuth2 client secret. Required if you have not set `-oauth2-client-secret`. Example: `-oauth2-client-secret-file=/path/to/client_secret` | | `-oauth2-client-id` | conditional | OAuth2 client ID for authenticating with your OAuth2 provider. Required if you have not set `-oauth2-client-id-file`. Example: `-oauth2-client-id=myclientid` | | `-oauth2-client-secret` | conditional | OAuth2 client secret for authenticating with your OAuth2 provider. Required if you have not set `-oauth2-client-secret-file`. Example: `-oauth2-client-secret=myclientsecret` | | `-credentials-update-interval` | no | the time interval for updating client id and client secret from files. Example: `-credentials-update-interval=30s` | | `-oauth2-access-token-header-name` | no | the name of the request header where the user's bearer token should be

Example: `-oauth2-access-token-header-name=X-Grant-Authorization` | | `-oauth2-grant-tokeninfo-keys` | no | comma separated list of keys to preserve in OAuth2 Grant Flow tokeninfo. Default: empty, preserves all tokeninfo keys. Example: `-oauth2-grant-tokeninfo-keys=scope,realm,expires_in` | | `-oauth2-auth-url-parameters` | no | any additional URL query parameters to set for the OAuth2 provider's authorize and token endpoint calls. Example: `-oauth2-auth-url-parameters=key1=foo,key2=bar` | | `-oauth2-callback-path` | no | path of the Skipper route containing the `grantCallback()` filter for accepting an authorization code and using it to get an access token. Example: `-oauth2-callback-path=/oauth/callback` | | `-oauth2-token-cookie-name` | no | the name of the cookie where the access tokens should be stored in encrypted form. Default: `oauth-grant`. Example: `-oauth2-token-cookie-name=SESSION` | | `-oauth2-token-cookie-remove-subdomains` | no | the number of subdomains to remove from the callback request hostname to obtain token cookie domain. Default: `1`. Example: `-oauth2-token-cookie-remove-subdomains=0` | | `-oauth2-grant-insecure` | no | omits `Secure` attribute of the token cookie and uses `http` scheme for callback url. Default: `false` | The filter accepts authorization codes as a result of an OAuth2 authorization code grant flow triggered by . It uses the code to request access and refresh tokens from the OAuth2 provider's token endpoint. Examples: ``` // The callback route is automatically added when the `-enable-oauth2-grant-flow` // flag is passed. You do not need to register it yourself. This is the equivalent // of the route that Skipper adds for you: callback: Path("/.well-known/oauth2-callback") -> grantCallback() -> <shunt>; ``` Skipper arguments: | Argument | Required? | Description | | -- | | -- | | `-oauth2-callback-path` | no | path of the Skipper route containing the `grantCallback()` filter. Example: `-oauth2-callback-path=/oauth/callback` | The filter revokes the refresh and access tokens in the cookie set by if `-oauth2-revoke-token-url` is configured. It also deletes the cookie by setting the `Set-Cookie` response header to an empty value after a successful token revocation. Examples: ``` grantLogout() ``` Skipper arguments: | Argument | Required? | Description | | -- | | -- | | `-oauth2-revoke-token-url` | no | URL of the OAuth2 provider's token revocation endpoint. Example: `-oauth2-revoke-token-url=https://identity.example.com/oauth2/revoke` | The filter allows defining access control rules based on claims in a tokeninfo JSON payload. This filter is an alias for `oidcClaimsQuery` and functions identically to it. See for more information. Examples: ``` oauthGrant() -> grantClaimsQuery("/path:@_:sub%\"userid\"") oauthGrant() -> grantClaimsQuery("/path:scope.#[==\"email\"]") ``` Skipper arguments: | Argument | Required? | Description | | -- | | -- | | `-oauth2-tokeninfo-subject-key` | yes | the key of the attribute containing the OAuth2 subject ID in the OAuth2 provider's tokeninfo JSON payload. Default: `uid`. Example: `-oauth2-tokeninfo-subject-key=sub` | To enable OpenID Connect filters use `-oidc-secrets-file` command line flag. ``` oauthOidcUserInfo("https://oidc-provider.example.com", "clientid", "clientsecret", "http://target.example.com/subpath/callback", "email profile", "name email picture", "parameter=value", "X-Auth-Authorization:claims.email", "0") ``` The filter needs the following parameters: OpenID Connect Provider URL* For example Google OpenID Connect is available on `https://accounts.google.com` Client ID* This value is obtained from the provider upon registration of the application. Client Secret* Also obtained from the provider Callback URL* The entire path to the callback from the provider on which the token will be received. It can be any value which is a subpath on which the filter is applied. Scopes* The OpenID scopes separated by spaces which need to be specified when requesting the token from the provider. Claims* The claims which should be present in the token returned by the provider. Auth Code Options* (optional) Passes key/value parameters to a provider's authorization endpoint. The value can be dynamically set by a query parameter with the same key name if the placeholder `skipper-request-query` is

Upstream Headers* (optional) The upstream endpoint will receive these headers which values are parsed from the OIDC information. The header definition can be one or more header-query pairs, space delimited. The query syntax is . SubdomainsToRemove* (optional, default "1") Configures number of subdomains to remove from the request hostname to derive OIDC cookie domain. By default one subdomain is removed, e.g. for the www.example.com request hostname the OIDC cookie domain will be example.com (to support SSO for all subdomains of the example.com). Configure "0" to use the same hostname. Note that value is a string. ``` oauthOidcAnyClaims("https://oidc-provider.example.com", "clientid", "clientsecret", "http://target.example.com/subpath/callback", "email profile", "name email picture", "parameter=value", "X-Auth-Authorization:claims.email") ``` The filter needs the following parameters: OpenID Connect Provider URL* For example Google OpenID Connect is available on `https://accounts.google.com` Client ID* This value is obtained from the provider upon registration of the application. Client Secret* Also obtained from the provider Callback URL* The entire path to the callback from the provider on which the token will be received. It can be any value which is a subpath on which the filter is applied. Scopes* The OpenID scopes separated by spaces which need to be specified when requesting the token from the provider. Claims* Several claims can be specified and the request is allowed as long as at least one of them is present. Auth Code Options* (optional) Passes key/value parameters to a provider's authorization endpoint. The value can be dynamically set by a query parameter with the same key name if the placeholder `skipper-request-query` is used. Upstream Headers* (optional) The upstream endpoint will receive these headers which values are parsed from the OIDC information. The header definition can be one or more header-query pairs, space delimited. The query syntax is . SubdomainsToRemove* (optional, default "1") Configures number of subdomains to remove from the request hostname to derive OIDC cookie domain. By default one subdomain is removed, e.g. for the www.example.com request hostname the OIDC cookie domain will be example.com (to support SSO for all subdomains of the example.com). Configure "0" to use the same hostname. Note that value is a string. ``` oauthOidcAllClaims("https://oidc-provider.example.com", "clientid", "clientsecret", "http://target.example.com/subpath/callback", "email profile", "name email picture", "parameter=value", "X-Auth-Authorization:claims.email") ``` The filter needs the following parameters: OpenID Connect Provider URL* For example Google OpenID Connect is available on `https://accounts.google.com` Client ID* This value is obtained from the provider upon registration of the application. Client Secret* Also obtained from the provider Callback URL* The entire path to the callback from the provider on which the token will be received. It can be any value which is a subpath on which the filter is applied. Scopes* The OpenID scopes separated by spaces which need to be specified when requesting the token from the provider. Claims* Several claims can be specified and the request is allowed only when all claims are present. Auth Code Options* (optional) Passes key/value parameters to a provider's authorization endpoint. The value can be dynamically set by a query parameter with the same key name if the placeholder `skipper-request-query` is used. Upstream Headers* (optional) The upstream endpoint will receive these headers which values are parsed from the OIDC information. The header definition can be one or more header-query pairs, space delimited. The query syntax is . SubdomainsToRemove* (optional, default "1") Configures number of subdomains to remove from the request hostname to derive OIDC cookie domain. By default one subdomain is removed, e.g. for the www.example.com request hostname the OIDC cookie domain will be example.com (to support SSO for all subdomains of the example.com). Configure "0" to use the same

Note that value is a string. ``` oidcClaimsQuery("<path>:[<query>]", ...) ``` The filter is chained after `oauthOidc*` authentication as it parses the ID token that has been saved in the internal `StateBag` for this request. It validates access control of the requested path against the defined query. It accepts one or more arguments, that is a path prefix which is granted access to when the query definition evaluates positive. It supports exact matches of keys, key-value pairs, introspecting of arrays or exact and wildcard matching of nested structures. The query definition can be one or more queries per path, space delimited. The query syntax is with a convenience modifier of `@_` which unfolds to `[@this].#("+arg+")` Given following example ID token: ```json { "email": "someone@example.org", "groups": [ "CD-xyz", "appX-Test-Users", "Purchasing-Department" ], "name": "Some One" } ``` Access to path `/` would be granted to everyone in `example.org`, however path `/login` only to those being member of `group "appX-Tester"`: ``` oauthOidcAnyClaims(...) -> oidcClaimsQuery("/login:groups.#[==\"appX-Tester\"]", "/:@_:email%\"*@example.org\"") ``` For above ID token following query definitions would also be positive: ``` oidcClaimsQuery("/:email") oidcClaimsQuery("/another/path:groups.#[%\"CD-*\"]") oidcClaimsQuery("/:name%\"One\"", "/path:groups.#[%\"-Test-Users\"] groups.#[==\"Purchasing-Department\"]") ``` As of now there is no negative/deny rule possible. The first matching path is evaluated against the defined query/queries and if positive, permitted. To get started with , also have a look at the . This section is only a reference for the implemented filters. The canonical use case that is also implemented with : Use the http request to evaluate if Skipper should deny the request (with customizable response) or let the request pass to the downstream service Example: ``` opaAuthorizeRequest("my-app-id") ``` Example (passing context): ``` opaAuthorizeRequest("my-app-id", "com.mydomain.xxx.myprop: myvalue") ``` Data Flows The data flow in case the policy allows the request looks like this ```ascii (1) Request Skipper (4) Request Target Application (6) Response (2) (3) (5) Response Req -> allow Input Open Policy Agent Policy ``` In Step (2) the http request is transformed into an input object following the that is also used by the OPA Envoy plugin. In (3) the decision of the policy is evaluated. If it is equivalent to an "allow", the remaining steps are executed as without the filter. The data flow in case the policy disallows the request looks like this ```ascii (1) Request Skipper Target Applicatio (4) Response (2) (3) Req -> allow Input =false Open Policy Agent Policy ``` The difference is that if the decision in (3) is equivalent to false, the response is handled directly from the filter. If the decision contains response body, status or headers those are used to build the response in (6) otherwise a 403 Forbidden with a generic body is returned. Manipulating Request Headers Headers both to the upstream and the downstream service can be manipulated the same way this works for This allows both to add and remove unwanted headers in allow/deny cases. Requests can also be authorized based on the request body the same way that is supported with the , look for the input attribute `parsed_body` in the upstream documentation. This filter has the same parameters that the `opaAuthorizeRequest` filter has. A request's body is parsed up to a maximum size with a default of 1MB that can be configured via the `-open-policy-agent-max-request-body-size` command line argument. To avoid OOM errors due to too many concurrent authorized body requests, another flag `-open-policy-agent-max-memory-body-parsing` controls how much memory can be used across all requests with a default of

If in-flight requests that use body authorization exceed that limit, incoming requests that use the body will be rejected with an internal server error. The number of concurrent requests is $$ n{max-memory-body-parsing} \over min(avg(n{request-content-length}), n_{max-request-body-size}) $$ so if requests on average have 100KB and the maximum memory is set to 100MB, on average 1024 authorized requests can be processed concurrently. The filter also honors the `skip-request-body-parse` of the corresponding that the OPA plugin uses. Always serves the response even if the policy allows the request and can customize the response completely. Can be used to re-implement legacy authorization services by already using data in Open Policy Agent but implementing an old REST API. This can also be useful to support Single Page Applications to return the calling users' permissions. Hint: As there is no real allow/deny in this case and the policy computes the http response, you typically will want to Example: ``` opaServeResponse("my-app-id") ``` Example (passing context): ``` opaServeResponse("my-app-id", "com.mydomain.xxx.myprop: myvalue") ``` Data Flows For this filter, the data flow looks like this independent of an allow/deny decision ```ascii (1) Request Skipper (4) Response (2) (3) Req -> resp Input Open Policy Agent Policy ``` If you want to serve requests directly from an Open Policy Agent policy that uses the request body, this can be done by using the `input.parsed_body` attribute the same way that is supported with the . This filter has the same parameters that the `opaServeResponse` filter has. A request's body is parsed up to a maximum size with a default of 1MB that can be configured via the `-open-policy-agent-max-request-body-size` command line argument. To avoid OOM errors due to too many concurrent authorized body requests, another flag `-open-policy-agent-max-memory-body-parsing` controls how much memory can be used across all requests with a default of 100MB. If in-flight requests that use body authorization exceed that limit, incoming requests that use the body will be rejected with an internal server error. The number of concurrent requests is $$ n{max-memory-body-parsing} \over min(avg(n{request-content-length}), n_{max-request-body-size}) $$ so if requests on average have 100KB and the maximum memory is set to 100MB, on average 1024 authorized requests can be processed concurrently. The filter also honors the `skip-request-body-parse` of the corresponding that the OPA plugin uses. Deletes given cookie from the request header. Parameters: cookie name (string) Example: ``` dropRequestCookie("test-session") ``` Deletes given cookie from the response header. Parameters: cookie name (string) Example: ``` dropResponseCookie("test-session") ``` Append a cookie to the request header. Parameters: cookie name (string) cookie value (string) Example: ``` requestCookie("test-session", "abc") ``` Appends a cookie to the response via "Set-Cookie" header. It derives cookie domain by removing one subdomain from the request hostname domain. The filter accepts an optional argument to set the `Max-Age` attribute of the cookie, of type `int`, in seconds. Use zero to expire the cookie immediately. An optional fourth argument, "change-only", controls if the cookie should be set on every response, or only if the request does not contain a cookie with the provided name and value. Example: ``` responseCookie("test-session", "abc") responseCookie("test-session", "abc", 31536000), responseCookie("test-session", "abc", 31536000, "change-only") responseCookie("test-session", "deleted", 0), ``` The JS cookie behaves exactly as the response cookie, but it does not set the `HttpOnly` directive, so these cookies will be accessible from JS code running in web browsers. Example: ``` jsCookie("test-session-info", "abc-debug", 31536000, "change-only") ``` This breaker opens when the proxy could not connect to a backend or received a >=500 status code at least N times in a row. When open, the proxy returns 503 - Service Unavailable response during the breaker

After this timeout, the breaker goes into half-open state, in which it expects that M number of requests succeed. The requests in the half-open state are accepted concurrently. If any of the requests during the half-open state fails, the breaker goes back to open state. If all succeed, it goes to closed state again. Parameters: number of consecutive failures to open (int) timeout (time string, parseable by ) - optional half-open requests (int) - optional idle-ttl (time string, parseable by ) - optional See also the . Can be used as feature. The "rate breaker" works similar to the , but instead of considering N consecutive failures for going open, it maintains a sliding window of the last M events, both successes and failures, and opens only when the number of failures reaches N within the window. This way the sliding window is not time based and allows the same breaker characteristics for low and high rate traffic. Parameters: number of consecutive failures to open (int) sliding window (int) timeout (time string, parseable by ) - optional half-open requests (int) - optional idle-ttl (time string, parseable by ) - optional See also the . Can be used as feature. Change (or set) the breaker configurations for an individual route and disable for another, in eskip: ``` updates: Method("POST") && Host("foo.example.org") -> consecutiveBreaker(9) -> "https://foo.backend.net"; backendHealthcheck: Path("/healthcheck") -> disableBreaker() -> "https://foo.backend.net"; ``` See also the . Can be used as feature. DEPRECATED use with the same settings instead. Per skipper instance calculated ratelimit, that allows number of requests by client. The definition of the same client is based on data of the http header and can be changed with an optional third parameter. If the third parameter is set skipper will use the defined HTTP header to put the request in the same client bucket, else the X-Forwarded-For Header will be used. You need to run skipper with command line flag `-enable-ratelimits`. One filter consumes memory calculated by the following formula, where N is the number of individual clients put into the same bucket, M the maximum number of requests allowed: ``` memory = N M 15 byte ``` Memory usage examples: 5MB for M=3 and N=100000 15MB for M=10 and N=100000 150MB for M=100 and N=100000 Parameters: number of allowed requests per time period (int) time period for requests being counted (time.Duration) optional parameter to set the same client by header, in case the provided string contains `,`, it will combine all these headers (string) ``` clientRatelimit(3, "1m") clientRatelimit(3, "1m", "Authorization") clientRatelimit(3, "1m", "X-Foo,Authorization,X-Bar") ``` See also the . Per skipper instance calculated ratelimit, that allows forwarding a number of requests to the backend group. You need to run skipper with command line flag `-enable-ratelimits`. Parameters: number of allowed requests per time period (int) time period for requests being counted (time.Duration) response status code to use for a rate limited request - optional, default: 429 ``` ratelimit(20, "1m") ratelimit(300, "1h") ratelimit(4000, "1m", 503) ``` See also the . This ratelimit is calculated across all skipper peers and the same rate limit group. The first parameter is a string to select the same ratelimit group across one or more routes. The rate limit group allows the given number of requests by client. The client identity is derived from the value of the `X-Forwarded-For` header or client IP address and can be changed with an optional fourth parameter. The optional fourth parameter may specify comma-separated list of header names. Skipper will join header values to obtain client identity. If identity value is empty

when all header values are empty or missing) then ratelimit does not apply. You need to run skipper with command line flags `-enable-swarm` and `-enable-ratelimits`. See also our Parameters: rate limit group (string) number of allowed requests per time period (int) time period for requests being counted (time.Duration) optional parameter to set the same client by header, in case the provided string contains `,`, it will combine all these headers (string) ``` clusterClientRatelimit("groupA", 10, "1h") clusterClientRatelimit("groupA", 10, "1h", "Authorization") clusterClientRatelimit("groupA", 10, "1h", "X-Forwarded-For,Authorization,User-Agent") ``` See also the . This ratelimit is calculated across all skipper peers and the same rate limit group. The first parameter is a string to select the same ratelimit group across one or more routes. The rate limit group allows the given number of requests to a backend. You need to run skipper with command line flags `-enable-swarm` and `-enable-ratelimits`. See also our Parameters: rate limit group (string) number of allowed requests per time period (int) time period for requests being counted (time.Duration) response status code to use for a rate limited request - optional, default: 429 ``` clusterRatelimit("groupB", 20, "1m") clusterRatelimit("groupB", 300, "1h") clusterRatelimit("groupB", 4000, "1m", 503) ``` See also the . The filter configures request rate limit for each backend endpoint within rate limit group across all Skipper peers. When limit is reached Skipper refuses to forward the request to the backend and responds with `503 Service Unavailable` status to the client, i.e. implements load shedding. It is similar to filter but counts request rate using backend endpoint address instead of incoming request IP address or a HTTP header. Requires command line flags `-enable-swarm` and `-enable-ratelimits`. Both rate limiting and load shedding can use the exact same mechanism to protect the backend but the key difference is the semantics: rate limiting should adopt 4XX and inform the client that they are exceeding some quota. It doesn't depend on the current capacity of the backend. load shedding should adopt 5XX and inform the client that the backend is not able to provide the service. It depends on the current capacity of the backend. Parameters: rate limit group (string) number of allowed requests per time period (int) timeframe for requests being counted (time.Duration) response status code to use for rejected requests - optional, default: 503 Multiple filter definitions using the same group must use the same number of allowed requests and timeframe values. Examples: ``` foo: Path("/foo") -> backendRatelimit("foobar", 100, "1s") -> <"http://backend1", "http://backend2">; bar: Path("/bar") -> backendRatelimit("foobar", 100, "1s") -> <"http://backend1", "http://backend2">; ``` Configures rate limit of 100 requests per second for each `backend1` and `backend2` regardless of the request path by using the same group name, number of request and timeframe parameters. ``` foo: Path("/foo") -> backendRatelimit("foo", 40, "1s") -> <"http://backend1", "http://backend2">; bar: Path("/bar") -> backendRatelimit("bar", 80, "1s") -> <"http://backend1", "http://backend2">; ``` Configures rate limit of 40 requests per second for each `backend1` and `backend2` for the `/foo` requests and 80 requests per second for the `/bar` requests by using different group name per path. The total request rate each backend receives can not exceed `40+80=120` requests per second. ``` foo: Path("/baz") -> backendRatelimit("baz", 100, "1s", 429) -> <"http://backend1", "http://backend2">; ``` Configures rate limit of 100 requests per second for each `backend1` and `backend2` and responds with `429 Too Many Requests` when limit is reached. Implements leaky bucket rate limit algorithm that uses Redis as a storage. Requires command line flags `-enable-ratelimits`, `-enable-swarm` and `-swarm-redis-urls` to be

The leaky bucket is an algorithm based on an analogy of how a bucket with a constant leak will overflow if either the average rate at which water is poured in exceeds the rate at which the bucket leaks or if more water than the capacity of the bucket is poured in all at once, see https://en.wikipedia.org/wiki/Leaky_bucket Parameters: label (string) leak rate volume (int) leak rate period (time.Duration) capacity (int) increment (int) The bucket label, leak rate (volume/period) and capacity uniquely identify the bucket. Label supports . If a template placeholder can't be resolved then request is allowed and does not add to any bucket. Leak rate (divided by increment) defines a maximum average allowed request rate. The rate is configured by two parameters for convenience and consistency with other filters but is actually a single number, e.g. the rate of 2 per second equals to the rate of 20 per 10 seconds or 120 per minute. Capacity defines the maximum request burst size or an allowed jitter. Each passing request adds increment amount to the bucket, different routes may add different amounts to the same bucket. Configuration with equal capacity and increment allows no jitter: first request fills up the bucket full and subsequent request will be rejected if it arrives earlier than `emission interval = 1/leak rate`. Real requests always have a jitter which can be demonstrated by the configuration having capacity and increment of one: ``` r1: * -> clusterLeakyBucketRatelimit("1rps", 1, "1s", 1, 1) -> status(200) -> <shunt>; ``` it does not allow jitter and therefore rejects ~half of the requests coming at rate of 1 rps: ``` $ echo "GET http://localhost:9090" | vegeta attack -rate=1/s -duration=1m | vegeta report Requests [total, rate, throughput] 60, 1.02, 0.58 Duration [total, attack, wait] 59.001991855s, 59.000310522s, 1.681333ms Latencies [mean, 50, 95, 99, max] 1.721207ms, 1.555227ms, 1.943115ms, 10.689486ms, 11.538278ms Bytes In [total, mean] 0, 0.00 Bytes Out [total, mean] 0, 0.00 Success [ratio] 56.67% Status Codes [code:count] 200:34 429:26 Error Set: 429 Too Many Requests ``` On the other hand the configuration with capacity greater than increment: ``` r1: * -> clusterLeakyBucketRatelimit("1rps2", 1, "1s", 2, 1) -> status(200) -> <shunt>; ``` allows all requests: ``` ~$ echo "GET http://localhost:9090" | vegeta attack -rate=1/s -duration=1m | vegeta report Requests [total, rate, throughput] 60, 1.02, 1.02 Duration [total, attack, wait] 59.00023518s, 58.999779118s, 456.062s Latencies [mean, 50, 95, 99, max] 1.410641ms, 1.585908ms, 1.859727ms, 8.285963ms, 8.997149ms Bytes In [total, mean] 0, 0.00 Bytes Out [total, mean] 0, 0.00 Success [ratio] 100.00% Status Codes [code:count] 200:60 Error Set: ``` and even if rate is greater than 1 rps the average allowed request rate is still equal to the leak rate of 1 rps: ``` $ echo "GET http://localhost:9090" | vegeta attack -rate=11/10s -duration=1m | vegeta report Requests [total, rate, throughput] 66, 1.12, 1.03 Duration [total, attack, wait] 59.091880389s, 59.089985762s, 1.894627ms Latencies [mean, 50, 95, 99, max] 1.709568ms, 1.60613ms, 1.925731ms, 10.601822ms, 12.10052ms Bytes In [total, mean] 0, 0.00 Bytes Out [total, mean] 0, 0.00 Success [ratio] 92.42% Status Codes [code:count] 200:61 429:5 Error Set: 429 Too Many Requests ``` Therefore the capacity should be configured greater than increment unless strict request interval needs to be enforced. Configuration having capacity below increment rejects all requests. Examples: ``` // allow each unique Authorization header once in five seconds clusterLeakyBucketRatelimit("auth-${request.header.Authorization}", 1, "5s", 2, 1) // allow 60 requests per hour (each subsequent request allowed not earlied than after 1h/60 = 1m) for all clients clusterLeakyBucketRatelimit("hourly", 60, "1h", 1, 1) // allow 10 requests per minute for each unique PHPSESSID cookie with bursts of up to 5 requests clusterLeakyBucketRatelimit("session-${request.cookie.PHPSESSID}", 10, "1m", 5, 1) // use the same bucket but add different amount

one /expensive request counts as two /cheap) Path("/cheap") -> clusterLeakyBucketRatelimit("user-${request.cookie.Authorization}", 1, "1s", 5, 1) -> ... Path("/expensive") -> clusterLeakyBucketRatelimit("user-${request.cookie.Authorization}", 1, "1s", 5, 2) -> ... ``` This filter changes the failure mode for all rate limit filters of the route. By default rate limit filters fail open on infrastructure errors (e.g. when redis is down) and allow requests. When this filter is present on the route, rate limit filters will fail closed in case of infrastructure errors and deny requests. Examples: ``` fail_open: * -> clusterRatelimit("g",10, "1s") fail_closed: * -> ratelimitFailClosed() -> clusterRatelimit("g", 10, "1s") ``` In case `clusterRatelimit` could not reach the swarm (e.g. redis): Route `fail_open` will allow the request Route `fail_closed` will deny the request The basic idea of load shedding is to reduce errors by early stopping some of the ingress requests that create too much load and serving the maximum throughput the system can process at a point in time. There is a great talk by [Acacio Cruz from Google](https://www.youtube.com/watch?v=XNEIkivvaV4) that explains the basic principles. Implements an admission control filter, that rejects traffic by observed error rate and probability. If it rejects a request skipper will respond with status code 503. The probability of rejection is calculated by the following equation: $$ P{reject} = ( { n{total} - { n{success} \over threshold } \over n{total} + 1} )^{ exponent } $$ Examples: admissionControl(metricSuffix, mode, d, windowSize, minRPS, successThreshold, maxRejectProbability, exponent) admissionControl("myapp", "active", "1s", 5, 10, 0.95, 0.9, 0.5) Parameters: metric suffix (string) mode (enum) d (time.Duration) window size (int) minRps (int) success threshold (float64) max reject probability (float64) exponent (float64) Metric suffix is the chosen suffix key to expose reject counter, should be unique by filter instance Mode has 3 different possible values: "active" will reject traffic "inactive" will never reject traffic "logInactive" will not reject traffic, but log to debug filter settings D the time duration of a single slot for required counters in our circular buffer of window size. Window size is the size of the circular buffer. It is used to snapshot counters to calculate total requests and number of success. It is within $[1, 100]$. MinRps is the minimum requests per second that have to pass this filter otherwise it will not reject traffic. Success threshold sets the lowest request success rate at which the filter will not reject requests. It is within $(0,1]$. A value of 0.95 means an error rate of lower than 5% will not trigger rejects. Max reject probability sets the upper bound of reject probability. It is within (0,1]. A value of 0.95 means if backend errors with 100% it will only reject up to 95%. exponent is used to dictate the rejection probability. The calculation is done by $p = p^{exponent}$ The exponent value is within $(0,\infty]$, to increase rejection probability you have to use values lower than 1: 1: linear 1/2: quadratic 1/3: cubic See Deprecated: use or The `accessLogDisabled` filter overrides global Skipper `AccessLogDisabled` setting for a specific route, which allows to either turn-off the access log for specific route while access log, in general, is enabled or vice versa. Example: ``` accessLogDisabled("false") ``` Filter overrides global Skipper `AccessLogDisabled` setting and allows to turn-off the access log for specific route while access log, in general, is enabled. It is also possible to disable access logs only for a subset of response codes from backend by providing an optional list of response code

Parameters: response code prefixes (variadic int) - optional Example: ``` disableAccessLog() disableAccessLog(1, 301, 40) ``` This disables logs of all requests with status codes `1xxs`, `301` and all `40xs`. Filter overrides global Skipper `AccessLogDisabled` setting and allows to turn-on the access log for specific route while access log, in general, is disabled. It is also possible to enable access logs only for a subset of response codes from backend by providing an optional list of response code prefixes. Parameters: response code prefixes (variadic int) - optional Example: ``` enableAccessLog() enableAccessLog(1, 301, 20) ``` This enables logs of all requests with status codes `1xxs`, `301` and all `20xs`. Filter `auditLog()` logs the request and N bytes of the body into the log file. N defaults to 1024 and can be overridden with `-max-audit-body=<int>`. `N=0` omits logging the body. Example: ``` auditLog() ``` Filter `unverifiedAuditLog()` adds a Header, `X-Unverified-Audit`, to the request, the content of which, will also be written to the log file. By default, the value of the audit header will be equal to the value of the `sub` key, from the Authorization token. This can be changed by providing a `string` input to the filter which matches another key from the token. N.B. It is important to note that, if the content of the `X-Unverified-Audit` header does not match the following regex, then a default value of `invalid-sub` will be populated in the header instead: `^[a-zA-Z0-9_/:?=&%@.#-]*$` Examples: ``` unverifiedAuditLog() ``` ``` unverifiedAuditLog("azp") ``` Notifies the proxy that the backend handling this request is also a proxy. The proxy type is based in the URL scheme which can be either `http`, `https` or `socks5`. Keep in mind that Skipper currently cannot handle `CONNECT` requests by tunneling the traffic to the target destination, however, the `CONNECT` requests can be forwarded to a different proxy using this filter. Example: ``` foo1: -> backendIsProxy() -> "http://proxy.example.com"; foo2: -> backendIsProxy() -> <roundRobin, "http://proxy1.example.com", "http://proxy2.example.com">; foo3: -> setDynamicBackendUrl("http://proxy.example.com") -> backendIsProxy() -> <dynamic>; ``` Filter sets the backend host for a route, value is taken from the provided header. Can be used only with `<dynamic>` backend. Meant to be used together with or . If this filter chained together with or filters, the latter ones would have priority. Parameters: header name (string) Example: ``` foo: * -> setDynamicBackendHostFromHeader("X-Forwarded-Host") -> <dynamic>; ``` Filter sets the backend scheme for a route, value is taken from the provided header. Can be used only with `<dynamic>` backend. Meant to be used together with or . If this filter chained together with or , the latter ones would have priority. Parameters: header name (string) Example: ``` foo: * -> setDynamicBackendSchemeFromHeader("X-Forwarded-Proto") -> <dynamic>; ``` Filter sets the backend url for a route, value is taken from the provided header. Can be used only with `<dynamic>` backend. Parameters: header name (string) Example: ``` foo: * -> setDynamicBackendUrlFromHeader("X-Custom-Url") -> <dynamic>; ``` Filter sets the backend host for a route. Can be used only with `<dynamic>` backend. Meant to be used together with or . If this filter chained together with or , the latter ones would have priority. Parameters: host (string) Example: ``` foo: * -> setDynamicBackendHost("example.com") -> <dynamic>; ``` Filter sets the backend scheme for a route. Can be used only with `<dynamic>` backend. Meant to be used together with or . If this filter chained together with or , the latter ones would have priority. Parameters: scheme (string) Example: ``` foo: * -> setDynamicBackendScheme("https") -> <dynamic>; ``` Filter sets the backend url for a route. Can be used only with `<dynamic>` backend. Parameters: url (string) Example: ``` foo: * ->

-> <dynamic>; ``` The `apiUsageMonitoring` filter adds API related metrics to the Skipper monitoring. It is by default not activated. Activate it by providing the `-enable-api-usage-monitoring` flag at Skipper startup. In its deactivated state, it is still registered as a valid filter (allowing route configurations to specify it), but will perform no operation. That allows, per instance, production environments to use it and testing environments not to while keeping the same route configuration for all environments. For the client based metrics, additional flags need to be specified. | Flag | Description | |--|--| | `api-usage-monitoring-realm-keys` | Name of the property in the JWT JSON body that contains the name of the realm. | | `api-usage-monitoring-client-keys` | Name of the property in the JWT JSON body that contains the name of the client. | | `api-usage-monitoring-realms-tracking-pattern` | RegEx of realms to be monitored. Defaults to 'services'. | NOTE: Make sure to activate the metrics flavour proper to your environment using the `metrics-flavour` flag in order to get those metrics. Example: ```bash skipper -metrics-flavour prometheus -enable-api-usage-monitoring -api-usage-monitoring-realm-keys="realm" -api-usage-monitoring-client-keys="managed-id" api-usage-monitoring-realms-tracking-pattern="services,users" ``` The structure of the metrics is all of those elements, separated by `.` dots: | Part | Description | |--|-| | `apiUsageMonitoring.custom` | Every filter metrics starts with the name of the filter followed by `custom`. This part is constant. | | Application ID | Identifier of the application, configured in the filter under `app_id`. | | Tag | Tag of the application (e.g. staging), configured in the filter under `tag`. | | API ID | Identifier of the API, configured in the filter under `api_id`. | | Method | The request's method (verb), capitalized (ex: `GET`, `POST`, `PUT`, `DELETE`). | | Path | The request's path, in the form of the path template configured in the filter under `path_templates`. | | Realm | The realm in which the client is authenticated. | | Client | Identifier under which the client is authenticated. | | Metric Name | Name (or key) of the metric being tracked. | Those metrics are not identifying the realm and client. They always have `*` in their place. Example: ``` Realm | apiUsageMonitoring.custom.orders-backend.staging.orders-api.GET.foo/orders/{order-id}...http_count | | | + Metric Name Client ``` The available metrics are: | Type | Metric Name | Description | |--|--|--| | Counter | `http_count` | number of HTTP exchanges | | Counter | `http1xx_count` | number of HTTP exchanges resulting in information (HTTP status in the 100s) | | Counter | `http2xx_count` | number of HTTP exchanges resulting in success (HTTP status in the 200s) | | Counter | `http3xx_count` | number of HTTP exchanges resulting in a redirect (HTTP status in the 300s) | | Counter | `http4xx_count` | number of HTTP exchanges resulting in a client error (HTTP status in the 400s) | | Counter | `http5xx_count` | number of HTTP exchanges resulting in a server error (HTTP status in the 500s) | | Histogram | `latency` | time between the first observable moment (a call to the filter's `Request`) until the last (a call to the filter's `Response`) | Those metrics are not identifying endpoint (path) and HTTP verb. They always have `*` as their place. Example: ``` HTTP Verb | + Path Template + Metric Name | | |

| | | + Client Realm ``` The available metrics are: | Type | Metric Name | Description | ||--|| | Counter | `http_count` | number of HTTP exchanges | | Counter | `http1xx_count` | number of HTTP exchanges resulting in information (HTTP status in the 100s) | | Counter | `http2xx_count` | number of HTTP exchanges resulting in success (HTTP status in the 200s) | | Counter | `http3xx_count` | number of HTTP exchanges resulting in a redirect (HTTP status in the 300s) | | Counter | `http4xx_count` | number of HTTP exchanges resulting in a client error (HTTP status in the 400s) | | Counter | `http5xx_count` | number of HTTP exchanges resulting in a server error (HTTP status in the 500s) | | Counter | `latency_sum` | sum of seconds (in decimal form) between the first observable moment (a call to the filter's `Request`) until the last (a call to the filter's `Response`) | Endpoints can be monitored using the `apiUsageMonitoring` filter in the route. It accepts JSON objects (as strings) of the format mentioned below. In case any of the required parameters is missing, `no-op` filter is created, i.e. no metrics are captured, but the creation of the route does not fail. ```yaml api-usage-monitoring-configuration: type: object required: application_id api_id path_templates properties: application_id: type: string description: ID of the application example: order-service tag: type: string description: tag of the application example: staging api_id: type: string description: ID of the API example: orders-api path_templates: description: Endpoints to be monitored. type: array minLength: 1 items: type: string description: > Path template in /articles/{article-id} (OpenAPI 3) or in /articles/:article-id format. NOTE: They will be normalized to the :this format for metrics naming. example: /orders/{order-id} clienttrackingpattern: description: > The pattern that matches client id in form of a regular expression. By default (if undefined), it is set to `.*`. An empty string disables the client metrics completely. type: string examples: all_services: summary: All services are tracked (for all activated realms). value: ".*" justsomeservices: summary: Only services `orders-service` and `shipment-service` are tracked. value: "(orders\-service|shipment\-service)" ``` Configuration Example: ``` apiUsageMonitoring(` { "application_id": "my-app", "tag": "staging", "api_id": "orders-api", "path_templates": [ "foo/orders", "foo/orders/:order-id", "foo/orders/:order-id/order_item/{order-item-id}" ], "clienttrackingpattern": "(shipping\-service|payment\-service)" }`,`{ "application_id": "my-app", "api_id": "customers-api", "path_templates": [ "/foo/customers/", "/foo/customers/{customer-id}/" ] } `) ``` Based on the previous configuration, here is an example of a counter metric. ``` apiUsageMonitoring.custom.my-app.staging.orders-api.GET.foo/orders/{order-id}...http_count ``` Note that a missing `tag` in the configuration will be replaced by `{no-tag}` in the metric: ``` apiUsageMonitoring.custom.my-app.{no-tag}.customers-api.GET.foo/customers...http_count ``` Here is the Prometheus query to obtain it. ``` sum(rate(skippercustomtotal{key="apiUsageMonitoring.custom.my-app.staging.orders-api.GET.foo/orders/{order-id}...http_count"}[60s])) by (key) ``` Here is an example of a histogram metric. ``` apiUsageMonitoring.custom.my_app.staging.orders-api.POST.foo/orders.latency ``` Here is the Prometheus query to obtain it. ``` histogramquantile(0.5, sum(rate(skippercustomdurationseconds_bucket{key="apiUsageMonitoring.custom.my-app.staging.orders-api.POST.foo/orders...latency"}[60s])) by (le, key)) ``` NOTE: Non configured paths will be tracked with `{unknown}` Application ID, Tag, API ID and path template. However, if all `application_id`s of your configuration refer to the same application, the filter assume that also non configured paths will be directed to this application. E.g.: ``` apiUsageMonitoring.custom.my-app.{unknown}.{unknown}.GET.{no-match}...http_count ``` This filter is used to measure the time it took to create a route. Other than that, it's a no-op. You can include the same origin marker when you re-create the route. As long as the `origin` and `id` are the same, the route creation time will not be measured again. If there are multiple origin markers with the same origin, the earliest timestamp will be used. Parameters: the name of the origin the ID of the object that is the logical source for the route the creation timestamp (rfc3339) Example: ``` originMarker("apiUsageMonitoring", "deployment1", "2019-08-30T09:55:51Z") ``` This Filter is similar to the filter in regards to parameters and status codes. It turned out that `lifo()` filter can hurt performance at high load. On AWS instance c6g.8xlarge filter had a limit of 21000 requests per second on a single

The `fifo()` filter had not hit a limit at 30000 requests per second. If you use TCP-LIFO, then request processing is already in LIFO style. Parameters: MaxConcurrency specifies how many goroutines are allowed to work on this queue (int) MaxQueueSize sets the queue size (int) Timeout sets the timeout to get request scheduled (time) Example: ``` fifo(100, 150, "10s") ``` This Filter is similar to the filter in regards to parameters and status codes. Performance considerations are similar to . The difference between fifo and fifoWithBody is that fifo will decrement the concurrency as soon as the backend sent response headers and fifoWithBody will decrement the concurrency if the response body was served. Normally both are very similar, but if you have a fully async component that serves multiple website fragments, this would decrement concurrency too early. Parameters: MaxConcurrency specifies how many goroutines are allowed to work on this queue (int) MaxQueueSize sets the queue size (int) Timeout sets the timeout to get request scheduled (time) Example: ``` fifoWithBody(100, 150, "10s") ``` This Filter changes skipper to handle the route with a bounded last in first out queue (LIFO), instead of an unbounded first in first out queue (FIFO). The default skipper scheduler is based on Go net/http package, which provides an unbounded FIFO request handling. If you enable this filter the request scheduling will change to a LIFO. The idea of a LIFO queue is based on Dropbox bandaid proxy, which is not opensource. Dropbox shared their idea in a . All bounded scheduler filters will respond requests with server status error codes in case of overrun. All scheduler filters return HTTP status code: 502, if the specified timeout is reached, because a request could not be scheduled fast enough 503, if the queue is full Parameters: MaxConcurrency specifies how many goroutines are allowed to work on this queue(int) MaxQueueSize sets the queue size (int) Timeout sets the timeout to get request scheduled (time) Example: ``` lifo(100, 150, "10s") ``` The above configuration will set MaxConcurrency to 100, MaxQueueSize to 150 and Timeout to 10 seconds. When there are multiple lifo filters on the route, only the last one will be applied. This filter is similar to the filter. Parameters: GroupName to group multiple one or many routes to the same queue, which have to have the same settings (string) MaxConcurrency specifies how many goroutines are allowed to work on this queue(int) MaxQueueSize sets the queue size (int) Timeout sets the timeout to get request scheduled (time) Example: ``` lifoGroup("mygroup", 100, 150, "10s") ``` The above configuration will set MaxConcurrency to 100, MaxQueueSize to 150 and Timeout to 10 seconds for the lifoGroup "mygroup", that can be shared between multiple routes. It is enough to set the concurrency, queue size and timeout parameters for one instance of the filter in the group, and only the group name for the rest. Setting these values for multiple instances is fine, too. While only one of them will be used as the source for the applied settings, if there is accidentally a difference between the settings in the same group, a warning will be logged. It is possible to use the lifoGroup filter together with the single lifo filter, e.g. if a route belongs to a group, but needs to have additional stricter settings then the whole group. This filter removes the optional trailing dot in the outgoing host

Example: ``` rfcHost() ``` This filter forces an alternative interpretation of the RFC 2616 and RFC 3986 standards, where paths containing reserved characters will have these characters unescaped when the incoming request also has them unescaped. Example: ``` Path("/api/*id) -> rfcPath() -> "http://api-backend" ``` In the above case, if the incoming request has something like foo%2Fbar in the id position, the api-backend service will also receive it in the format foo%2Fbar, while without the rfcPath() filter the outgoing request path will become /api/foo/bar. In case we want to use the id while routing the request, we can use the <loopback> backend. Example: ``` api: Path("/api/:id") -> setPath("/api/${id}/summary") -> "http://api-backend"; patch: Path("/api/*id") -> rfcPath() -> <loopback>; ``` In the above case, if the incoming request path is /api/foo%2Fbar, it will match the 'patch' route, and then the patched request will match the api route, and the api-backend service will receive a request with the path /api/foo%2Fbar/summary. It is also possible to enable this behavior centrally for a Skipper instance with the -rfc-patch-path flag. See . This filter sets request header to the secret value with optional prefix and suffix. This is only for use cases using skipper as sidecar to inject tokens for the application on the path, if it's used in the ingress path you likely create a security issue for your application. This filter should be used as an only feature. Parameters: header name (string) secret name (string) value prefix (string) - optional value suffix (string) - optional Example: ``` egress1: Method("GET") -> setRequestHeaderFromSecret("Authorization", "/tmp/secrets/get-token") -> "https://api.example.com"; egress2: Method("POST") -> setRequestHeaderFromSecret("Authorization", "/tmp/secrets/post-token", "foo-") -> "https://api.example.com"; egress3: Method("PUT") -> setRequestHeaderFromSecret("X-Secret", "/tmp/secrets/put-token", "bar-", "-baz") -> "https://api.example.com"; ``` To use `setRequestHeaderFromSecret` filter you need to run skipper with `-credentials-paths=/tmp/secrets` and specify an update interval `-credentials-update-interval=10s`. Files in the credentials path can be a directory, which will be able to find all files within this directory, but it won't walk subtrees. For the example case, there have to be `get-token`, `post-token` and `put-token` files within the specified credential paths `/tmp/secrets/`, resulting in `/tmp/secrets/get-token`, `/tmp/secrets/post-token` and `/tmp/secrets/put-token`. This filter injects `Bearer` tokens into `Authorization` headers read from file providing the token as content. It is a special form of `setRequestHeaderFromSecret` with `"Authorization"` header name, `"Bearer "` prefix and empty suffix. Example: ``` egress: * -> bearerinjector("/tmp/secrets/my-token") -> "https://api.example.com"; // equivalent to setRequestHeaderFromSecret("Authorization", "/tmp/secrets/my-token", "Bearer ") ``` This filter adds an opentracing tag for a given baggage item in the trace. Syntax: ``` tracingBaggageToTag("<baggageitemname>", "<tag_name>") ``` Example: If a trace consists of baggage item named `foo` with a value `bar`. Adding below filter will add a tag named `baz` with value `bar` ``` tracingBaggageToTag("foo", "baz") ``` This filter sets an opentracing tag from the filter context (state bag). If the provided key (first parameter) cannot be found in the state bag, then it doesn't set the tag. Parameters: key in the state bag (string) tag name (string) The route in the following example checks whether the request is authorized with the oauthTokeninfoAllScope() filter. This filter stores the authenticated user with "auth-user" key in the context, and the stateBagToTag() filter in the next step stores it in the opentracing tag "client_id": ``` foo: * -> oauthTokeninfoAllScope("addressservice.all") -> stateBagToTag("auth-user", "clientid") -> "https://backend.example.org"; ``` This filter adds an opentracing tag. Syntax: ``` tracingTag("<tagname>", "<tagvalue>") ``` Tag value may contain . If a template placeholder can't be resolved then filter does not set the tag. Example: Adding the below filter will add a tag named `foo` with the value `bar`. ``` tracingTag("foo", "bar") ``` Example: Set tag from request header ``` tracingTag("http.flow_id", "${request.header.X-Flow-Id}") ``` This filter works just like , but is applied after the request was

In particular, referencing the response can be used in the parameters. This filter sets the name of the outgoing (client span) in opentracing. The default name is "proxy". Example: ``` tracingSpanName("api-operation") ``` Some filters influence how load balancing will be done When this filter is set, and the route has a load balanced backend using , then the newly added endpoints will receive the traffic in a gradually increasing way, starting from their detection for the specified duration, after which they receive equal amount traffic as the previously existing routes. The detection time of an load balanced backend endpoint is preserved over multiple generations of the route configuration (over route changes). This filter can be used to saturate the load of autoscaling applications that require a warm-up time and therefore a smooth ramp-up. The fade-in feature can be used together with the roundRobin, random or consistentHash LB algorithms. While the default fade-in curve is linear, the optional exponent parameter can be used to adjust the shape of the fade-in curve, based on the following equation: currentrate = proportionalrate * min((now - detected) / duration, 1) ^ exponent Parameters: duration: duration of the fade-in in milliseconds or as a duration string fade-in curve exponent - optional: a floating point number, default: 1 Examples: ``` fadeIn("3m") fadeIn("3m", 1.5) ``` Traffic fade-in has the potential to skew the traffic to your backend pods in case of a rolling restart (`kubectl rollout restart`), because it is very likely that the rolling restart is going faster than the fade-in duration. The image below shows an example of a rolling restart for a four-pod deployment (A, B, C, D) into (E, F, G, H), and the traffic share of each pod over time. While the ramp-up of the new pods is ongoing, the remaining old pods will receive a largely increased traffic share (especially the last one, D in this example), as well as an over-propotional traffic share for the first pod in the rollout (E). To make rolling restarts safe, you need to slow them down by setting `spec.minReadySeconds` on the pod spec of your deployment or stackset, according to your fadeIn duration. This filter marks the creation time of a load balanced endpoint. When used together with the fadeIn filter, it prevents missing the detection of a new backend instance with the same hostname. This filter is typically automatically appended, and it's parameters are based on external sources, e.g. the Kubernetes API. Parameters: the address of the endpoint timestamp, either as a number of seconds since the unix epocs, or a string in RFC3339 format Example: ``` endpointCreated("http://10.0.0.1:8080", "2020-12-18T15:30:00Z01:00") ``` This filter sets the request key used by the algorithm to select the backend endpoint. Parameters: key (string) The key should contain , without placeholders the key is constant and therefore all requests would be made to the same endpoint. The algorithm will use the default key if any of the template placeholders can't be resolved. Examples: ``` pr: Path("/products/:productId") -> consistentHashKey("${productId}") -> <consistentHash, "http://127.0.0.1:9998", "http://127.0.0.1:9997">; ``` ``` consistentHashKey("${request.header.Authorization}") consistentHashKey("${request.source}") // same as the default key ``` This filter sets the balance factor used by the algorithm to prevent a single backend endpoint from being overloaded. The number of in-flight requests for an endpoint can be no higher than `(average-in-flight-requests * balanceFactor) + 1`. This is helpful in the case where certain keys are very popular and threaten to overload the endpoint they are mapped to. . Parameters: balanceFactor: A float or int, must be >= 1 Examples: ``` pr: Path("/products/:productId") -> consistentHashKey("${productId}") -> consistentHashBalanceFactor(1.25) -> <consistentHash, "http://127.0.0.1:9998", "http://127.0.0.1:9997">; ``` ``` consistentHashBalanceFactor(3) ```